How does the Product Owner role change everything in software delivery?
June 22, 2015
I was having a conversation with one of our Agile coaches, who has a long history of project management delivery. We were discussing:
Who owns the successful delivery of value of the features in a traditional project approach?
I think the answer is:
It falls between the gaps.
In a PRINCE2 world, you have:
1. An IT project manager
They generally deliver the solution.
2. A business project manager
They deliver the business components required to support the solution, re-structure the business process, get everyone set up to start using the solution and make sure the training is in place.
3. A steering group
This group is there to pull the strings and make sure that the project is delivering against the business case.
However, all these things fall apart at the end of a project. You do your ‘ta-da!’ release that delivers everything, everyone congratulates each other on a slightly late but effective delivery of the project, and then they go back to their day jobs.
No one owns the delivery of the business case, which is why the project was initially justified.
Choose a Product Owner.
Give them the budget to deliver what they need to deliver to make the business case work.
They might not be interested in delivering the lower value / higher cost features that were originally in the scoping document. They’re interested in delivering, as soon as possible, the one or two high value features that:
- De-risk the project
- Start generating revenue
- Validate that customers want it
- Start getting some traction in the business and market
Only once they get that traction will they then be willing to invest more to deliver the next set of features.
More importantly, they will learn what the next most-valuable set of features are, only once the first set of features are actually seen working in production (or not working in production).
Make sure your project is set up with a Product Owner (or a business project manager) that is solely dedicated to making sure that the benefits are delivered. The benefits are easier to deliver if you have a lower cost overhead for them. So if the person is empowered to make decisions on which benefits can be delivered for which spend, then they will naturally deliver only the highest value / lowest cost items.
It’s important to view your project as a set of features, some of which are:
It’s also important to understand the return on your investment for each feature. You don't want to deliver the features that are going to cost you a lot and not deliver any value.
The value is delivered in terms of either:
- Cash in the bank from revenue generated
- De-risking internally or externally
- De-risking the technical solution
So assess the value but, more importantly, empower someone to deliver on that value and look at outcomes, not scope.