Project Management

Last Responsible Moments

From the Pro*Blog Blog
Covering all things Pro: problems, products, progress, projects, process, programs, professions, proposals, provisioning, and more! Analysis and commentary on yesterday and today, and prognostications, prophesies, and projections for the future.

About this Blog


Recent Posts

Agile versus Waterfall in Software Projects

Collective Knowledge

Last Responsible Moments

Donald Rumsfeld and Project Management

Kaizen or Kaikaku?

Last Responsible Moments

By John Herman   PMP, CQE, MPM

Lean Software Development is an agile software approach based on the lean concepts of Value Streams, and the work of Taiichi Ohno, who is considered the father of the “Toyota Production System” and “Lean Manufacturing”.  Using the lean philosophy, Lean Software Development developed six best practices that continue to influence Agile methodology.  The six are:

  • Optimize the Whole
  • Defer Commitment
  • Deliver Fast
  • Eliminate Waste
  • Build Quality In
  • Empower Team Learning

No doubt today’s Agile methods have seen benefit from Lean Software Development, which originated in the early 2000’s.  The discussion of all six best practices is too much for a single blog posting, but I’d like to draw your attention to the second, “Defer Commitment” for a short lesson in agile risk management, and software project methodologies. 

In an earlier blog entry, I discussed Alexander’s Question, and Last Responsible Moments are generally based on those building blocks.  While Alexander’s Question encourages deferring decisions until certain critical information can be obtained or better understood, the Lean “Defer Commitment” states that the best possible solution can emerge by deferring design until the Last Responsible Moment.

The Last Responsible Moment occurs when any advantages of acquiring additional information are offset by potential risks of delaying a decision any longer. 

Note that there can be several such moments within any project or iteration, with aspects of the design and process in opposition to various risks, with overlap and feedback mechanisms also within consideration.  If it was easy, anyone could do it, right?

Thus the Last Responsible Moments, and the practice of Defer Commitment in general, are dependent on solid risk management.  This point is invaluable in any debate regarding the viability of agile methods when unknowns and risks are running rampant, and especially in defense of agile methods from those who are entrenched in Traditional Waterfall software development methods. 

I urge you to continue to evaluate each software project’s methodology based on the project itself, and without any preconceived notions regarding the best approach, until the Project Management team has gathered as much information about the project as it can.  Which is, of course, a Last Responsible Moment.


Posted on: January 24, 2017 03:52 PM | Permalink

Comments (5)

Please login or join to subscribe to this item
Thank you for your blog, and i liked you suggesting selection of Project Life Cycle at last responsible moment. Many time i do see well before project charter stakeholders starts talking about the Project Life Cycle they want to use for the project. In my experience i do not find companies using waterfall as one fall (complete project in phases of Software Development Life Cycle) now a days, but i still find some companies breaking the project in small phases and using waterfall in it.

@Saket - Waterfall is still a very viable methodology. Does anyone want to drive across a half-finished bridge? (not me!)

As far as SDLC, some projects, such as conversions, require a "Big Bang" go-live and are not suitable for incremental releases.

I prefer using term waterfall for software development projects not for building bridges. This is what i see Dr. Winston W. Rovce mean when he introduced waterfall. I do see many professionals mistakes predictive life cycles equals waterfall.

I can see conversion projects may still follow pure waterfall , as i say i do not see it in my experience. What % of software development projects you find using waterfall (as one flow, no increments ) in your experience?

Percentage is a variable. For overall percentage of projects via count, waterfall is small, but for large budget projects (such as Application, Database, or Server conversion), it is much more popular. I find that most Business As Usual (BAU) projects are agile with large projects being more waterfall. BAU being minor enhancements, tuning, minor business changes, tax and regulatory changes, etc. Large projects being primarily conversions and acquisitions. In between the two are medium projects which tend to be somewhat hybrid: new products and markets, customer initiatives, etc. If there is a formal "Go Live" date, then waterfall will be involved at least for the very last phase of these "medium" size projects.

Please Login/Register to leave a comment.


"Nothing defines humans better than their willingness to do irrational things in the pursuit of phenomenally unlikely payoffs."

- Scott Adams