Cost of Delay has become a popular component of a variety of calculations intended to yield information that aids in making decisions about the optimal development order of multiple items (e.g. product features), based on economic data. However, there are several different ways to apply CoD, and sifting through them can get complicated in a hurry. This article discusses a simpler method for prioritizing product features based on relative value.
What’s in a name?
Opportunity cost means “the cost of a lost opportunity.” Investopedia defines opportunity cost as: “The cost of an alternative that must be forgone in order to pursue a certain action. Put another way, the benefits you could have received by taking an alternative action.”
Cost of Delay (CoD) is a specific type of opportunity cost. If that cost is a result of delaying an action in time (e.g. moving a project’s start time back by a couple of weeks), that’s CoD.
It is important to remember that, despite the name, CoD is often not actually a cost at all—it’s more accurately described as potential revenue. It can seem like a cost, perhaps because it’s fairly easy for us human types to think of money we could have earned as money lost, but it’s really unrealized revenue. (An exception to this: If a service you use is currently costing you money, and you decide to get rid of it to save money, but you don’t do that right away, that’s a Cost of Delay.)
I’m reminded of an exchange from the Marx Brothers movie, Animal Crackers, between Captain Spaulding (Groucho) and Ravelli (Chico) in which Mrs. Rittenhouse has hired Ravelli’s orchestra to play at her Long Island party:
Mrs. Rittenhouse: You are one of the musicians? But you were not due until tomorrow.
Ravelli: Couldn’t come tomorrow, that’s too quick.
Spaulding: Say, you’re lucky they didn’t come yesterday!
Ravelli: We were busy yesterday, but we charge just the same.
Spaulding: This is better than exploring! What do you fellows get an hour?
Ravelli: Oh, for playing we getta ten dollars an hour.
Spaulding: I see…What do you get for not playing?
Ravelli: Twelve dollars an hour.
Spaulding: Well, clip me off a piece of that.
Ravelli: Now, for rehearsing we make special rate. Thatsa fifteen dollars an hour.
Spaulding: That’s for rehearsing?
Ravelli: Thatsa for rehearsing.
Spaulding: And what do you get for not rehearsing?
Ravelli: You couldn’t afford it.
My point is that calling CoD a “cost” can be misleading in that, just as in the Marx Brothers’ universe, you might run up a pretty large bill by having no work done. Avoiding costs is a big part of any business, but simply calling something a cost doesn’t make it so.
If, for example, your organization releases individual features when each is ready, and each feature starts generating revenue fairly soon after release, then you can use a method incorporating CoD to assess the lowest-cost order in which to release those features. In this case, treating potential revenue as a cost makes sense.
If, on the other hand, your organization releases collections of features on a regular calendar schedule, and you want to ensure that the most valuable features are developed first (assuming that all features may not be completed by the deadline), then you can use an alternative prioritization method based on the relative values of features. Assigning costs of delay to individual features is less appropriate, and perhaps a little confusing, because changing the development order of any of the features that are developed in time for the release has no effect on the overall cost. Revenue begins accruing only after the entire collection of features gets released, so Cost of Delay has little meaning in this case.
An alternative prioritization method
All we really need to do for the second case above is to determine the relative values of all the features we wish to include in a release, and develop them in highest-value-first order. It doesn’t matter what the actual values are—we just need to know how the features rank compared to each other.
There are 2 components involved in calculating value, and these are benefit and cost. There are some very simple ways to estimate both benefit and cost. Indeed, it’s easier to estimate relative benefit and relative cost than it is to estimate either of those in absolute terms.
Revenue is one example of benefit, but you might not be able to predict how much money, in absolute dollars, a particular feature will bring in. It’s easier to estimate in relative terms (e.g. “I think feature A will bring in about 3 times as much money as feature B”). We can estimate the relative benefits of each of a collection of features pretty quickly. Using a team-oriented exercise to do so lets us get consensus on what is more beneficial and what is less so.
Cost is proportional to the time spent developing a feature, and in a way that is probably counter-intuitive to many people. As it turns out, the cost to develop a feature is directly proportional to the amount of time that feature is worked on by the pacesetting operation. (The pacesetting operation is also known as the process bottleneck.) We can estimate the costs of features in relative terms (e.g. “I think that feature B will take about twice as long to develop as feature A”). Here again, we can get consensus on the relative costs using a simple exercise that leverages the knowledge of the team.
Dividing relative benefit by relative cost yields a ratio that can be thought of as a value index. The value index serves as a basis for quickly assessing relative feature values. The greater the index, the higher the value.
- Cost of Delay is often not a cost at all.
- Calling something a “cost”, when it isn’t, can be misleading.
- Releasing revenue-generating features one after the other is a good case for using Cost of Delay to determine development order.
- When releasing a collection of features, prioritizing by relative values is a good method for determining development order, especially if all of the features might not get completed by the deadline.