Why, looking back at problem projects, does it so often seem that the key mistakes were made so early? And what can we do about it?

This came up last week talking to someone about yet another almost-failed project, where in that case it was the wrong choice of supplier. In other conversations it’s been the wrong technology, or the wrong contractual arrangement with (what otherwise might have been) the right supplier. Sometimes it’s been a complete failure to understand what the customers wanted.

So to the first question: why are the key mistakes seemingly made so early? I think the answer has to be that the impact of any decision grows with time, so the earliest bad decisions will be the ones with the biggest impact.

Typically a decision or action is built on over time: Our strategy will be this, so we’ll do X, which means we’ll do Y, and so onto Z. If we now discover it’s a bad strategy we’ve got to undo X, Y and Z. The impact of a decision over time (which can be measured as the cost of undoing it or changing it) typically looks like this:

Sometimes it’s more significant. A legal contract may have termination penalties in force the moment it’s signed. In that case the impact looks more like this:

We may also find ourselves making a decision with an impact that looks like this:

That will be when we’ve made the decision long before it’s ever actually needed.

Given this, let’s take the second question: How can we reduce the impact of mistaken decisions?

Ideally we’ll want our impact curve to look like one of these:

or any other shape where any possible negative impact is contained. Here are some options as to how to achieve this:

1. Make decisions as late as possible. This has two benefits. First, there is less time for dependencies to grow around the decision. Second (and more significantly) it gives provides us with the best context in which to make the decision: the most up to date market information, the experience of everything else learned so far, etc.
2. Include a mechanism to handle change gracefully. For example in a contract make sure the cost of termination is proportionate to the time and effort the other party has committed (or better, of course). Software development has evolved its own system of tools and practices which ensure the cost of change there can be minimised.
3. Work with alternatives in mind. For example, if your supplier is developing an application for you to run, make sure they’re not relying on any secret sauce that you can’t find elsewhere.
4. Break up decisions into smaller ones, in parallel. AKA spread your risk. AKA don’t put all your eggs in one basket. E.g. if there’s a risk of becoming too dependent on a single provider of widgets then split the supply over two providers. They don’t even need to be placed in competition, and you can rebalance your supplier portfolio continually.
5. Break up decisions into smaller ones, in serial. For example, very often deciding what’s to be done is important for early planning, but deciding a lot of how it’s to be done can be delayed. If we’re thinking about marketing it might be useful to start working up concepts early, but the company which creates those ideas need not be the company that produces the final material, and that selection could be made much later.

You can probably think of more ideas. By all means throw them into the ring.

The most significant lesson for me, though, is to have a mitigation strategy for all decisions — particularly those that are made early on.