In Part 1, I explained the various Costs of Delays with this image:
I explained how to calculate the salary costs in Part 1. Now, it's time to calculate/assess Costs 2, 3, and 4 to decide on the most valuable work. (If you have Manage Your Project Portfolio, there's an entire section about calculating and ranking with Cost of Delay.)
Here's how to calculate the various costs.
How to Calculate Cost 2
Cost 2 is the lost revenue from a delayed introduction.
See those red lines pushing out that lower S-shaped curve? The red lines explain the time for Cost 1, paying people's salaries. But those same red lines explain how long it takes to start to get the expected sales.
Let me put some numbers on these costs. Assume that each person on your 6-person team has a salary of $100,000/year. That's $2,000/week/person. (I'm using easy-to-see data, not your data.)
Now, assume you need four more features and you think your cycle time is one week. That's a four-week delay. (Notice, this is not the same as order-of-magnitude estimate I suggested in the first post. I'll talk more about that in Part 3 of this series.)
Let's use a trivial example. Say your product costs $1000. And you think you can sell 50 of them the first week, 100 the second week, 200 the third week, and 300 the fourth week. Then, you continue to see 300 products/week until the product starts to descend into it's EOL (End of Life).
Since sales still have to ramp up, we calculate Cost 2 by saying that's 4 weeks of delay time 300 units * $1000/unit. (Remember that Cost 2 takes the maximum sales, not the initial weekly sales.) Cost 2 for each week is 300 * 1000 = $300,000. For four weeks, that's $1.2 million of cost due to lost sales.
Cost 1, where you have to continue to pay people's salaries, a four-week delay costs you $2000 * 6 people * 4 weeks. That's $48,000.
The four-week consequence of not making a choice and trying to make progress on “everything” costs you $1.2M in delayed sales plus Cost 1 of $48,000. The longer your delay, the more the delay costs you.
I Mostly Ignore Costs 3 and 4
Generally, when I explain this, no one cares about Costs 3 and 4, because the magnitude of Costs 1 and 2 shock the decision-makers. When I talk through Costs 3 and 4, people sort-of remember their calculus, the area under the various curves. But they realize those costs are effects of more delays. The faster the team can ship the product (or a specific feature), the lower Costs 3 and 4 are. (Yes, costs are all about feedback loops and cycle time.)
Also, Costs 3 and 4 are totally predictive, based on our wishes, not facts. While we might be able to predict expected sales for the product's life, I've always been wrong trying to predict EOL for a product. Either the useful sales end much earlier or much later.
Yes, Cost 2 is a predictive cost. However, especially if it's only for a few weeks to a few months, our current sales insights can be useful. The farther out those sales insights, the less predictive they are. (See the Weibull model in What Model Do Your Estimates Follow? for my reasoning.)
However, Costs 3 and 4 are so far outside any reasonable prediction for my clients and me, I tend to ignore these costs.
So far, I've discussed costs for a commercial product where we have direct revenue. What about adoption, indirect revenue instead? Or products/features that enable something in a specific time period, but not revenue?
Adoption Delay Might Have Worse Costs
I told the story of how a separate deployment team with a broken build system caused many, many costs of delay in How Value and Cost of Delay—Not Cost Savings—Applies to Centralization Decisions, Part 2. If you still have centralized or “shared services” people, you will also incur many costs of delay. (Yes, there's a lot more on this Create Your Successful Agile Project and Practical Ways to Lead an Innovative Organization.)
In the case of the broken build system, 3000 people often waited three weeks for clean builds. The salary costs were enormous. Worse, the company needed to EOL that product and move to a new product, but they couldn't. They had to keep supporting the old product and not do enough work on the new product.
They had made two fatal decisions:
- Because they created a centralized deployment team, no team could release their finished work when they finished. That increased everyone's WIP and increased the feedback loop durations for every team.
- They thought they could shortchange the necessary updates to their infrastructure. Why? Because infrastructure is not customer-visible.
However, these decisions made their Costs of Delay enormous.
We estimated they spent $5.4 Million every week because their build system was so broken. Yes, over 5 million every single week. (The larger the organization, the more money the organization wastes on multitasking.)
Aging is Another Form of Cost of Delay
Use that same thinking for meeting a specific date. For example, years ago, I was the (contract) program manager for a product that had to demo at a trade show. If we missed that deadline, even by a week, the potential customers would never consider buying anything from the company again. (Way too many missed deadlines.) That was the leverage I needed to show the managers this graph of when we needed people full time on the project and when we got them:
At the time, I did not know about Cost of Delay, but I knew multitasking was killing the program and that we would not make the date. (I wrote about this in Manage It! and More on Creating Faster Cheaper Projects.)
Now that you have Costs 1 (salary costs from the delay) and Cost 2 (the product costs from the delay), you can determine the most valuable work.
I clearly need another post for how to rank. That's next.