A brief note, much of this content leverages and is inspired by the material on cost of delay that can be found at Blackswanfarming.com, is an excellent resource for understanding cost of delay.
It’s authors Joshua James and and Ozlem Yuce, are incredibly insightful on this topic. I personally have had the privilege to go through one of their sessions, and it completely changed my perception around how to use Cost of Delay. Also the material has been much improved through feedback by Jeff Kosciejew and Ellen Grove.
Cost of Delay Puts a Price Tag on Time, Creating the Urgency to Deliver Things with More Frequency
One of the reasons we tend to turn to agile methods, is because we are trying to deliver value in an environment of high uncertainty. We are unsure if what were building is solving a problem that our customers care about, and we don’t know for certain if our solution will effectively solve that problem. To combat this uncertainty we want to gain feedback quickly on any solution we create.
Another reason people turn to agile methods is to take advantage of gaining value from a particular solution as quickly as possible. We use specific strategies such as reducing delay and breaking up work into smaller, minimal version of a solution to get our solution into market as fast as we can, leading to better economic outcomes.
In traditional approaches, there is a tendency to focus on efficiency, and the maximization of utilization of our resources and people. However, when either uncertainty is high, or an advantage exists to gain value from releasing a solution earlier, than the correct response is to focus on minimizing time. As stated in my previous post on thinking to live differently about delivering value, time, not utilization, is your most precious asset. Delay, i.e. the total amount of time that potential value is not being worked on becomes your most expensive liability.
A Brief Description of Cost of Delay
Cost of Delay provides a way for us to quantify the impact that delaying a particular piece of work has on the value being provided by that work. Typically expressed as the amount of value lost, or not received per unit of time that a piece of work has not been deployed, Cost of Delay, encourages us to prioritize work based on the decay of value over time. It encourages our people to take a hard look at the impact of delay, and identify and eliminate the sources of that delay.
When working with agile teams, Cost of Delay can be applied to an Epic, Feature or particular release. Cost of Delay can be represented as a number (value lost /time increment), as well as a slope showing the relationship between time and loss of value. Order of magnitude differences of the slope can be represented using a Cost of Delay profile (also known as an Urgency Profile).
Looking at Cost of Delay Helps Us Focus on the Economic Impact of Time over the Impact of Utilization
For organizations trying to increase agility Cost of Delay is particularly compelling. COD makes impact of queuing clear. Cost of Delay gives us information that can motivate us to optimize our system to deliver more value by reducing the impact of delay.
Take an example where we have identified a Customer Travel Abroad Feature with the cost of delay being $187,500 per week ($750,000 per month). The value stream below illustrates the progression of this feature through an organization’s system of work:
if we look at how much queuing costed this organization we can see, that the 10 weeks that this opportunity spent waiting in various queues cost the organization $1,875,000 in lost revenues. This is not an unreasonable scenario in many organizations. We can infer that even a small reduction in delay time would have a dramatic impact on the total value delivered. Perversely, most organizations still focus on trying to squeeze utilization and efficiency out of their people. What this perspective provides is evidence that our focus is better spent on trying to reduce the delay in getting value out to market.
Much of these points, are summarized in an excellent video by Joshua Arnold, I highly recommend looking at it.
Getting Started with Cost of Delay Using Urgency Profiles
A simple, effective way to get started with Cost Of Delay is to simply look at the backlog of un-started work, either at the team or portfolio level, and categorize increments of value according to an urgency profile (otherwise known as a Cost of DelayProfile). When working with more traditional organizations, it can often be difficult to assign COD profiles to an overall program or project. It is encouraged to try to break up the overall project in the various increments of work, and evaluate the COD for each increment.
Organizations are encouraged to come up with their own profiles, however there are a standard set that many use which are as follows:
Work categorized as expedite is thought to have a severe and immediate impact to business. If this work is not immediately addressed, a major opportunity is perceived to have been lost.
Example: Our customer’s privacy is exposed until we make this fix
Value categorized as fixed dated can have medium or high impact to the business. The important question to ask when categorizing something as Fixed Dated is “will delivering this work have any value before after a particular date?” People tend to get very confused around what is considered fixed dated and what is not. If you promise to deliver something by a certain date, but there is value in the work if that date is not met, then the work is not fixed dated. Conversely if you’re going to get find a particular amount of money based on an audit t, and that audit is going to happen at a certain date, than the work used to respond to that audit can be considered fixed dated. If you fail to do the work by the date of the audit, you will be fined, and there will be no value in deploying that work.
Example: Our Christmas Marketing Campaign had better be done before Christmas
Most work falls into the category of Standard Class. Work of this type has incremental, and often immediate impact to the business. The decay of value is often linear. New features, risk reduction, and cost-cutting all fall into this urgency profile. Every week that you do not deploy a new feature to your users, is a week that you cannot charge for that features use.
Example: For every day that our customers can subscribe online, we will get more paying customers
When we use the Intangible Profile, we are saying that the work to be conducted has no real recognizable medium-term impact to business or customer value. Intangible work represents activity required for organizations to deliver value that they are currently unable to deliver right now, as well as work required to improve existing value creation capabilities. In other words, working on Intangible items is incredibly valuable and important, however the delivery of this type of work typically cannot be quantified in terms of immediate Cost of Delay.
Example: Once you have finished migrating our solutions to our internal technology team, we will be able to deliver application features using local people, and have the autonomy we need to deliver at market speed
Reduce Overall Risk in Your Portfolio by Allocating the Backlog across a Balance of Cost of Delay Profile
When agile teams start experimenting with Cost of Delay, they often begin by categorizing and color coding the features/releases according to a particular cost of delay profile. Each Cost of Delay profile can be thought of as representing a different category of risk being incurred when starting the work. For this reason, organizations often start trying to load balance the backlogs across the different Cost of Delay profiles. This is typically done at the portfolio level across a set of teams.
This limiting of inventory/load-balancing is often managed visually using a Kanban system.
Estimating Cost Of Delay
Cost of Delay provides an excellent framework to estimate value. Before getting into the details of how to do this, it’s probably worth spending a bit of time talking about the mindset required to effectively deliver value. Many organizations tend to swing from one extreme to the other. On one extreme people can feel that trying to quantify value is too difficult, that value is too ambiguous, and hence do not even try to estimate value beyond the vaguest of terms. On the other extreme, people can spend a large amount of time going through an onerous amount of detail trying to come up with an artificially precise estimation of value. Neither of these positions are optimal, what we want to do is increase the amount of thoughtful dialogue we have around value, and do this across people who bring a number of unique perspectives to the table.
When organizations are trying to improve how they deliver value, they can significantly move the ball forward by:
- bringing together cross functional groups together to estimate value
- breaking up that value in smaller increments
- making assumptions explicit when estimating the value
- articulating delay, as well as the impact of that delay
Begin Estimating Cost of Delay by Selecting a Value Type – a Simple Way to Assess the Economic Impact of the Investment Decisions We Are Making
Once we have assigned a cost of delay profile for a particular feature or release, consider allocating one of four value types. Value types allow us to quickly understand the source of value for the work that we are doing, making it easier for us to come up with a quick model to quantify the cost of delay for the work.
Once we agree upon both the cost of delay profile as well as the value type, we can start to estimate value by modeling and quantifying the exact cost of delay over time. Shown below are a couple of examples of models that could be derived from a particular value type.
Turn Estimating Value into a Safe Team Exercise by Making Assumptions Explicit
When building a Cost of Delay model, it is important to emphasize that we are not trying to create a finely detailed, precise model based on certain knowledge. Rather, we are trying to encourage people to surface assumptions that go behind the estimation of value. It is these assumptions, and our certainty behind these assumptions that are what’s important. These assumptions are more important than the actual numbers that we come up with. In a typical Cost of Delay estimation session, we would encourage a cross functional group to list assumptions behind each variable in in their Cost Of Delay model. We would then ask the team to rate their confidence behind each of these assumptions, and list key questions that need to be answered in order to increase confidence behind these assumptions. Next steps would include trying to invalidate some of these assumptions, and answer some of these questions go to sleep using good agile estimation principles that you encourage dialogue and dissent through discussion with the other members of the organization who may have a differentiated perspective. Using good agile estimating principles, the idea is to encourage dialogue and dissent, but time-box it!
Example:
Shown below is a quick cost of delay estimation worksheet that can be used to quickly estimate the value of a collection of business valued features or releases.
On my next posts I’ll give an overview of how to use CD3, (Cost of Delay Divided by Duration) to effectively prioritize your backlog of work.
