How Do You Calculate the Cost of Delays?

Have you ever worked on a software project that ran past the deadline?  Just kidding.  I don’t actually need to ask.  Of course, you have.

But then again, we all have.  It’s just an apparent hazard of working in the industry.  The only way not to wind up late, on a long enough timeline, is never to actually have deadlines.

In a sense, the agile movement has encouraged us to minimize, if not eliminate, deadlines.  Establish a steady pipeline of incremental value delivery, and ship something to production every couple of weeks.  And that does a great job of eliminating artificial deadlines.

But real-world deadlines still intrude.  Competitors bring things to market.  Or else you have that trade show coming up.  In the competitive business landscape, there’s always something driving you to hurry.

The Cost of Delays

When you’re in the thick of a project running behind schedule, you can lose sight of everything but your own hustle to make up time.  You put in some long hours and then you hope for the best, pitching in where you can and trying to help.  But what does the missed deadline ultimately mean for the team and for the organization?

Or, to get down to brass tacks, what does the delay really cost?

It’s hard to say, a lot of times.  In the first place, you’re dealing with a lot of concepts that are nebulous and hard to measure.  Beyond that, people generally plan to hit their deadlines, so (at their peril) they don’t often spend as much time projecting the cost of misses.

But let’s do that today.  Let’s look at how you can calculate the cost of delays in software delivery projects.

What Counts as Cost?

Before I get to the calculation particulars, it’s important to establish some categorizations of cost.  That will help the rest of the post go more smoothly.

When talking about the cost of delay for a project, I’m going to be talking only about the cost associated with the actual delay.  If that sounds redundant, let me clarify with a couple of counterexamples.

• Extended labor costs.
• Opportunity costs.

By way of narrative, think of planning a project to build a piece of software.  You assume that it will take 3 months, so you assemble a team of some staff and some staff augmenting contractors.  All of these folks set about building the software but, lo and behold, it takes 4 months instead of 3.

Now you’ve paid the contractors 33% more for hourly labor than you thought you would.  You’ve also tied up your staff 33% longer, preventing them from going to work on the next great thing in your company for a month.  These are both significant costs, and both matter a lot to your organization.

But neither is a cost associated with delay, per se.  And I’m not going to talk about them any further, since they’re both relatively easy to quantify and more a cost associated with missed planning rather than with the actual delay.

An Internal, Bottom-Line Saving Project

Moving on from what I won’t cover, let’s get to the meat of things.  The cost of delay will depend a lot on the particulars of a project, obviously.  But it does help to group them in terms of the benefit to the company because delaying that benefit is what causes the cost.

First, consider a relatively simple project that you do internally.  Projects like this are meant to promote efficiency and thus cut expenses from the bottom line.  Some examples might include

• Automating something employees do manually with data entry.
• Implementing some kind of cloud solution to stop the company from having to ship physical items.
• Migrating from a complex, internal accounting systems to a COTS product that saves time significant time and prevents accounting errors.

Whatever the particulars, these projects make doing business less expensive.  And a company undertaking such a project will have a good idea of how much less expensive, probably in absolute terms and recurring monthly terms, as applicable.  Somewhere, you’ll find a statement like, “Doing this should save us $10,000 per month in labor and material savings.”

So find that statement, wherever it lurks.  Then multiply the savings per month times the delay in months, and you’ll have your cost.

A Simple, External Project that Adds to Top Line

Next up, consider a fairly similar scenario.  Instead of an internal utility to automate data entry and reduce cost, you’re putting out something external that helps to increase revenue.  Examples of that might include:

• A new offering that represents an upsell to your existing customers.
• A site improvement that will yield more simultaneous traffic and thus more revenue.
• Adding a new geographic market to your offering.

In any such case, you’re working on something that, when released, will bring in more money.  So every week or month you don’t release it, you don’t get that money.  This is your cost of delay, and as with the last scenario, it’s pretty straightforward to calculate.

A Promised Deliverable

Let’s switch gears a little now, and look at a different style of project.  Up until now, no other parties have really entered the mix.  If you’re working on a project to make more or spend less money, delays hurt, but only relatively.  You’re just tolerating the status quo for longer and kicking an opportunity down the road a bit.  And deadlines in this scenario are somewhat artificially imposed.

But what about when someone else is involved and depending on you?

Things get murkier here.  A slipped deadline on a promise might mean that your customer shrugs and yawns, or it might mean they walk away from you.  If you’re a custom app dev agency, they may refuse payment.  Missing a promised deadline has a wide range of potential effects depending on many factors.

So how do you attempt to calculate cost of delay for something like this?

Well, I’d suggest taking the most pessimistic route.  Calculate the percentage of the total that you’ve delivered successfully up to this point, and consider the remainder the cost of a delay.  In other words, on deadline day, take the entire cost of the project to you and call the incomplete percentage the cost of delay, as if you’ll never deliver it.  Sound harsh?  Maybe, but it gives you a figure and a worst-case scenario.

And it also really drives home the importance of incremental value delivery.  If you’ve delivered 90% of the project to the customer’s satisfaction already, a delay probably won’t hurt.  If you’ve delivered nothing, consider the entire project waste unless proven otherwise.

An Immovable External Deadline

The final type of project I’ll mention is somewhat similar to that last one.  But here, an immovable event threatens you, rather than some past promise you made.  Examples of this?

• Your competitor is releasing a killer feature on a certain date, and you need to beat them to market.
• You have a huge trade show coming up and need to make a good showing.

Even more than the last scenario, you’re in an all-or-nothing situation here.  And, again, I’d advise taking to heart the lean movement’s wisdom of considering anything not delivered to be waste until it is.  In other words, consider a delay to make the project a total — your cost of delay is the cost of the project.

Unlike the last scenario, incremental delivery doesn’t necessarily help.  In this case, you mitigate risk by taking a critical look at scope.  If you’re going to have a total on your hands without delivery by a certain date, you need to take a hard look at what you really need by that date and ruthlessly cut everything else.  If you get ahead, you can always add it back in later.  But if you get behind, you can’t kindly request a reschedule of the trade show.

An Intangible Project

The last situation that I’ll mention briefly is something you might think of as an “intangibles” project.  It’s a project that will make the board happy or that you think will totally be awesome, but with no numbers to back it up.  Really, it could be anything where you can’t easily quantify the benefit.

In this case, I honestly have no advice for you on cost calculation.  How do you calculate the cost of delay when you’re not really sure how the project helps?  What does purple sound like?  It’s a question that makes no sense.

If you’re doing a project like this, I do have some advice for you, though.  Stop what you’re doing and make at least some attempt to quantify the benefits.  If you can’t reason about the cost to delay a project, you probably haven’t thought through its benefits.  And if you haven’t done that, why are you doing the project?

Understanding costs and benefits is hard.  Estimating the cost of heavily multivariate outcomes, like delays, is even harder.  You could do something rigorous like a Monte Carlo simulation, but you can get a good feel for it just by applying some of what I’ve talked about here.  But however you approach figuring out the cost of delay, make sure to understand it from the outset and to have a solid backup plan the moment things start to head off course.  Because in the world of software, they always go off course — it’s just a question of how much.

Learn 8 best practices for managing remote software teams using GitHub.