{"id":663,"date":"2012-02-20T10:17:50","date_gmt":"2012-02-20T09:17:50","guid":{"rendered":"http:\/\/leanmagazine.net\/?p=663"},"modified":"2024-03-15T15:18:50","modified_gmt":"2024-03-15T14:18:50","slug":"cost-of-delay-don-reinertsen","status":"publish","type":"post","link":"http:\/\/leanmagazine.net\/lean\/cost-of-delay-don-reinertsen\/","title":{"rendered":"Cost of Delay – interview with Don Reinertsen"},"content":{"rendered":"

Cost of delay (COD) is something we all need better understanding of. Don Reinertsen\u00a0\u2013 the author of “The Principles of Product Development Flow.<\/a>”\u00a0\u2013 explains some of the mysteries of this elusive subject to Anders Sixtensson of Softhouse. <\/em><\/h4>\n
\"Don<\/a>
Don Reinertsen at Lean Tribe\u00b4s seminar in Lund<\/figcaption><\/figure>\n


\nAnders Sixtensson: In most of the examples you give in articles the cost of a month\u2019s 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? <\/strong>
\nDon Reinertsen: <\/em>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\u2019s 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.<\/p>\n

.<\/span>
\nIn 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? <\/strong>
\nFor 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.<\/p>\n

.<\/span>
\n\"\"<\/a>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?<\/strong>
\nI 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 \u201cdeferred work\u201d rather than \u201ctechnical debt\u201d.<\/p>\n

.<\/span>
\n\"\"<\/a>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? <\/strong>
\nTo 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, \u201cThe Principles of Product Development Flow.\u201d 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.<\/p>\n

.<\/span>
\nI have read somewhere that one way to get a better understanding of cost-of-delay could be to imagine the following: \u201cHow much would I be willing to pay for a \u2018magic consultant\u2019 to solve my existing problem NOW?\u201d 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? <\/strong>
\nI 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\u2019s 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\u2019s 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.<\/p>\n

\"\"<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Cost of delay (COD) is something we all need better understanding of. Don Reinertsen explains some of the mysteries of this elusive subject to Anders Sixtensson of Softhouse. <\/p>\n","protected":false},"author":32,"featured_media":674,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[59,5,83],"tags":[6,29,30,32,58,31],"_links":{"self":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/663"}],"collection":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/comments?post=663"}],"version-history":[{"count":22,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/663\/revisions"}],"predecessor-version":[{"id":1445,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/663\/revisions\/1445"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media\/674"}],"wp:attachment":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media?parent=663"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/categories?post=663"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/tags?post=663"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}