Today I would like to start talking about one of the most mind-boggling aspects of project and process management – error cost escalation. And as every good article starts with a definition, let us use this entry to fixate a couple of the most relevant ones.

First off – what is error cost escalation? In a nutshell, it is the propensity of errors to become more and more expensive when discovered or addressed later down the process flow or at a later project stage.

And what is so mind-boggling about error cost escalation? My, I don’t even know where to start! In the first place, the costs tend to escalate tremendously and go right through the roof from one phase of a project into the next one. Secondly, this scenario repeats itself time and time again: Whether projects and teams are similar or not, errors keep happening and keep being discovered way too late, while costs keep escalating. And finally, everyone gets really surprised at the moment of the discovery, even if one has already gone through such an experience and even when in hindsight the situation looks crystal clear.

What is meant by process flow and project stages? In the context of an organization, this will be the whole value chain between the definition of its strategy and operations/customer service or collections department if we are talking about banking. Within the context of a project, we can stick to the following description: Define – Analyze/Formulate Requirements – Design – Pilot/Test – Deploy/Manufacture – Go-Live.

And finally, how much “more costly” are we talking about? The answer to this question is the classical one – it depends. After doing some research I was astonished to find out how few reliable studies and data are available on the subject (for the reasons we will discuss down the road). The general estimates vary hugely even within one industry, let alone between different ones. As such, within the software industry alone one finds estimations between ten- and hundred-fold increase between the requirement and deployment phase. A NASA paper from the year 2004 shows truly astronomic relations: taking the error correction cost from the requirement phase as a baseline, at the design stage the cost increases up to 8-fold, during the manufacturing – up to 16-fold, at the stage of test and integration – up to 78-fold. And at the point of operations, it can reach the whooping 1500-fold. Even if your project is not exactly the launch of an interstellar spaceship, you are getting the picture: the cost escalation is anything but linear, as one can see on the highly scientific graph below:

On top of that, there are a couple of other enchanting properties of the error cost escalation curve worth mentioning (inspired by Murphy himself, derived from heuristics solely and waiting for proper research to be conducted on them):

1. The error cost increases exponentially with the number of people noticing the error.
2. The cost of an error correction will be inversely proportional to the likelihood of it being someone else’s fault.
3. The cost of correcting an error will be directly proportional to the length of time since the code or calculation was last worked on.
4. The likelihood of an error increases with the complexity of the implemented solution, whereas the likelihood of the developer finding the error decreases with the complexity of the solution.

So, if the cost increases exponentially and can take the shape of a good old hockey stick in extreme cases, why does it keep remaining the case that errors get discovered way too late, both in projects and in processes? This is exactly the type of question for this blog as there is a multitude of reasons to scrutinize and dissect as well as a multitude of paths to explore. In the following articles, we will investigate all sorts of reasons why errors get discovered and addressed too late and what measures we have at our disposal to mitigate the outcome at least somewhat – both, conventional and non-conventional ones. (Spoiler alert: we will even go to a golf field for that!)