[Music] Everything can be improved, iterated and refined. And if you don't think that's true, maybe you haven't analysed it enough. Calculated choices, carefully considered, absolutely analytical. This episode is brought to you by Clubhouse, the first project management solution for software development for software development that brings everyone on every team together to build better products. Visit this URL, clubhouse, or oneword.io/10theword for more information. We'll talk more about them during a show. Analytical is part of the Engineered Network to support our shows, including this one. Head over to our Patreon page and for other great shows, visit engineered.network today. Owner or owners. Generally, sometimes even more than two. One of the biggest challenges working in large organisations is understanding where you fit. When you're asked to deliver a project of some kind, of any kind, the first question you'll ask is "What is the project expected to deliver?" Maybe it's not obvious, but often projects are doomed to fail when someone asks that question to the wrong person. So in fact, it's not actually the wrong question, but first perhaps you should start with a different question. Who owns what the project is delivering? To put it a different way, who will be responsible for the ongoing use, maintenance and performance of what the project delivers? One analogy for that is ownership of a car. Now let's say it's a Tesla, because well, Tesla's making some nice electric cars these days, mostly. As a potential customer of Tesla, I visit their showroom, maybe take a test drive and then if I buy one, I now am a customer of theirs. But I'm also an owner of that specific car that I bought. If I drive it hard, if I corner it hard, drive it on really rough roads and I choose to never get it serviced, then as the owner I will have to pay to get that repaired. As an owner of that vehicle, I'm on the hook except if it's defective, in which case the company needs to go pay to rectify it. So now we're going to switch to our project context. If there's a project that's delivered to an owner and there are issues with that project, the onus remains on the project to fix those defects. That's why we have a defect and liability period or DNLP for short. Now during a DNLP, a company has to make good to the satisfaction of the owner and there's usually some retained funds to ensure some kind of reasonable compliance. in this regard can get a bit murky with internal projects since let's face it, if the project team doesn't deliver, then what are you going to do? You're going to withhold their paycheck? You're going to sue one part of the company from the other part of the company? It's not going to happen. Companies that do lots of internal projects generally will have their own defect tracking system while the organized ones do anyway. Attached to that maybe there's a project delivery framework and different progress gates that you have to pass through, whereby the project team doing the project delivery isn't off the hook so to speak until all of the defects have been agreed as being completely closed out. But the determination of what is a defect and what isn't comes back to an adjudication or a judgement by whomever is the owner or their delegate. So if one or two people in the organisation say this is a defect, the final judgement has to be made by the owner. If the owner says that it's not a defect, then surely the buck stops with them and it isn't a defect. So that's precisely why clarity around who the owner is as early in the project as possible at the very beginning is vital and consistency of the owner throughout the whole project duration is equally vital. Where projects so often seem to go wrong is when this isn't an early focus. Some suggestions around handling and understanding owners I suppose. First of all, identify the direct owner of what the project will ultimately deliver. You have to accept the fact that larger projects can and do have multiple owners. It's not just one person. And in many cases on projects of a certain size in large organizations, it's a very bad idea to have just one owner. When owners change, take time to bring them up to speed, the new ones that is. You've got to bring them up to speed with all the key decisions that have been made to date and if you can, why they were made. Investing that time to ensuring the project goals are established and agreed as early as possible on the project and reinforce them as you go. Come to owners when design decisions need to be made with an open mind and multiple options on the table and let the owner or owners make the decisions and then respect them. Of course, the longer the project, the higher the churn in an organisation, the more difficult this becomes. Multiple owners for multiple aspects of the project, changing multiple times during the project is a sure recipe for a very bad result and a huge waste of time and money. So focusing on what we can control, let's just focus on how to be sure you have the right owner or owners involved and then make sure that it doesn't become a six degrees of separation problem because you end up seeing everyone as their customer. And spoiler alert, they aren't. Before we go any further, I'd like to talk about our sponsor of this episode. And that's Clubhouse, the first project management platform for software development that brings everyone on every team together to build better products. Now Clubhouse was built from the outset with agile development in mind, with an intense focus on intuitiveness and responsiveness. With their web app backed by Fastly CDN, it really feels like a local app on any platform. Clubhouse delivers developer-centric tools for everything from Kanban boards to epics, milestones, cards, with different card classifications for features, bugs and chores, but it's more Clubhouse's ability to interconnect all of them together that's so impressive. Users have reported creating list duplicates, navigation is very fast using a common board, but with as many configurable workspaces as you like to customize that board for whatever purposes you might need, morning stand-ups for different teams, sub-teams, all the teams, it's up to you. Ultimately any collaborative project management software has to be as low friction as possible and not just for software developers but for everyone in the organisation, marketing, support, management, you name it the lot so everyone can contribute and actual collaboration actually happens. Finally, the other part of Clubhouse that really shines is its ability to zoom out from individual tasks to the overall project status that not only keeps project managers happy but keeps the team connected to how their part contributes to the greater project and keeps them focused on what matters, delivering a result their customers will enjoy. There are others in the market but they're not like Clubhouse and what makes Clubhouse so different is the balance between the right amount of simplicity without sacrificing key functionality structured to allow genuine cross-functional team collaboration on your project. is a modern software as a service platform with seamless integrations for popular tools like GitHub, Slack, Sentry and lots more and if the tools that you want to integrate with aren't available out of the box there's an extensible REST API in Clubhouse that makes integrations straightforward. If you visit this URL clubhouse or oneword.io/10theword you can take advantage of a special offer for Engineered Network listeners. Of course you'll get the 14-day free trial but if If you sign up, you'll get two months free. And because this is a team centric solution, this offer will work for your team, not just you. This offer is available to Engineered Network listeners for a limited time. So take advantage of it while you can. Thank you to Clubhouse for sponsoring the Engineered Network. Okay, so there's two realistic types of ownership, authoritative and technical. Authoritative owners, these are owners that typically management level and have a team or series of teams that are engaged in the operation, maintenance and support of some aspect of the business that the project will impact or it will deliver to. They aren't necessarily technical in nature and in the cases where they aren't, if they're sensible, they'll defer their technical components to a technical owner or technical authority instead. Technical owners, well, they're the owners that typically don't have a team working for them directly, but they're considered to be seniors or leads in their technical discipline either internationally, nationally or just organizationally. Outside of any given project they may set technical standards that directly or indirectly affect the operation, maintenance and support of some aspect of the business that the project is going to impact or deliver to. In truth, it's also possible to have an owner that's both technical and authoritative, and that's fine, but that sort of person might just be a bit stressed out from time to time. What can you do? Anyway. This definition does create a small problem though. You could cast the definition over an entire organisation or at least large swaths of it. So to be sure that doesn't happen we need to identify that for a project to be able to succeed it must have an organisational owner that represents all of the users of their product area. So let's consider a simple example, a project has stood up to deliver a new email template let's say, we don't identify that 1000 employees in the company is individually an owner, instead see them as users. The owner should solicit opinions through various means and provide this to the project as a starting point. Sometimes we call that a design basis. Or sometimes the project might do that on their behalf and then the owner can confirm these requirements are correct before they start executing. Another example might be a data concentrator whose data is used by multiple engineering departments, each with a different use for that data in question, but if the data team had to engage with every single user in every single department, that wouldn't work, so each department needs to have a representative to provide some ownership. Ultimately, though, projects that ignore or just vaguely attempt to identify and engage with owners usually end up delivering the wrong thing to the wrong people to the overall detriment of all concerned, including themselves, because they'll end up looking pretty stupid. Some projects believe that delivering an outcome, even if it isn't what the owner requested or needed, is the measure of a good result. For a single company, with projects delivering to themselves, poor engagement with owners and delivering something unfit for purpose ultimately costs the whole organisation. Certainly there are those in business that are happy to run projects with no interest in the best outcome for the entire business and only their own personal interests. And maybe one way of telling good projects from bad ones is by seeing how much they care about identifying and engaging with the owners of what their project delivers on. Because ultimately if they aren't, then either it's intentional and that's pretty bad, or they just shouldn't be running projects with your company's money. Ever. If you're enjoying Analytical and want to support the show, you can via Patreon at patreon.com/analytical. or one word. With a thank you to all of our patrons, and a special thank you to our silver producers Carsten Hansen and John Whitlow, and an extra special thank you to our gold producer known only as R. Patron rewards include a named thank you on the website, a named thank you at the end of episodes, access to raw detailed show notes as well as ad-free high quality releases of every episode, with patron audio now also available via individual breaker audio feeds. So if you'd like to contribute something, anything at all, there's lots of great rewards and beyond that it's all really, really appreciated. Beyond that there's lots of other ways to help like leaving a rating or review on iTunes, favoriting the episode in your podcast player app or sharing the episode or the show with your friends or via social. All of these things help others discover the show and can make a huge difference. I'd personally like to thank Clubhouse for sponsoring the Engineered Network. If you're looking for an easy to use software development project management solution that everyone can use to specifically visit this URL, clubhouse or oneword.io/10theword to check it out and give it a try. It'll surprise you just how easy it can be. Analytical is part of the Engineered Network and you can find it at engineered.network and you can follow me on the Fediverse at
[email protected] or the network on Twitter at engineered_net. We also have a YouTube channel with more content going live regularly for your convenience. Accept nothing. Question everything. It's always a good time to analyze something. I'm John Chui-Jing. Thanks so much for listening. [Music]
