14 tips for calculating cost of delay. Implementing cost of delay and ultimately creating a project economic model for basing project decisions on is a lot of work. You don't want your efforts to go to waste. So here are 14 tips for creating and ensuring the adoption of your economic model.
-
Build a Project Economic Model (PEM) spreadsheet
Use the sales forecasts which the project approval was based on. If you don’t want to start from scratch, you download a free spreadsheet for calculating cost of delay here.
Why? People understand and buy into the results better when they can see them proven using some simple math in a spreadsheet.
-
Plot monthly sales forecasts (as opposed to annual)
If only annual forecasts are available, estimate the monthly forecasts and plot them. For increased confidence, gather historical monthly sales for similar product launches in the past and try to emulate the shape of the curve.
Figure 1: Monthly Sales Forecast Plots Showing COD
Why? The results are more believable if they are visual. Plots of monthly sales show the impact of a one-month delay more clearly than plots of annual sales.
-
Involve Sales, Marketing, and Finance in the COD calculation and reasoning
Discuss the monthly sales forecast graph with sales, marketing, and finance. Specifically cover what happens if the product is released late. Does the sales incline get a steeper slope somehow? Is there a reduced peak? Does the sales decline move later if the product is launched later? Use one month, three month and six month delays as examples. Draw the projected curves using a markup tool on the original graph.
Why? Buy in to the COD calculation and economic decision making is much better if sales, marketing, and finance agree with the assessment.
-
Estimate the per-month COD using a brute force method
Replicate the delay curves you drew in #3 within your spreadsheet, and compare the cumulative profit in each case. This is done by shifting any increasing monthly forecasts to the right by the amount of the delay. If there will be a peak reduction, reduce all monthly profits by that same percentage. Add total profit for each delay. The difference between the profit in the delay case and the profit in the baseline is the COD for each delay.
Figure 2: Monthly Sales Forecast Plots Showing 1 mo, 3 mo and 6 mo CODWhy? This ‘brute-force’ graphical method helps many people understand and buy into the COD value.
-
Exclude project expenses in your Cost of Delay calculation
When calculating the one-month Cost of Delay sensitivity, do not include labor or other expenses which may be incurred during a month of additional development time. Instead, consider the expense impact of each decision or delay separately.
Why? There are several reasons for this:
a. Expenses for any given decision vary a lot, and can include labor, lab costs, prototype parts, and many other types of costs. Any given decision which costs us a month could cost a lot or a little in project expenses.
b. If you keep expenses separated out, you can more easily determine the ROI associated with each decision. Expenses are the denominator of ROI.
c. In order to make cross-project decisions using COD, it is best if the COD itself isn’t already a function of how many people are on the project. For example, when prioritizing projects you often create pure delays but not R&D overspends. Keep COD a reflection purely of the opportunity value of the project and how that value degrades over time. Add the cost in separately where it’s needed.
d. The expense cost of one month of development is typically much less than the opportunity cost of a one month delay to market. Adding a month of expenses to COD doesn’t change your decisions much, but it does complicate them.
-
Keep the model simple
Don’t put in any ‘time value of money’ (e.g., NPV, IRR etc), or anything which makes it difficult for people to understand and use the model. Simple modifications are ok, like subtracting Marketing and/or General and Administrative (G&A) expenses from revenue.
Why? If the model isn’t easy to understand, it won’t be used and the benefits won’t be realized. NPV doesn’t substantially change the results anyway, especially in Lean development organizations where development times and product lifecycles are shorter.
-
Establish a common Value Horizon for all projects
Whether you use the entire lifecycle of each product or a fixed number of years, set a practice and use it for all projects. We find ‘cumulative profit after “X” years’ works well for comparing many different types of projects. (see Figure 2) Settling on the best Value Horizon seems like it could be difficult, but most companies do it easily. Usually the value horizon we use is 3, 4 or 5 years, and we set it once with a little discussion and keep using it.
Why? This allows better tradeoffs between projects, as they are more apple-apples comparisons.
-
Help people understand that inaccurate sales forecasts do invalidate the model
Help everyone recognize that, while the model is built around estimated sales volume forecasts, and they are often inaccurate, most outputs of the economic model are directly proportional to sales volume. The relative importance of delay vs. sales volumes vs. unit costs stays the same even if volume changes. For more information see the post on this topic.
Why? One of the largest objections and impediments to economic modeling is from the lack of certainty in the base inputs – the sales forecasts. Eliminating this objection is critical to buy-in across the organization.
Figure 4: Impact of Error in Sales Forecasts
-
Economically model every project, of every type, to determine its Cost of Delay
Whether they are new products, cost reductions on existing products, process improvements, CAPAs, or any other type of initiative, develop an economic model. Even products which lose money and seemingly have a negative COD, but which open doors to new markets and future profits, can have a quantified COD which includes the delay of value behind those doors. Different types of projects have different economic models, requiring different input-estimates, but they all have a COD that can be estimated.
Why? COD is the Golden Key (as Don Reinertsen puts it). It enables objective priority and resourcing decisions across all types of projects, and is critical in establishing optimal WIP constraints – i.e., when to start another project and when to wait.
-
Promote the use of the economic model
Management should publicly recognize that we will be correct more often by using economic analysis with some estimates in it, rather than making decisions based entirely on gut-feel. The more profitable choice is unintuitive often enough that it pays to analyze our decisions economically. Management and team members should regularly ask, “What does the economic analysis say?” Publish results frequently, and note how economic analysis helped the team come to a better decision, faster.
Why? Economic Analysis takes a little time and effort. Gut-feel decisions are habit, and they are often easier than analytical decisions, just not as correct and profitable. Some people will need to be reminded of the benefits, or they won’t continue to make the effort. If we don’t use it, we lose it.
An analogy I like to use here is estimating the distance to the pin while golfing. Do you look for the distance markers that are there, or do you just ‘eyeball it’? Looking at the markers is doing a simple analysis. By looking at the markers and eyeballing it together your eyeball estimates will get better. However, you will still be better off doing a quick analysis whenever you can.
-
Establish a Minimum Decision ROI for project decisions
For any given decision, how much return do we need before deciding to do it? The Minimum Decision ROI is a function of the projects we have waiting for funding, and the opportunities available within other active projects. We recommend setting a baseline Minimum Decision ROI and use it across all projects. Review and update it quarterly.
Why? With each decision, we should profit as much or more from that decision than we could by putting our expense money toward something else.
-
Establish Minimum Expected Value, spending limits, and other safety factor(s) for decisions
See the previous post for more on these.
Why? To allow the safer decisions to move forward more quickly, for an even higher profit gain.
-
Create accurate plans and have a detailed understanding of true resource availability
Have good, detailed, up-to-date project plans, a good understanding of which resource(s) and work is Critical Chain, and what people’s true availability is.
Why? These allow you to have a better estimate for the impact a change will have on the launch date. With better delay estimates, our analyses are more accurate, and we achieve more buy-in and higher profit. This one is in the ‘not so easy’ section because it is difficult - unless you have a tool (Playbook) that makes accurate planning easy.
-
Get direct customer feedback
For decisions that impact sales volume or price, turn to your customers for representative feedback. Get better feedback about what your customers truly value by using Lean Startup methods. Also, remember that we don’t need to know exactly what ‘% change in volume’ will result from a particular change to the product. We can, instead, determine the break-even value and move forward if we expect to be above that value.
Why? Even the people in our organization who are experts on our customers (Chief Engineer, Marketing, Sales, etc.), will overvalue some ideas and undervalue others. We are better off learning what customers actually need and will pay for.
Summary and series wrap-up
In summary, the success of project economic modeling requires buy-in and a commitment from the organization to base new product development decisions in part on economics. Although it takes a little practice, discipline and work up front, once the model is in place, the level of effort is small compared to the payback!
I will conclude this series by adding one more key benefit to understanding Cost of Delay and economic analysis. COD is the key to resolving one of the primary root causes of the slow and overloaded conditions of traditional product development.
Many problems stem from too much visibility to project and company expenses, and a lack of visibility to COD. A focus on expenses causes local optima within departments, rather than optimizing the entire system. It pushes us toward larger batches and higher capacity utilization, which in turn cause big delays, lower quality products, frustrated and stressed-out people, and reduced profits.
Cost of Delay is the magic compass that helps counteract the natural forces pushing us into these stable and slow traditional conditions. With COD showing us the way, we see the value of spare capacity, limited WIP, better risk management, and smaller batches, all of which are critical to becoming a truly Lean organization.
Please let us know if you have any questions, comments, or requests for future topics.
-----
Download the free spreadsheet to calculate cost of delay.
Related Posts
Introduction to Cost of Delay
What is Cost of Delay?
Cost of Delay: How to Calculate It
Cost of Delay and Project Modeling
Cost of Delay Project Model Examples
Cost of Delay Project Modeling Risk
Cost of Delay and Strategic Advantage
Cost of Delay: Project decisions based on profit
8 Ways to Decrease Risk in Project Decisions
14 Tips for Calculating Cost of Delay
WSJF and How to Calculate It
Don Reinertsen on cost of delay
Wikipedia on cost of delay
Guide to Cost of Delay
Editor's note: This post was originally published in 2015 and has been updated for accuracy and comprehensiveness.
