“If you only quantify one thing, quantify the Cost of Delay” – Don Reinertsen

In a nutshell, the “cost of delay” is what it costs an organization in lost revenue, lost opportunity, increased risks, customer respect, etc., due to a delay in realization of value.

Everyone knows intuitively that delays in software delivery impose some economic cost on the organization. But what exactly is that cost, and how do we measure it? Applying a combined Lean-Agile perspective, we can understand these costs better. More importantly, we can use the same perspective to improve the speed and reliability of software delivery, while making important choices about when you’ve delivered enough value.

In this post, you will read about

• The reasons why cost of delay should be a primary measure of software innovation.
• The economic value of shorter, more frequent releases.

Focus your organization on avoiding Cost of Delay

At a gut level, delays in software delivery make everyone uncomfortable. However, for the leaders and managers of software innovation efforts, a gut feel is not enough. Not only do they need to mobilize their organizations to meet their commitments, but they also have to answer for delays to their own higher-ups. The mere fact that something is late doesn’t necessarily mean that it doesn’t have value; however, the degree to which the delay diminishes its value isn’t altogether clear.

First, you need some targets

Before you can solve this conundrum, you need to demand that software innovators have a measure of value in the first place. The economic target will vary, based on the product or project. In one case, customer retention might be the goal. In another, it might be market expansion. In any case, you need to start with some definition of the economic impact that delivering the software is supposed to achieve.

It’s important to be precise, for a couple of reasons. Organizations are dumb beasts, and ambiguity usually leads to confusion and inertia. Additionally, unless you have precise measures of success, it will be extremely difficult to divide them into intermediary goals, each of which can be the rationale behind a separate release. (More on the strategy of smaller, more frequent releases in the next section.) And third, you need to provide some clarity on whether adjustments are needed. If the goal is vague (for example, “Generate more business”), then people working on the software might conclude falsely that the progress towards that goal is sufficient.

Next, you need shorter, more frequent releases

Shorter, more frequent releases are critical to success, for many reasons:

• Earlier realization of value. Naturally, if you can realize value earlier, so much the better. For example, a new mobile application might attract the attention of early adopters, even if it lacks all the planned capabilities at the time of its first release.
• Decisions about whether to continue. In the best case, smaller, more frequent releases arrive more quickly at the point of sufficiency. Perhaps, after re-consideration, the new mobile application does not need all of the planned features, at which point you may want to cancel or postpone further work. In the worst case, if the project or product looks as though it cannot achieve its target, then you can pull the plug that much earlier.
• Adjustment. Software innovation is a learning process. Releasing software frequently creates more real-world feedback loops, arming software professionals with the data needed to challenge their hypotheses and compel important adjustments.

Clarity about the expected economic benefits of each smaller release is just as important as clarity for the overall economic target. For example, the goal for the first release of the mobile app might be, “Reduce customer support calls by 5%,” which is a small piece of the overall goal for the app, a 50% reduction of customer support calls. If the initial release fails to meet the 5% goal, or exceeds it substantially, you have a firmer basis for making adjustments than if no clear goal existed for that release.

Finally, you can assess Cost of Delay

This short article won’t go into the precise calculations for cost of delay. Instead, it’s enough to say for now that the cost of delay is something that you can calculate, based on the approach that we have described. If you expect the number of customer support calls to diminish by 5% after the first release of the mobile app, you can assess the cost to the organization, day by day, of not releasing the app when planned. This cost of delay presents people in the software value stream with a clear economic imperative that should be guiding their actions, instead of a less compelling commitment to a project management outcome.

Calculating cost of delay will also make clear the different patterns of value realization, across products or projects. While some may realize value very early, others may need more time to produce substantial value. Software innovation strategies can adjust to fit these different value curves. For instance, while one team might work very hard to meet the first two releases, another team might be more concerned about later releases.

Summary

Cost of delay is an important metric because it focuses attention on the right question, When and how are we realizing value from our software innovation efforts? It also leads to a smarter release strategy, many shorter releases instead of one expensive (and risky) moon-shot. Agile gives teams the ability to release more quickly and reliably; Lean provides a larger framework for not just the team, but the software value stream overall, to be more value-driven.