The problem with projects
If you consider the economic value and urgency for each of the requirements for your software development project, you will likely find that it is not evenly distributed. It’s not four levels of value (like MoSCoW might suggest). It’s also not linear (like your relatively prioritised backlog might suggest). It probably looks something like this…
Here is an excerpt from the paper we wrote about Black Swan Farming using Cost of Delay:
Seeing the evidence of [the power-law distribution of value] suggested that it really was worth the effort to break work down and consider value at the feature level. What this also suggests is that projects are a poor vehicle for delivering valuable software. By attributing value to the whole project, rather than individual features, this effectively waters down the benefit cost ratio of the most valuable features. It becomes easier to batch up and hide a bunch of low-value features inside the project alongside the “vital few” that are truly valuable, forcing them to carry the others. This is a classic batch size problem.
Using projects at Maersk Line had other effects though. By fixing the duration of projects, the organization missed the high Cost of Delay ideas that arrived after the pre-defined window of opportunity had closed. Even worse, was when they not only fixed the duration of the project but also attempted to fix the scope prior to approval. This had the effect of reducing even further the window of opportunity. The incentive for the business was to try and work out up-front what the whole solution “needed” to be. Unfortunately, most of what gets included at this point has a low Cost of Delay – a truly sub-optimal approach.
In effect, projects at Maersk Line were a tail-dropping FIFO queuing system – one that tended to ignore late arriving, but high Cost of Delay ideas. Our conclusion is that projects are a poor vehicle for improving how the organization works as well as the products and services they provide.
It’s not just the distribution of value though, it’s also the effect on the team. This is what I was getting at when I replied to Damien Schreurs, fixing his original tweet:
“@DamienSchreurs: Using Cost of Delay to prioritize _features_ (via @JoshuaJames) – http://t.co/TAikc8QQ9e” Fixed it for you :)
— Joshua J. Arnold (@joshuajames) June 2, 2013
And to follow up:
.@DamienSchreurs Projects kill flow and teams. Focus on products, not projects. #NoProjects (rather than #NoEstimates).
— Joshua J. Arnold (@joshuajames) June 2, 2013
My thoughts on this are only half-baked. I may well be wrong, but I get the distinct impression that the use of projects as the primary vehicle for delivering software products and services is less than ideal. Maybe this is what Don Reinertsen was hinting at when he says:
“…the dominant paradigm for managing product development is wrong. Not just a little wrong, but wrong to it’s very core.”
Few would deny that the dominant paradigm for managing product development today is the project vehicle. There are of course exceptions — where enlightened product managers use projects in a very loose sense, or even merely as a funding vehicle. If these funding increments are small enough, with a roughly defined goal and a long-lived team working on it… well, at some point this no longer resembles what the mainstream would consider to be a “project”.
#NoProjects (*for product development).
So, what am I proposing as an alternative? Well, firstly, I don’t believe in an all-out “war on projects”. I know full well that the project vehicle can be helpful for getting complicated, one-off things done. But if what you’re doing is more complex and the definition of “done” is unclear, then wrapping that up in a project vehicle leads you to focus predominantly on the wrong things.
So if all projects aren’t the enemy, perhaps we need a different word to describe a better vehicle for developing products? One success criteria could be that it shifts the focus away from the language of certainty. We need something that highlights the discovery and learning that product development requires. It’s no good trying to change the definition of “project” to include these. Doing so would mean we lose the original meaning of “project”, which we’ve already agreed is useful in some situations.
Try this for a week — every time you see, hear or speak the word “project”, substitute with one of these alternatives:
Initiative.
Experiment.
Exploration.
Increment.
Iteration.
Or, try one of your own creation. (Answers on a postcard, or the comments below). What you’re trying to do is use language to suggest an approach that is fit for purpose, given the more complex environment i.e. Probe > Sense > Respond
Allow me one more excerpt from Black Swan Farming on the subject of projects and their use as a vehicle for innovation:
Innovation requires that we test new ground and break things, discovering the best solution. Probe, sense, respond: Amplify the positive signal, dampen the negative signal. In this way, product development is not so much Black Swan hunting, but more like Black Swan farming. Projects hide a lot of these small bets though and provide management with a false sense of control. You actually have more visibility and control when you deliver a series of small incremental and iterative steps…
I’m sure I’ll come back to this theme again. In the meantime, have a read of Steve Smith’s blog post, which contains a bunch of relevant points. Bob Marshall has also a couple of posts on the subject. Allan Kelly also.
Plan —> Forecast
Resources —> Teams
Push —> Pull
Reqmnts —> Expmnts
Projects —> Initiatives
Dates —> CostOfDelay— Joshua J. Arnold (@joshuajames) May 10, 2016
If you want to talk about alternative funding models and other ways to tilt the playing field in product development, without projects, get in touch!