So what’s the solution?
I think we need to move large organisations in a shift away from projects and towards products.
Most large organisations are either still operating on Waterfall, which means they have separate functional “component” teams (which is a bad thing, as I explained in this article). Or they have moved to some form of agile, and established cross-functional teams.
But the Scrum teams are usually a random collection of people hastily put together to work on Random Project X, followed by Random Project Y, and so on. The team have no stable link to any function or application.
The project manager can drag them through hell to deliver Random Project X, then disappear to another project, while another project manager comes along and sends them on a death march to deliver a completely different project.
In Amazon, they have small cross-functional teams that build, own and run a small piece of functionality, which we can call a “product” (it’s not a product in the traditional marketing sense of the word, it’s more likely to be a feature in a website or application). They build it from scratch, deploy it to production, and look after it like it’s their own child. These are product teams, not project teams.
Traditional project management has some failings, which I talked about here. One way to overcome these failings is to not think of work as a large series of discrete projects, with sharp beginnings and ends. But rather as a number of continuous workstreams based around products. And stable teams work on each of these workstreams.
The teams (including the product owner and “product manager”) are responsible for the long-term care and value of the product. Not in terms of what was delivered for a particular “project”, but in terms of how much value the product is providing to the business, year in and year out.
This will help get us away from situations where a project can come along, deliver something of little or no value, leave a big pile of bugs and technical debt, and run off into the distance, patting themselves on the back because “we delivered the scope, on time and on budget”.
Instead of work funded via big “projects”, with specific features and benefits defined up-front attached to that funding, we should move towards pipelines of funding assigned to various “products” or workstreams. And those workstreams are prioritised based on how valuable and strategic that work is expected to be.
It is up to the product owner and product manager to use that funding wisely, adjusting as they go. Locking funds into pre-defined benefits and features gives teams no scope to pivot as they discover new information.
If you want to know more, I wrote an article about how “product funding” might work.