Subscribe to our mailing list

* indicates required

Saturday, April 11, 2009

The principle of Last Responsible Moment

This post has moved to: Please forgive the inconvenience. 

 A military officer who was about to retire once reportedly said: "The most important thing I did in my career was to teach young leaders that whenever they saw a threat, their first job was to determine the timebox for their response. Their second job was to hold off making a decision until the end of the timebox, so that they could make it based on the best possible data."

This is an illustration of a principle that I think is (sadly) underutilized not only in R&D circles but in project planning generally, namely the principle of delaying decisions until the "last responsible moment" (championed by the Poppendiecks and others). The key intuition is that crucial decisions are best made when as much information as possible has been taken into account.

This is a good tactic when the following criteria are met:

1. Not all requirements for success are known in advance
2. The decision has huge downstream consequences
3. The decision is essentially irreversible

If one or more of the conditions is not met, the tactic of deferring commitment might not gain you anything (and could actually be costly, if it holds up development).

Conventional project planning, as practiced in enterpise today, tends to overemphasize the need for completeness in requirements-gathering. The completeness fetish leads to the Big Huge Requirements Document (or Big Huge RFP) Syndrome and can introduce unnecessary dependencies and brittleness into implementations.

There's a certain hubris associated with the notion that you can have a complete specification for something. You almost certainly can't. You almost certainly don't know your true needs ahead of rollout. True, some decisions have to be made in the absence of complete data (you don't always have the luxury of waiting for all the information to arrive), and there's the fact that you need to start somewhere even if you know that you "don't know what you're doing" yet. But that's not my real point. My real point is that too often we make decisions ahead of time (that we didn't really have to make, and later realize we shouldn't have made) based on the usually-false assumption that it's possible to know all requirements in advance.

What I'm suggesting, then, is that you reconsider whether it's always a good idea to strive for a complete specification before starting work on something. Accept the fact that you can't know everything in advance. Allow for "emergentcy." (Good decisions are often "emergent" in nature.) Reject the arrogant notion that with proper advance planning, you'll have a project that goes smoothly and results in a usable solution. Most of the time, from what I've seen, it doesn't work out that way. Not at all.


  1. This is exactly where agile development shines as it provides for that flexibility, allowing for requirements to evolve while keeping the stakeholders in the decision loop.

  2. Anonymous12:42 PM

    The problem being mentioned is very genuine. But the solution you propose depends entirely on instincts and experience. Is there a more systematic way of solving this?

  3. Anonymous: You raise a good question w/r/t "systematic." I don't know what they teach in project-management courses (I'm not a project-mgmt expert), but to me it would make sense to tier the decisionmaking into well-defined phases, with decision points (scheduled flesh-outs) on a calendar. Start with a limited set of high-level requirements; iterate to refine that; then begin work (which may mean writing an API rather than code, during the initial stages); regroup & decide whether to proceed with the flesh-out. Take what's been learned so far and craft the next set of requirements (build out on reqs; "flesh them out"). Refine & work. Regroup & decide whether to proceed to do the next flesh-out. (Else recede and iterate again.) Repeat.

    I can see whether this needs some thinking as to how branching and parallelism, delegation, rollback, etc. should be addressed. Lots of issues to solve if this is become systematic. Unfortunately, I'm not the guy to take this all the way (and give it catchy new buzznames, make a cult out of it, etc.), but I think it's possible for someone who knows more than I do about project management to build a bonafide methodology around this. Lean Development speaks to this general subject, but it is not a true methodology, IMHO, precisely because it is not systematic; it's thematic.

  4. Ya lean development. However. There's always a wild card.

    Random Lean Development. Consider the expected and unknown.


Add a comment. Registration required because trolls.