Defining the Last Responsible Moment

I was involved in a recent twitter discussion with Chris Matts about Lean’s “Last Responsible Moment”, and he set a challenge to come up with a usable definition. Chris’s opinion is that there isn’t one, compared to the Real Options equivalent. This then, is my response to that challenge.

I will define the Last Responsible Moment (LRM) in terms of Cost of Delay, as used by Don Reinertsen, and Benefit of Delay, a related term that came up in an email conversation with Julian Everett. In short, the Last Responsible Moment is just before the Cost of Delay outweighs the Benefit of Delay. Its not necessary to be able to quantify the costs and benefits very accurately because any evaluation is going to be better than none!

In his challenge, Chris used the example of knowing the Last Responsible moment to submit a session for Agile2010. I’ll use that example to explain my definition.

Firstly, the Cost of Delay for submitting to Agile2010 goes up at the submission deadline, because when you can no longer submit, can can no longer get accepted, and thus can no longer receive speaker benefits including conference registration, complimentary hotel nights. However, that does not make the submission deadline the LRM, because there is no benefit in delaying submission due to the open commenting and review process. Thus the LRM is actually as soon as the submission system opens. From then on, submitters are losing the opportunity to improve their submission.

What would happen if the Agile2010 submission process wasn’t as open or iterative? In that case, then there would be benefit in delaying, because it would allow more time to refine a submission before entering it. The Benefit of Delay would drop off just before the deadline, however, so the LRM would be then.

A third scenario, as suggested by Chris, is that a speaker might have something so important and valuable to say, that the Benefit of Delay doesn’t actually drop off at the submission deadline. There may be a Benefit right up to the conference itself because a speaker can turn up with a Soap Box, or propose a session for Open Space. The Cost of Delay remains the same, due to the loss of speaker compensation, but the Benefit might always outweighs the Cost.

Finally, in this scenario, a speaker might choose to register for the conference early anyway to take advantage of any early bird deals, and book flights and hotels early to get good prices. This would reduce the Cost of Delay, and thus potentially reduce the Benefit needed to make it worthwhile not requiring an official speaking slot on the program.

To summarise, understanding both the Cost of Delay and Benefit of Delay can be a practical way of defining the Last Responsible Moment. Real Options thinking provides ways of influencing the Costs and Benefits of Delays to gain some flexibility.

VN:F [1.9.22_1171]
Rating: 4.0/5 (2 votes cast)
Defining the Last Responsible Moment, 4.0 out of 5 based on 2 ratings

19 comments on “Defining the Last Responsible Moment

  1. With regards to diagram 1, given that propose that once you missed the deadline you can not gain any benefit, why doesn’t the cost of delay shoot up to 100% (or whatever scale this is meant to be)

    • Hi Bonnie

      I was trying to give a general shape to the graphs with the tools at hand (powerpoint), rather than create a precise graph. Hence the lack of scale đŸ™‚

      Karl

  2. Pingback: Dew Drop – April 6, 2010 | Alvin Ashcraft's Morning Dew

  3. Don Reinertsen also covers this subject in the Principle of Optimum Decision Timing.

    Struggling with your final example, you are allowing sunk cost to be included in the economic decision as opposed to marginal economics. The ticket is purchased, nothing you can do about that.

    By focusing on just the marginal economics, leaving the decision to the conference start, the speaker has lost some of the opportunity slots reducing his chance of being selected and also iteratively developing it.

    The marginal economics are key, and therefore the LRM in your final example looks more like the first picture. There is no marginal benefit of delay, only marginal cost of delay. The LRM is straight away but with marginal picture and the cost of delay being different as this person could also rely on the open space without any more cost (the option lasts longer)

    • Hi Paul,

      Not sure I understand your argument. I wasn’t consciously allowing sunk cost, although I was ignoring the “option cost” for simplicity.

      Karl

  4. One for the pub on Thursday. However once the ticket has been purchased it should no longer be included in the decision.

    Thus the cost of delay is losing the opportunity to have the work iterated, feedback and get a guaranteed spot, the ticket price is no longer a factor.

    The benefit of delay is nothing, there is no benefit in delaying. He has already purchased the ticket.

    The simplicity is good, but it leads the wrong choice in the final answer.

    • Ah. Yes, I see that the Cost of Delay is reduced much more due to sunk cost. Thanks. I still think that there is Benefit of Delay. Why submit early when you don’t have to submit at all?

      I can’t actually make LWS this week. Shame you can’t make LSSC10. Next time though!

  5. This is nice, really nice. Still, there’s a little bit of unit mixing in your description. I notice that in the beginning, your description of Benefit uses these words: “speaker benefits including conference registration, complimentary hotel nights.” Later, you use a considerably less specific “so important and valuable to say” to talk about the Benefits of acting late.

    That’s one of the things I worry about when it comes to such cost/benefit analyses. That which is easily quantifiable (cost of hotel rooms) comes to dominate the qualitative (what you get out of speaking). In unsubtle hands, the qualitative gets completely ignored, leading to bad decisions.

    What happens if different benefits and different costs are incommensurable, if not everything can be converted into, say, euros?

    • Thanks Brian. There’s a difference between Benefit of Delay, and Benefit of Attending. I could be clearer on that difference and I think the final example needs some more work.

      I’m not too worried about trying to quantify the costs and benefits precisely. Its more about the conversation and resulting shared mental model provided by the shapes of the graphs.

  6. Nice abstraction, there are a lot of context specific modifiers I would want to include.

    Take a conference I know well, I used to be on the organizing committee: I can extend my own deadline by submitting a place holder before the deadline knowing that I know the committee well enough that they will check back with me during the review process
    That doesn’t scale, if everyone does it the system breaks down. When I’m on the committee I hate people doing that becuase it makes my job more difficult (expensive).

    Put it another way, I (submitter) can increase the value (to me) by extending my deadline, but I increase the cost to the organizers. Is there any value add? Or just value transfer?

    Another conference I know: my submission experience suggests the organizers value JIT submissions highly and early submissions at zero. They have an open review process and when I submit early nobody looks at the proposal. Submit late, when everyone else is submitting (and reviewing) and it gets attention.

    Bringing this back to LRM…

    Its a bit like physics “friction free surface”, sooner or later you need to account for context, and as usual, the hard bit (the Devil or God, take your pick) is in the detail

  7. Pingback: Quick Agile Links #12 – nemrac.com

  8. Pingback: Why I Don’t Attend Agile2011… « OlafLewitz

  9. Pingback: Last Responsible Moment—A Mindset | Lean Procrastination

  10. Pingback: Agile, Team Work, Leadership » Blog Archive » Why the LRM is just theory?

  11. Pingback: Software Development as Risk Management « Ishmael's Risk Management Cubicle…

  12. Pingback: Why are estimates nearly always low? | Succeedable - Using agility to achieve.

  13. Pingback: Quick Agile Links #12 | Agile Pain Relief

Leave a Reply