The term cost of delay tends to lead people to think about extra costs incurred because something is delivered late, as in using express shipping because manufacturing took longer than expected. But extra costs—a form of waste to lean thinkers—are often dwarfed by revenue forgone because a product is not in the market earlier.
This lost revenue is usually not considered because it was never seen in the first place, but it is real. Cost of delay includes missing out on sales due to such things as the customer finding an alternative solution, missing some critical date, or losing out to rivals (retaining such sales is sometimes called revenue protection).
And of course, if you spend less time developing a product, there is every possibility that the costs of product development will be lower, too.
Yet I find the concept of cost of delay from any of these sources is often too abstract for most people. This changes quickly if you write a number—almost any number!—on a story.
For example, you could write 10,000 on a development story and tell the development team, "This story is worth 10,000 if we deliver it tomorrow." Next you could ask, "If we deliver it a week later, would it be worth more or less than 10,000?" Developers will answer that it is worth less, which allows you to ask, "How much less?" Say the answer is "Just a bit less," so you might write "+1 week: 9,750."
You can repeat this process for different intervals: one month, three months, six months, a year. That allows you to construct a graph that I call a time-value profile, as shown in the figure below.
The time-value profile shows the value for a given piece of work at different points in time and how that value changes. This graph is useful in itself, but it can be even more useful.
Communicating Value
If you pick up a carton of milk you will find a "use by" date. After this date the milk might be off and should get thrown away. In our terminology, it becomes valueless.
Some foods have a "best before" date instead. Such foods lose much of their taste after this date. Essentially, the producer is saying, "After this date the product isn't going to give the same benefit as before the date, but it is not worthless."
Adding "use by" and "best before" dates to the time value profile communicates the product’s value even more clearly. Whether you want to do this is a judgment call, but by having the discussion about such dates, teams can build a better shared understanding.
Starting a Conversation
Armed with this information, the team’s view of their development projects changes. The business story with the highest value might not be the one to tackle first if the "best before" date is some way off. Another, lower-value story with a closer “best before” date would be the better choice.
Projects are little more than a bundle of deliverable items, and different items can have different time-value profiles. Rather than aiming to deliver the whole project by one date, it might make sense to deliver increments in the order they maximize value.
For instance, a project the team is waiting to start might contain items that have a high time-value dependency. Failure to deliver these items soon would cause them to lose significant value, so it makes sense to deliver these items quickly—maybe even before the final items of the current project are complete.
Engineers can consider what they can build in the time available. In a market with a time-critical date, like the end of the tax year, it can make sense to build something smaller that enters the market sooner. Building a product with less functionality that will go on sale sooner and only captures a small part of the market may well deliver higher revenue than a larger, more functional product that enters the market later, even if the larger product captures a larger percentage of market share.
Similarly, in a rapidly growing market, entering sooner with a smaller product might give first-mover advantage. But in a growing market where first-mover advantage has already passed, entering later with a more functional product might be a better strategy.
Inverting Estimation
Once your team starts thinking this way, the whole basis of estimation becomes inverted. Rather than estimating how long work will take to complete, it makes more sense to estimate the time-value profile and determine what work needs to get going. Engineers can then work backward within these constraints to determine what to build in the time available.
Engineers faced with a three-month window of opportunity will plan and build a very different product from engineers faced with a twelve-month window. Knowing the engineering options and the time-value profile allows engineers and business representatives to have meaningful conversations about options and value over time.
Time-value profiles also help with the old "I need it yesterday!" problem. People on the business side of things will say this to engineers to get them to give priority to a project. But if the need was yesterday, and the need has gone, then the time-value profile shows no value for today.
If all the value accrued yesterday, then delivery tomorrow (the earliest possible delivery date) is valueless. But in reality, most "yesterday" demands still have value tomorrow, and the day after—they may just look different:
You no longer need a time machine to deliver any value for this project. After talking with the business side and determining the above time-value profile, everyone should realize that instead of rushing to deliver a project with minimal value, it would probably be in everyone’s best interest to wait and aim for the next period of higher value.
Understanding Deadlines
Once you have a time-value profile for a feature or product, it becomes obvious that deadlines are not binary, all-or-nothing events. Deadlines are elastic by value: Delivering your product on different dates results in different outcomes, different values, and different costs and revenues.
There are genuine trade-offs to be made between how much product is built versus how much of the market is captured. This needs to be a discussion between those who understand the market and those who understand the technology. Knowing the time-value profile can help expose some of these trade-offs and get the conversation started.
