Skip to main content

Cost of Delay. Can It Be Quantified?

Reading: Cost of Delay. Can It Be Quantified?
Cost of Delay. Can It Be Quantified?

Most organizations are struggling to determine how much revenue any given project is going to create; therefore, they need some other criterion to prioritize their backlogs. That’s the reason I see companies turning to Cost of Delay (CoD) more and more. Often, I overhear people talking about CoD like it’s some mathematical formula where they can crunch tangible revenue numbers, get an output, and that everyone is just going to get it. In my experience that hasn’t been the case.

The reality is that in most cases the CoD is more than just dollars. The cost is usually something more ambiguous, as Jim Hayden alluded to in his blog post, and this is where people get all twisted up.  They have a hard time assessing the value of features that don’t have an exact dollar amount tied to them.

The Elements of CoD

So, how does an organization determine the cost of delaying a project, or the cost of not doing the project at all, when there is an indeterminate financial outcome? Even if they can make that determination, how would they decide on what to do next?

In Principles of Product Development Flow, Don Reinertsen asserts that the CoD can be blown out into the following three parameters:

  • User Business Value
  • Time Criticality
  • Risk Reduction and/or Opportunity Enablement Value

He states that User Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement Value equals the CoD

Weighted Shortest Job First

In his book, Reinertsen also introduces a model that will allow your organization to weigh the importance of each new project and enable you to make an educated decision on which is the next most important thing. He calls this model: Weighted Shortest Job First, or WSJF. Basically, WSJF equals the CoD divided by the Job Size.

Here’s an example table that you can use to determine your WSJF numbers. You will rate each feature relative to the other features on the list, using the three parameters that make up COD.

Determining Value 

Now that we have an established baseline formula, and a means by which to visualize it. How do you determine the appropriate value of each parameter? What’s the unit of measurement? I like to do it the way I do story pointing. I’ll get the product owners and a few lead tech guys around a table and we will begin to assign points.

I like to use a Fibonacci Scale, cap it at 20, and take it one column at a time. You’ll look at the feature and give the Business Value a number, Time Criticality a number, and then the RR/OE Value a number.

Once you’ve determined those numbers you can calculate a point total for CoD, divide it by the Job Size, and get your WSJF number. Once you have the WSJF number, you’ve successfully determined the next most important thing to do.

A lot of times when I introduce this model to one of my clients, they push back and tell me that it feels like they’re just making random decisions. However, keep in mind the importance of each parameter can be subjective. The actual value of CoD may not even be mathematically quantifiable, but that’s okay.

Shared Understanding

CoD and WSJF are only meant to be used for guidance on how to do prioritization. It doesn’t really matter that we are pulling numbers from our collective consciousness, what matters is the relative comparison of one thing to another. Applying this technique allows the decision making to be influenced by the team. It opens a conversation about why one feature has a twenty and another one has a five.

What truly matters is that everyone on the team agrees with what’s on the list and that they all have a share understanding of the points awarded. It has been my experience that when you have a team of people that are all in the industry and have the best interest of the company in mind, more than likely the decision made is the decision that’s best for the organization.

This model is just one way to do prioritization, but there are others. Sometimes, especially in small, lean startups, I’ll see people using Gartner reports, or looking at their perceived market share to make business decisions. Often, they are acting on instincts and using fuzzy numbers to justify investments. The CoD/WSJF model is a good way to clean up a backlog in the absence of dollar amounts. So, if you’re having trouble measuring value I say….

In the words of Reinertsen, “…if you’re going to quantify one thing, quantify the cost of delay.”

Free Download of the WSJF Calculator

Download this interactive Excel Spreadsheet of the WSJF Table discussed above, so that you can use to determine your WSJF numbers within your own organization.

Next Student Q&A: Dealing with Architecture in Agile w/ Devin Hedge

Comments (4)

  1. Keith Gillespie
    Reply

    Enjoyed reading the article Marty. I have been looking for better ways to move prioritization beyond gut feel or subjective thoughts. This seems to give a nice way to weigh objectives against one another and more importantly get everyone talking about the priorities in a more subjective way to deliver more value.

    Reply
  2. Brad Black
    Reply

    The is the SAFe definition for cost of delay—not Reinertsen’s. SAFe’s formula isn’t in Reinertsen’s book.

    Reply
  3. Michael Litton
    Reply

    Well, in Donald’s book and several talks you usually start out with a parameterized business case and do a sensitivity analysis on it with respect to time. This can be simple models such as cost-benefit or more sofisticated ones.

    You can quantify your deliverables in dollars and you should. Start by looking at the four categories “Increase revenue”, “Protect Revenue”, “Reduce costs” and “Avoid costs”. Then use Fermi decomposition to get a better understanding of your drivers. Figure out the “Expected Value of Perfect Information” and invest accordingly.

    When an organization is used to this more economic approach it usually goes quite fast and should always be done on the portfolio team level and occationally on lower ones.

    The approach suggested here is not a sound one. It’s for people that have not learned how to model decisions properly.

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *