Cost of Delay: Not Shipping on Time, Part 1

Do you know about the Cost of Delay? It’s the way to think about the revenue you can lose plus the cost of continued development.

One of my managers many years ago had a back of the napkin approach to cost of delay.

Cost of Delay, Back of the Napkin

Cost of Delay,
Back of the Napkin

“Johanna, we want to ship this product in the second quarter this year. We estimate it will take us a quarter to ramp up sales. We think there is a lifetime sales of about five years for this product. Any delays in our shipment will not push our sales figures to the right. They will remove our max sales from the middle. Got it? We have to make our ship date.”

I got it.

There weren’t too many of us developers in that organization. We all knew what our job was: to release on time, and make sure the product was usable. The product didn’t have to be perfect. The product had to be usable, because we could release fixes if we needed to, but we had to climb that sales ramp to get to that max sales point.

We worked on one project at at a time, until it was done. Then we went to the next project. We worked on that project. None of our projects was very long. Why? Because we needed to realize revenue. You can’t realize revenue with a product-in-a-box if you don’t ship it.

We didn’t ship too many fixes. Oh, not because we were perfect the first time. We asked each other for review, and we found problems, so we fixed them inside the building. Before we shipped. Because the cost of not shipping on time was too great.

When you delay your release and don’t ship on time, you miss the revenue from the maximum sales times. Take your delay in weeks, and remove the revenue weeks. That’s your cost of delay, back of the napkin approach.

You can go through more serious calculations. Troy Magennis of Focused Objective talks about a “compounding impact” on other projects. I am sure he’s correct.

But even if you said, “Every week we slip, we lose at least a week of revenue from our maximum sales week of revenue,” do you think people would notice?

How do you release on time? You fix scope (ha!). You have release criteria. You have shorter projects, because they are easier to estimate and deliver. You use an incremental or an agile lifecycle, so you have more predictability about your release.

This post is the simple idea of not shipping on time. But what about when you have competing projects and not enough people? Look for Part 2, next.

P.S. After I wrote this post, I realized I was not living this post. (Why do you think I write? It’s not just for you. It’s for me too.) I published the incomplete Essays on Estimation. I have another essay or two to release. But if I don’t release it, you can’t read it and get any value from it, can you? The point: if you don’t release your products, your customers can’t get any value. Hat Tip to @jlottsen who said in a tweet, “you have to release it, or no one can use it, and you can’t realize any revenue at all”. Very true.

14 Comments

  1. I’m so glad you wrote about this too-often overlooked truth. Certainly, we’re trying to manage uncertainty when we work software-development projects. The average tester (I manage testers) loses his or her mind when I want to shortcut test time because of lost revenue opportunity of shipping later. From a pure cost-benefit analysis, it might be less expensive to fix the bugs in patch releases and ship earlier. That’s counterintuitive to the engineering mindset (if you don’t make the time to do it right, when will you make the time to do it over), but a reality in the overall software-company ecosystem.

    Reply
    • Hi Jim, yes, there are a number of truths about cost of delay. I’m trying to write about them in simple terms. I might make it!

      It really depends on what your customers need. But sometimes, you need to ship something. Sometimes, it’s less than what you want, as long as it’s really good enough for what the customers need. It has to be useful. But you have to release it, or no one can use it, and you can’t realize any revenue at all. That’s key.

      Reply
  2. Thats a really insightful of looking at the cost of slipped target dates, glad I found this blog.

    Reply
  3. Morning,
    So that all sounds marvellous BUT.

    In order to make your deadline you cut scope or quality. That means your product will realise less of your max earnings over all to the time or at least until you release ALL of your app. So anticipating full return for a partial product is wrong.

    For your case to be true it says the intended delay is for totally superfluous or low return functionality. If that’s the case you got a different issue all-together. It would actually mean the reason for the delay is non existent or the ROI of the work done there is extremely small.

    Cheers
    Oliver

    Reply
    • Hi Oliver, you are correct in that you cannot expect a full return for a partial product. What if you don’t need a full product? What if you can get pretty good return for a Minimum Viable Product?

      As with all things, this depends on your product. If you have a hard goods product, you have to weigh the cost of an upgrade to releasing now and later. But think about what Apple did with its original iPhone. They had a minimum viable product. They had a great return.

      I’m not saying you have a crappy product. You have to have a product people will buy. So you don’t cut scope and you definitely don’t cut quality.

      This depends on how little you can do and still have a Minimum Viable Product. That answer is not always clear. Especially if you don’t have SaaS.

      Reply
  4. As an engineering project manager, I have seen my management miss the boat on this almost as a rule. Our development and sales cycles were more like 18 to 24 months and the penalties for missing the window were hugh. More things to consider under this general heading are 1) dithering in choice of features and process cause loss of schedule time that is never recovered, 2) delays from ongoing projects compound when staffing the follow-ons, and 3) dislocations contract that maximum sale time as much as delays in execution, that is, when the tech bubble burst, that marked the end of the maximum sale time regardless of when that project delivered.

    I wandered across this from reddit. I am reading through all of your posts especially the cost of delay and find that very much of the follies therein described I have seen in one form or another in the vlsi design field over the years. Your insights and the write ups of your insights are instructive even as I look back.

    Finally, I subscribe to the saying, “Perfect is the enemy of done.”

    Thank you for your writing.

    Reply
    • Hi John, thanks so much for your comment.

      Your part 1, dithering in the choice of features is possibly part of my part 3, Cost of Delay Due to Indecision. It depends how that delay occurs.

      Your part 2, the delays from ongoing projects is a problem when you do a serial-lifecycle (waterfall). If you have any way of changing to an incremental approach (read Manage It! for more information about lifecycles), you would be better off. You could stop a project and declare victory. I also have articles on my main site about lifecycles.

      Your part 3 is true. This is why you want to think about projects, especially if you are running them in waterfall, where you think about how little you can do. Keep your projects to six months or less, and release. Do another project, six months or less. Release. Repeat. (Oh I said that already :-)

      You and Flaubert are correct. (I had to look up the actual quote for Manage Your Job Search): Perfection is the enemy of the good. The 80/20 rule is a good guideline for requirements. You want to make the 80% you put in work, and work as expected. But you probably only need 80% of what you think you need.

      I’m delighted you found me. Thanks for reading.

      Reply
  5. Hi Johanna,

    Nice article.

    I’d like to suggest another cost of delay: opportunity cost of learning from customers. In my world, we often have an idea what our customer wants, but don’t have perfect requirements or designs. We learn a lot from our customers with our v1 release, and use that feedback to tweak/tune/redesign. Sometimes, we even flame out and fail on a feature.

    Obtaining that customer feedback quickly allows us to learn faster from our customers. Even if we fail, that allows us to move onto the next project quicker.

    A schedule delay misses out on sales, and is also a missed opportunity to learn from our customers.

    Thanks,

    John

    Reply
    • Hi John, Oh, that’s a good one. You are right. The earlier you release something, the more opportunity you have to listen to your customers. I should get through my thick head for my books.

      Reply
  6. Hi Johanna,

    Thanks for these posts, I’m going through them in order. My comment on this first post is based on Lean Startup reading. Clearly there is great sense in shipping early to maximize learning and launch an MVP, but how do we know that the delay in shipping the product provides such a direct correlation to its shelf life? The timescales seem to lack any empirical basis and it puzzles me.

    Thanks,

    Jon

    Reply
    • HI Jon,

      Okay, let me try again :-) Sometimes, I’m not so clear the first time. Please do provide me feedback this time if I make sense.

      Many products have a shelf life, as you call it. Many companies try to be first in their market for that reason. Have you read Crossing the Chasm by Geoffrey Moore? The chasm is that break into the real market, past the early adopters, into the mainstream.

      If you release early enough, especially as a young company, you get the feedback to make your product better and better. That allows you to play “feature leapfrog” with your competition and continue your releases, again and again. If you wait to release, you never get that feedback.

      When you wait to release, you miss the revenue from the initial release. You miss the feedback. Depending on how long you wait, you might miss substantial revenue. (Have you looked at Part 6 yet?)

      Some products have a long shelf life. Some have a very short shelf life. In the US right now, it’s tax season. Our taxes are due April 15. If you were writing a book about a software product for this year’s tax season, it would have a very short shelf life, right? If you were writing an economics text about taxes and their effect on the economy, that would have a long shelf life, right? The first book you need to get out immediately. Otherwise the value is gone by April 15. The other book you have more flexibility, but you probably want to get copies into professors’ hands before the start of the fall semester, so they can read it and order it for their fall courses. See the difference?

      I left the timescales vague in my back of the napkin picture, because every product has a different timescale. I don’t know what your timescale is.

      The consequences for releasing late are real. It depends on your product, and I don’t know what kind of a product you have. If you need a real model, you should talk to the people at Focused Objectives. They thrive on real mathematical models. I don’t. I simplify things, because for my clients and me, the simplified models are often enough to start the discussions.

      Okay, I’m ready for feedback now.

      Reply
  7. Hi Johanna,

    Wow, that was an amazing answer, thank you. I get what you are saying now especially with those tax examples for the delivery side of your example and it also explains why the manager was right with prediction of value and need to ship early. My experience of a number of projects is that the value and ROI side of the project is often poorly understood which means that prioritization is poor and MVP type delivery is a rarity.

    I’ve read all of the posts in this thread and have sent links out to several people in my organization. :-)
    I suspect I was focusing on the wrong thing when I read your post.

    Kind Regards,

    Jon

    Reply
    • Jon, good! Your question was helpful to me, too. Later, at 3am actually :-), I thought of game companies. They have the “Christmas” market, right? If they don’t get their product in the stores sometime around late-Oct, certainly by late November, it is too late for Christmas. They miss their market window for *this year’s* Christmas. Every year it seems to be earlier, too.

      Thank you so much for sending my posts to your people. I appreciate the wider distribution.

      Reply

Trackbacks/Pingbacks

  1. Postrehli sme o Agile| Agile, Scrum, Kanban, Lean - […] prvom článku sa dočítate o cene za oneskorenú […]
  2. New PM Articles for the Week of February 3 – 9 | The Practicing IT Project ManagerThe Practicing IT Project Manager - […] Johanna Rothman introduces an opportunity cost metric: the Cost of Delay. Here’s part two. […]

Submit a Comment

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>