There was in fact no correlation between exiting phase gates on time and project success … the data suggested the inverse might be true.

—Dantar P. Oosterwal, The Lean Machine


Principle #5 – Base milestones on objective evaluation of working systems

The Problem with Phase-Gate Milestones

The development of today’s large systems requires substantial investment—an investment that can reach millions, tens of millions, and even hundreds of millions of dollars. Together, systems builders and customers have a fiduciary responsibility to ensure that the investment in new solutions will deliver the necessary economic benefit. Otherwise, there is no reason to make the investment.

Clearly, stakeholders must collaborate in such a way as to help ensure the prospective economic benefit throughout the development process and not just engage in “wishful thinking” that all will be well at the end. To address this challenge, the industry has generally applied a sequential phase-gated (waterfall) development process, whereby progress is measured—and control is exercised—via a series of specific milestones.

These phase-gate milestones are not arbitrary. They follow the apparently logical and sequential process of discovery, requirements, design, development, test, and delivery. Of course it hasn’t worked out all that well for many, as Figure 1 shows.

Figure 1. The problem with phase-gate milestones

The root causes of this problem is the failure to recognize four critical errors within the basic assumption that phase gates reveal real progress and thereby mitigate risk:

  1. Centralizing requirements and design decisions in siloed functions that may not be integrally involved in the solution building.
  2. Forcing too-early design decisions and “false positive feasibility” [1]: An early choice is made for the best known option at that time; development proceeds under the assumption that everything is on track; only later comes the discovery that the path chosen is not actually feasible. (Principle #3)
  3. Assuming a “point” solution exists and can be built right the first time. This ignores the variability inherent in the process and provides no legitimate outlet for it. Variability will find a way to express itself.
  4. Taking up-front decisions creates large batches of requirements, code and tests, and long queues. This leads to large batch handoffs and delayed feedback. (Principle #6)

Base Milestones on Objective Evidence

Clearly, the phase gate model does not mitigate risk as intended, and a different approach is needed. Principle #4 – Build incrementally with fast, integrated learning cycles provides elements of a solution to this dilemma.

Throughout development, the system is built in increments, each of which is an integration point that demonstrates some evidence as to the viability of the current in-process solution. Unlike phase-gate development, every milestone involves a portion of each steprequirements, design, development, testingtogether producing an increment of value (see Figure 2). Further, this is done routinely, on a cadence (Principle #7), which provides the discipline needed to ensure periodic availability and evaluation, as well as predetermined time boundaries that can be used to collapse the field of less desirable options.

Figure 2. Milestones based on objective evaluation of working systems

What is actually measured at these critical integration points is subject to the nature and type of the system being built. But the system can be measured and assessed, and evaluated by the relevant stakeholders frequently, and throughout the solution development life cycle. This provides the financial, technical, and fitness-for-purpose governance needed to ensure that the continuing investment will produce a commensurate return.

Learn More

[1] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.

Last update: 11 April 2016