Cost of delay (COD) is something we all need better understanding of. Don Reinertsen – the author of “The Principles of Product Development Flow.” – explains some of the mysteries of this elusive subject to Anders Sixtensson of Softhouse.

Anders Sixtensson: In most of the examples you give in articles the cost of a month’s delay is often surprisingly big (at least for someone who has never done the calculation). Is it often a surprise for those that really make the effort?
Don Reinertsen: There are usually three surprises for newcomers to calculating cost of delay (COD). First, they are surprised at how large the number is. Second, they are surprised at how little time it takes to do the calculation. Third, they are surprised at how much consensus they can reach on the value. All three of these surprises occur because people’s intuitive sense of cost of delay is way off. The intuition of members of the same team typically differs by 50 to 1, so the real estimate surprises most team members. In general we have good intuition about things we have seen more than once. People who have never calculated COD have no basis for any intuition on the subject.

.
In pure software development, you do not usually have any high production costs. On the other hand you have maintenance and bug fixing. In your life-cycle profit model, where do these running and variable costs fit in?
For manufactured products the majority of the recurring cost is the cost of manufacturing which is proportional to the quantity of product sold. Software also has recurring costs that are proportional to the quantity of product sold. For example support costs are typically proportional to sales volume. On the other hand, software also has costs that are relatively independent of the quantity of software sold, such as bug fixes. Both of these costs influence the P&L of a software company, and they should be reflected in any economic model that is used in a software company. It is a solid general principle to have life-cycle profit models keep score the same way management keeps score in their P&L.

.
Technical debt is a term often referred to. Usually this means that previously done work has led to bad architecture, high failure rate, high complexity, etc, which make future development and maintenance even more expensive. In a life-cycle profit model, it could be worthwhile to amortize your debt by refactoring or cleaning up the code etc. Where do these kinds of activities fit into your economy-based decision model?
I do not find that technical debt is sufficiently similar to financial debt to reason by analogy on this matter. Financial debt almost always has to be repaid and the total cost of repayment rises as a function of time. In contrast, there are many cases where technical debt will never have to be repaid, and other cases where it can be repaid at a lower cost in the future than the present. When a developer makes the choice to defer work they are generally doing so to achieve another economic benefit such as earlier introduction. Deferring work may have an economic cost. If this added cost is less than the financial benefit of deferring work, for example the value of early introduction, then creating technical debt is a good economic choice. To correctly model such a situation one should include the one-time and recurring costs caused by the technical debt. In general, although I recognize this is not the practice in the software industry, I prefer to refer to this problem as “deferred work” rather than “technical debt”.

.
Our customer runs a portfolio of projects in parallel and tries to manage this pipeline of ongoing projects in such a way that the pipeline as a whole delivers as much business value as possible over time. If we have a bottleneck and need to sequence a number of projects, first to go is for example Project A, then Project C and finally Project B. This sequencing decision should be based on some kind of accumulated cost-of-delay for all the projects together. Have you used or seen Cost-of-delay as an input to portfolio management? Would it be possible?
To maximize the economic benefit of a portfolio of projects the sequencing of projects should consider both the cost of delay of each project and the amount of time that the project will block scarce development resources. This approach is known as a weighted-shortest-jobfirst (WSTF) queueing discipline and it is discussed in the book, “The Principles of Product Development Flow.” The sequence of projects that will produce the best total return will prioritize projects with the highest cost of delay per unit of scarce resource consumed. This illustrates a key point: in product development we can reduce the cost of delay without shortening average cycle time. We can do this by ensuring that jobs that are delayed the most are jobs with the lowest cost of delay.

.
I have read somewhere that one way to get a better understanding of cost-of-delay could be to imagine the following: “How much would I be willing to pay for a ‘magic consultant’ to solve my existing problem NOW?” So, that price divided by the time difference from NOW until I have solved it myself is really the cost of delay. Could you argue like that?
I would not use this approach. A cost-of-delay calculation establishes the value of time on the critical path of the project. Whenever we pay less than this amount for time we are improving the economics of a project. Let’s say cycle time is worth $25,000 a week. If we can save a week of cycle time by spending $500 to expedite a shipment this is attractive. If we can save the same week of cycle time by hiring a consultant for $10,000 it is also attractive. However, neither of these amounts are the cost of delay, which is $25,000. In general the maximum price you would be willing to pay to maintain a project schedule will be the project’s cost of delay, however using your intuitive sense of a maximum price is a very poor way to calculate cost of delay. This price will be determined by intuition which, as I mentioned earlier, typically can vary be a factor of 50:1. It is much better to calculate a cost of delay.