All software work is time sensitive and there is a real cost of delay.  The speed at which new or improved software is implemented matters. Always. Being the first to implement an innovative capability can be be the competitive edge that makes one company thrive leaving its competitors to struggle.

“speed and security are the keys to remaining competitive in the banking space”

Saul Van Beurden, Head of Technology of Wells Fargo

The business impact of getting some functionality delivered quickly (and safely) is significant – and usually dwarfs the cost of doing the software work. Most businesses have plenty of ideas but insufficient capacity to implement them all. So, a measured approach is needed to work out what to do first, and how to do it quickly and how to do it safely.

Generally, we want to do the most valuable jobs first, as they will deliver the most value. Sometimes the most valuable jobs are large and complex. So by looking at both the value and size, we can refine our prioritisation by targeting the smallest most valuable jobs to deliver the most value, quickest and for the least cost.

Given that the business value of a timely delivery is usually far greater than the cost of building the software, it makes sense to look at the value first, and cost second. Understanding the value of a timely delivery is easiest to estimate and compare (with other features) if we instead look at the cost of a one month delay.

Focus on the business cost of delay

The real cost of delay

For each capability/feature ask the question”

“how much is it worth if we deliver one month earlier”

In some cases the cost of delay might be modest, but for certain innovative capabilities, the delay cost can be high and in some cases can be so significant as to make a material impact on the business’s bottom line. We recommend that you apply a financial value to the one month delay (it’s an integral feature of ScopeMaster’s Value Tracer).

The cost of delay may not be linear (ie. will two month’s delay be twice the size of one months delay), but for simplicity’s sake we might assume that it is.

By focussing our attention on the real business cost of delay (and finding ways to reduce it) we find ways to deliver more valuable software faster. For more on the fundamentals of C.O.D., check out Jim Haydn’s illustrated article on the cost of delay

The process is as follows:

  1. Determine the quantifiable business outcomes that we are seeking to achieve overall
  2. Determine which capabilities are needed to achieve that outcome
  3. Estimate the cost to the business if a feature is delayed (by one month)

As part of this final step, you may also need to consider :

  • The business risk of doing this feature later.
  • What other features depend on this and the cost of the delay of those.

Ideally, when we refer to cost and value above, it is best practice to use an absolute value, such as $x per month. Relative indicators (as apposed to currency values) are less helpful but sometimes unavoidable. We always recommend the financial value over relative ones as they help to make the decision-making of priorities more transparent. Always try to apply a currency value to the cost of delay. We find that wrapping up these factors into a single value of $ per month of delay is a simple effective way to focus attention.

Weighted Shortest Job First (WSJF)

So far we have only looked at the value of a timely delivery (i.e. business cost of delay), we have not considered the cost of delivering that feature. The cost to create the software is (or should be) comparatively small compared to its medium term value.

The WSJF approach takes into account both the cost of the delay and factors in the cost/effort to deliver the feature.

Weighted Shortest Job first with ScopeMaster

The COSMIC Function Point size of a feature is an excellent means of estimating the cost to deliver, as there is a high correlation between CFP size and effort (i.e. cost). Thanks to ScopeMaster’s unique ability to estimate functional size, we simply take the cost of delay and divide by the CFP size to give us a relative priority for each feature/epic – this number is the WSJF value.

WSJF = Cost of delay / Cost to deliver (CFP)

ScopeMaster makes it trivial to get an indication of WSJF, as it already estimates the functional size (CFP) and by proxy, the effort to create your user stories. By using a currency value for the “Cost of Delay per Month”, ScopeMaster will help you prioritise your Epics/Capabilities accordingly:

When is the cost of delay highest?

There are four main scenarios that tend to have very high costs of delay.

  1. Innovation opportunity
  2. Competitive catch-up
  3. Costly bug or security problem
  4. Burning platform

If the capabilities that you are looking at fall into one of these categories you will find high costs of delay – and therefore a good reason to prioritise that capability:

Lets look at each one more closely:

Innovation opportunity

This is the delivery of a new feature or capability that would differentiate your organisation in the market place and have lasting competitive value. e.g. in the financial sector, you might want to be the first organisation to offer a new form of payment. This could cause customers to switch to using your offering for all their transactions and have a disproportionately high value opportunity. Being late to deliver could mean that you are an also ran.

Competitive Catchup

Your competitor has released a new feature and is winning clients faster than you, or perhaps you are losing business to them because of it. Every day of delay could be more business lost.

Costly bug or security problem

You may have a system bug that is actually costing you customers/business/loyalty, every day that this is not fixed is damaging your brand.

Burning Platform

You are facing a fixed deadline, perhaps a regulatory one or some technology will stop working at a given point in time. If you don’t deliver the functionality in time, you may face a very costly scenario.

Delays and removing them

Not only does the WSJF approach helps us prioritise work, it also focuses attention on other things that affect the time to delivery.

In some organisations even small jobs can take a long time to get done. In fact, in most organisations, even a few hours of coding work can take days or even weeks to get put into production. It’s not just the development, testing and deployment process but the approvals, delays, queues and holdups in between. Time is money, and these delays can be very costly to the organisation.

To remain competitive, we need to reduce these delays and still concentrate on the most valuable (and smaller) jobs first.

In many organisations the waiting time for work exceeds 80% of the total time taken. Only 20% of the duration is actually spent doing the work. If we are not looking at the cost of delay, we may be unaware of the real impact of long waiting and queuing times.

So how do we go about solving this problem? Firstly, we need to understand the value of the work that we are working on and the cost of delays in getting it done. Once we articulate this we can then drive the change in behaviours to remove the bottlenecks. This helps us to:

  1. Make better decisions, exposing the economic tradeoff of delays,
  2. Prioritise work (WSJF), deliver maximum value fastest for a given capacity.
  3. Change focus from “dates and effort estimates” (game-able) to productivity and value.

In conclusion, we need to change the language and focus towards delivering functionality on time by quantifying the cost of delay to deliver a feature by one month.