A guide to cost of delay 

This Guide shows you how to estimate Cost of delay and other economic sensitivities to create a model for making project decisions based on Return on Investment and profitability. It will show you:

 

You can also download the complete guide on cost of delay here.

 

Download my eBook

What is Cost of Delay?

The Cost of Delay is the amount of money it will cost the company if a product launch is delayed. According to Don Reinertsen, it's the most important metric to know. 

The cost of delay is often worth millions of dollars in lost profit.

We can assume then, that creating fast flow in your new product development project is critical to your bottom line! 

How do you calculate the cost of delay?

Here is a simple formula for quickly estimating cost of delay: the profit lost per-month of delay.

 

Total COD = Lost Month Cost + Peak Reduction Cost

 

In order to calculate the cost of delay, we need to understand the behavior of the product life-cycle, and the impact of launching late, on total profit. In this post we will discuss the product life-cycle, and how to estimate the Total cost of delay quickly.

Building an economic model to aid in project decision making

First, understanding the cost of delay provides a sound economic foundation for making decisions regarding which projects should get priority across an organization. It's also a good way to prioritize the implementation (or not) of new product features, tempering scope creep.

For example, cost of delay can answer the question, which project is going to cost me more profit if it is delayed? If the company knows the cost of delay for each project, it's easy to choose which projects make the most economic sense to put on hold, and which projects need to be driven to completion before the next project kicked-off.

Next, cost of delay can provide valuable economic input into the question, should we add this product feature before launch? With pressure from the business to add new features, the cost of delay can give a clear picture of the economic impact of waiting to launch in order to add a feature.

Obviously there are other reasons that a project may be prioritized over another project or a feature chosen over going live, but understanding the economic impact is a critical piece of the puzzle.

Understanding the behavior of the product life-cycle

Recall from Part 2 the graph below, which shows Cost of Delay over an entire product life-cycle.

 

 

p3fig1

Figure 1: Monthly profit, projected for entire life-cycle, on time vs. 1 month late

 

 

In order to estimate the cost of delay, we need to consider the behavior of the curves depicted in the graph above and the variables that can impact their shape.

First let's discuss the front end of the curves, the product launch and sales ramp-up period.

Notice the ramps on the left for the orange (one month late) & red curves (one month late with a reduced sales peak) are about the same slope as the green curve (on time to market). The ramp is shifted to the right, but the slope is the same. The slope reflects the rate of sales, which is determined by the rate at which our sales force can get up to speed on the product, advertise it to customers, win them over, and ultimately achieve sales.

Generally, the rate at which sales increase is about the same whether releasing on-time or late. Pent-up demand scenarios where the slope gets steeper if we release later, are rare. It is more likely that the ramp gets shallower if we are late, because it becomes harder to win those customers over (from the competition).

One can argue it is possible to increase the slope by adding sales people or spending more money on advertising. However, if increasing sales this way is cost effective if we are late, why wouldn’t we just plan to do the same on the "on time" curve too?

The later you are to market, the lower your sales peak

Next let's look at the top of the curve - orange curve vs. red curve. In most cases, the later we are to market, the lower our sales peak will be. There are several reasons for this.

First, during the time we are still in development, our competitors may be out there advertising, talking to customers, and winning them over. Some of the customers they ‘win’ will typically continue to buy from our competitor, even when our product is released, and even if our product is better than our competitor’s.

 

Want to learn more about how to calculate cost of delay? Download the eBook, "Profit Driven Development and Cost of Delay: A Guide for Decision Makers."
Download my eBook on how to calculate the cost of delay

 

Next, even if our competition hasn’t launched yet, they are getting closer to it. With each passing week we lose more of our opportunity to win customers who will stay with us even after the competition launches.

Finally, the market for the product may be seasonal or event driven. If we are late to market, the seasonal rush may be partially or completely over, or we may miss a trade show, or a sales meeting, and lose the associated buzz that comes with it.

These cases are common. As a result, our peak monthly profits are reduced because either our sales volumes are reduced, or we lower the sales price and reduce our margins, or both. Unfortunately, the amount of the reduced peak is difficult to estimate. To make matters worse, some people have a hard time accepting that there will be any reduction in the peak at all. Instead, they choose to believe that if (whenever) we build it, they will buy (eventually), at the same price.

When product life-cycles extend beyond 5 years, it is common to assume that every customer lost as a result of being late to market will be back to buying from us by year 2 or 3. This is not the case. The only way to catch up when sales are still increasing is to increase the slope of the ramp via additional investment in sales and advertising. As discussed previously, if this additional investment is cost effective, it should be in our baseline on-time curve as well.

Declining profits

Now that we have looked closely at the ramp-up and top of the curves, let’s look at the tail of the curve – the declining profits period.

If you forecast far enough to have a downslope, the downward ramps for both the ‘on-time’ product and the ‘late’ product are typically (almost) coincident. Think about why you have declining profits and ask yourself, “Does the downslope start later if I release later, or does the rate of decline change if I release later?” Not likely. Usually the reason for the declining profits is that our competitors will launch a better solution around that time.

When new competition arrives, either our volume drops or our margins do, or both. If we release our current product later, in today’s competitive marketplace, the downslope typically remains unchanged. There are exceptions, but they are rare.

How to estimate the lost month cost

When forecasting for an entire product lifecycle, if the ramp-up and plateau area (profit) moves to the right, as shown in orange below, and the decline area in yellow stays fixed, we lose the month in between – the peak month of sales. In fact, the green and blue areas in the graph are equal. Even if you don’t forecast for the entire lifecycle, if you forecast far enough to reach declining profits, the downslope is fixed, the ramp-up shifts, and you lose a peak month of profit. This lost month cost is some of the cost of delay. The peak month of volume times the product margin is often the easiest way to calculate it.

 

p3fig2

Figure 2: Lost Month Cost of Delay, sales projected for an entire lifecycle.

 

When we don’t forecast as far as the downslope, and sales are still increasing or have plateaued or peaked at the end of the Value Horizon, the ‘tail’ is a drop-off. The last month’s profit, shown in blue below, falls out of the Value Horizon window.

 

p3fig3

Figure 3: Lost Month Cost of Delay, sales still increasing at value horizon

 

It may seem initially like we don't really lose this month of profit, but that it has just shifted one month later. However, if we zoom-out from the curve and forecast further, until sales do decline, it starts to look like the whole-lifecycle curve. The left side (orange area) is shifted and the right side (yellow area) stays fixed and we lose the month between, which is right before we start declining – the peak month.

 

p3fig4

Figure 4: Lost Month Cost of Delay – partial life-cycle vs. entire life-cycle

 

There certainly is a cost of delaying your market launch.

For example, if the volume will peak at 200 units per month, and our profit margin is $2000 each, the lost month Cost of Delay is $400K. Of course, your volume and margin may vary from this example.

Generally, once this concept is demonstrated graphically, project teams agree with a shift in the front-end, a fixed back-end, and the peak month of profit over the forecasted period as a simple, probably conservative estimate for Cost of Delay. If you don’t count any peak reduction, this is your per-month Cost of Delay.

Interested in increasing project velocity, team morale and product quality? View the on-demand webinar about PLAYBOOK software and Methods today.

How to estimate the peak reduction cost

Determining a number for the reduced peak in profits is, unfortunately, not straightforward. It is too easy to discount the original marketing forecasts and without a solid baseline to measure actual sales against, we can’t estimate what sales would have been had we been on-time. (If I only had a nickel for every time I’ve heard someone say, “The marketing guy was smoking something when he came up with those numbers.”) The reduction in peak for many is too much of a fuzzy guess. Fortunately, coming up with a number for the reduced peak it isn't entirely necessary, as we discuss later in this post.

Although it is difficult to have confidence in the peak reduction value, there is a simple way to estimate the additional Cost of Delay due to a peak reduction. As shown in purple below, imagine a strip of area (sales profit) X% wide and as long as the forecast, where X is the peak reduction in volume or margin percentage. Values for the peak reduction are typically 1% to 5%, though it can be much higher in some cases.

 

 

p3fig5

Figure 5: Peak Reduction Cost

 

A simple estimate for the area of this strip is its average width times its length. The average width is the X% peak reduction * the average monthly profit over the forecasted time period. The length of the strip is the number of months in the forecasted time period. So Peak Reduction Cost = X% * average monthly profit * number of months forecasted. Average monthly profit is average volume (total volume divided by the number of months forecasted) times the product margin, if margin is fairly constant over time.

For example, a 2% reduction in average volume of 150 units per month is an average reduction of 3 units a month. Over a 4 year (48 month) period, we’ll sell about 150 fewer units. With a margin of $2000 per unit, that is a Peak Reduction Cost of about $300K.

As you can see, the Peak Reduction Cost can easily match or be even larger than the Lost Month Cost, especially on products with long lifecycles.

Arriving at the total cost of delay

Once you understand how to calculate the cost of one lost month and the peak reduction, the total COD can be easily estimated.

 

Total COD = Lost Month Cost + Peak Reduction Cost

 

In conclusion, even though you can easily estimate the Peak Reduction Cost, and it can easily double or triple your total cost of delay, people typically can’t agree on what the peak reduction percentage ‘X’ should be. As a result this component of total cost of delay is often ignored.

Fortunately, the lost month cost is typically enough to establish cost of delay as a valuable, understood, and agreed-to metric within your organization. And it is still generally a large enough number to have the impact that an even larger one would have. It can still lead to reducing batch sizes, building more resource availability and capacity into the development system, and throttling demand. In addition, Cost of Delay gives project teams the ability to analyze trade-offs objectively, which can really help speed up decisions, and therefore the project. 

Watch the webinar on how to build a project economic model

 

Of course there are other sensitivities you need to measure you develop you model.  We will discuss these below.  If you'd prefer to watch the webinar, here it is!

 

Estimating the sensitivity to sales volume

 

You can estimate sensitivity to sales volume in several ways. 

 

SVS = 1% * total volume * average margin per unit or SVS = 1% * total profit

or

SVS = 1% * average monthly profit * number of months forecasted

or

SVS = 1% * avg. monthly volume * avg. margin per unit * # of months forecasted

 

For example, where an average monthly volume of 150 units was forecasted for 48 months, at a margin of $2000 each, the Sensitivity to Sales calculation is as follows:

 

SVS = 1% * 150 units per month * $2000 per unit * 48 months ≈ $150K

Estimating sensitivity to unit cost

Estimating Sensitivity to Unit Cost is also relatively straightforward. To estimate it on a percentage basis, simply determine 1% of the estimated unit cost and multiply it by the number of units sold over the forecasted time.

For our example product, we have a 50% margin on our product. We sell it for $4K, our margin is $2K each, and our unit costs are $2K each. To calculate the Sensitivity to Unit Cost take 1% of the unit cost and multiply by the total number of units you expect to sell during the forecasted period.

 

UCS% = 1% * $2000 per unit* 150 units per month * 48 months≈ 150K

 

For easier decision calculations it is helpful to determine Sensitivity to Unit Cost in dollars rather than percentage - dollars profit, per dollar of unit cost reduction.

It is easy to estimate this by estimating the total number of units you expect to sell over the forecasted period and multiplying this number by $1.

 

UCS$ = $1 per unit * 150 units per month * 48 months ≈ $7200 per dollar of Unit Cost reduction

Estimating the sensitivity to project expenses

To calculate the Sensitivity to Project Expenses, determine 1% of development expenses. This number is primarily used to provide the level of scale of this sensitivity relative to the others.

Once again, when performing tradeoffs, we use dollars instead of percentages. If our total project expenses are expected to be $2.5M, our sensitivity to Project Expenses is $25K.

Need more info?  Download our webinar on project economic modeling.

 

Create My Model

Examples of using an economic model to make project decisions.

Real examples sometimes make all the difference.

Here are some to contemplate.

Example 1: Adding Resources Consider the case of adding resources to a project. For this example, using accurate, live plans and an understanding of resource criticality, assume we are able to estimate that adding 2 resources for 6 months would save us 1 month on the schedule.

Launching one month earlier makes us $400K more, while the additional cost of resources is $200K (2 * 26 wks * 40 hr/wk * $100/hr). There is payback, but it’s slim – the ROI is only 1-to-1. As such, it may not be worth spending the money on additional resources, if we can make more by investing it somewhere else.

 

Profit Increase = $400K - $200K = $200K


ROI = $200K / $200K = 1-to-1

 

Example 2: Prioritizing Projects

Say we had a critical resource we may choose to share across two projects – Project X and Project Y. Project X has a COD of $100K per week. Project Y is a cost-reduction on a currently shipping product with a COD of $5K per week. Project X is expected to keep our resource busy for another 6 months.

Project Y expects to use our critical resource for 80 hours. Our resource’s availability to perform Project X work assigned to him is currently only 50%, 4 hours per day, after all of the meetings and interruptions and coffee breaks in an average day. 80 hours spent on Project Y will delay Project X by 20 days, or 4 weeks.

If we do Project Y we delay Project X by 4 weeks. Cost of Delay of Project X is $400K. If we defer Y until our critical resource is available in 6 months, we delay Y by 6 months (24 weeks) Cost of Delay of Project Y is $120K. Deferring Y makes you $280K more. 

To calculate ROI, if you say the $5K per week extra you are spending on parts in lieu of Cost Reduction, Project Y is money you could invest in other projects or other decisions, the ROI on the decision is (400K-120K)/(120K) = 2.3-to-1.

 

Profit Increase = $400K - $120K = $280K


ROI = $280K / $120K = 2.3 to-1

 

Check out our series of posts on calculating Cost of Delay. We also have a free eBook that will show you how.

 

Download my eBook on how to calculate the cost of delay

 

Want to build your own economic model?  Watch our webinar on how to do it.

  Create My Model