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…

GCSS Cost of Delay distribution

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:

And to follow up:


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:
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.

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 below.

Your Email

Your Message


Comments 5

  1. I’d challenge you to consider this… what if projects were the entrenched funding vehicle in the company you were working for. Could you solve the same problem a different way? The problem you are describing is real, but projects as a funding vehicle isn’t necessarily the problem. The more fundamental problems are related the size of the funding increments, the structure of the organization that is delivering the work, the way that scope is managed, and the way that commitments are made. We use projects as a funding vehicle all the time within a lean-agile framework where governance is basically an enterprise level Kanban, we limit WIP, manage to constraints, and try really, really hard to only fund in 2-3 month increments. Even within those increments, there has to be room to trim the requirements in such a way as to maximize value within the time and cost constraints established. I agree with you on the problem, it’s just that the solution you appear to be recommending is a non-starter in many organizations. I’d just suggest that there are other ways to attach the problem. Good post. Thanks for sharing!

    1. Post

      Hi Mike,

      Thanks for reading, and for the comments. Happy to accept your challenge!

      I totally understand that projects are an entrenched funding vehicle in many organisations. In fact, most of my career has been focused on the fuzzy front end of projects.

      I would suggest that the size of the funding increments is completely related to the use of projects as the funding mechanism. Who can be bothered with going through all the hassle of getting a project off the ground if the increment is only a few months? For most organisations, the process and/or effort required is basically the same whether you ask for a Ferrari or a Ford Escort.

      As for the structure of the organization delivering the work, one of the problems with projects as a vehicle is their temporary nature. In reality, most organisations assign permanent staff into a temporary structure. I’ve seen too many examples where at the end of the project, a whole load of learning has either been disbanded, or walked out the door.

      Projects are a fabulous vehicle for delivering infrastructure (or anything where there is a clear delineation between building and operating) and you need to carefully pre-plan a very complicated set of tasks that can be identified and detailed in advance. Software is not like this. The current paradigm for developing software is broken, and the project vehicle is part of the problem.

      We can try to redefine what “project” means if you like, but this is hard to do and it will take decades to reprogram people to understand the new meaning. Changing the meaning of “project” also makes the English language a little poorer, since there are valid places where the project approach makes sense – just not in developing software products and services!

  2. Hi Joshua,

    Thanks for the thought provoking article.

    I’ve joined a team in the UK government with a remit to help departments across government kick-start or unblock their digital transformation programmes, placing user-need at the heart of decision-making.

    Many of the challenges facing these departments are cultural, complex and intractable. Each department behaves like a complex adaptive system where there are multiple motives, changing user needs and at times over-reactive response to policy-change.

    Multiple-millions are spent on services based on decisions and commitments that have not been sufficiently validated and based on phoney certainty.

    I believe we need to be more ready to identify when to use decision models and business models that will probe-sense-respond; an approach I believe fits into your article’s message. It’s quite a large shift in attitude and approach which many will resist and not want to try.

    Incidentally probe-sense-respond is the decision model suited to Cynefin’s complex domain. Are you familiar with the Cynefin framework? Is it something that forms part of thinking?

    Kind regards,

    1. Post

      Hi Dean,

      Yes, I am familiar with Dave Snowden’s work and the Cynefin framework and I’m glad to observe that it seems to be getting increasing recognition and traction. Hopefully the next generation of decision-makers will have a better understanding of the need for different approaches depending on the environment. Probe -> Sense -> Respond in particular doesn’t really fit the traditional “project vehicle” – especially those you tend to see in the public sector.

      I’m also well aware of the challenge of changing the approach in public sector. I spent many years (for my sins?) working in the UK public sector. The work the GDS have been doing hopefully increases the appetite for considering alternatives.

      Practicing what we preach though, part of the trick is to not try and adopt wholesale a completely different model in one fell swoop. Start where they are today and slowly but surely create the conditions for adopting small and easily reversible changes that improve the overall system. Probe -> Sense -> Respond:Amplify/Dampen applies equally to the work of changing the organisation as it does to the work flowing through the organisation. Many “Agile” practitioners (I’m looking at you SAFe) seem to forget this.

      As for #NoProjects in the public sector, allow me to repeat what I say at the top of this post: whatever you do, DON’t talk about #NoProjects – do what is needed for them to slowly fade away.

      I wish you all the best in your endeavours!

Leave a Reply

Your email address will not be published. Required fields are marked *