Who do you think is actually responsible for project success? Would you say it’s the Project Manager, or the Sponsor? Maybe the Development Team Leader who gets the product built, or even the Test Manager whose work drives development via acceptance testing and test-driven development? What do you reckon? Well, in traditional projects such responsibility usually ends up getting shared across various roles, but the inherent problem with this is that it creates a ‘risky ship’ environment where people happily make the wrong decisions knowing that no one person is accountable (assuming such decisions are even made at all!) In order to answer my poser, I would suggest that we consider a different question: “what is the only true indicator of project success?” (clue: it’s got nothing to do with the outdated ‘project triangle’ concept of time/cost/scope). Well, surely true value is only attained…. drum roll please…. through the delivery of products, processes, and services that actually get used. And if you accept this then it’s obvious at least who shouldn’t be in charge, and that is the people in the roles already mentioned as they just don’t have the relevant experience to imagine future products that will satisfy customer needs.

What we want is somebody to really represent the final customer, a person with the authority, capability, knowledge, and, most importantly, time to own the specification and delivery (in the shortest possible time) of a product that has the potential to provide significant competitive advantage for our consumers. We need to find, as we say in the Scrum methodology, a “Product Owner” (or as I like to refer to this role, the “MIPP”: “Most Important Person on the Project”). Having this qualified, single point of contact representing the final consumer is an eminently sensible way of avoiding not only internal politics arising as representatives from the customer community hammer out priorities amongst themselves, but also ensures that your development team is fed only one view of the future rather than being continually bombarded with (often conflicting) requests.

Responsibilities of this role include developing a vision of what the future will look like, facilitating development by remaining on point to answer all development team questions, accepting products as they are created, and ensuring that the initial vision is not watered down or forgotten. Now, this is not to say that the Product Owner isn’t allowed any help in ‘owning’ proceedings. When following an Agile approach, ‘blamestorming’ is prohibited and the whole team must support each other, whatever individual job titles may be, so that we foster a “we’re all in this together” ethic and ensure that decisions are not made in isolation. But the Product Owner must have real authority or the role merely becomes a back-office resource for typing entries into the Product Backlog and arranging meetings with the ‘actual’ Product Owner; choose such a person and you are doomed to failure as you can be sure that it will be pretty much impossible to get the time of the real decision-maker when you need it. As Roman Pichler writes in Agile Product Management with Scrum: “Using a proxy product owner is an attempt to superficially treat a systemic issue”. Or as I would put it: you need a leader, and that leader needs to lead!

So what does all this mean? Basically, without a good Product Owner you may as well give up right now. It’s (just about) possible to succeed with a weak development team but if there is nobody to imagine and then prioritise a different future, and then actually be around to work with the team to fulfil that vision, then all you’re going to achieve is a big fat expense entry on your p&l.