- Principle #1: Take an economic view
- Principle #2: Apply systems thinking
- Principle #3: Assume variability; preserve options
- Principle #4: Build incrementally with fast, integrated learning cycles
- Principle #5: Base milestones on objective evaluation of working systems
- Principle #6: Visualize and limit WIP, reduce batch sizes, and manage queue lengths
- Principle #7: Apply cadence, synchronize with cross-domain planning
- Principle #8: Unlock the intrinsic motivation of knowledge workers
- Principle #9: Decentralize decision-making
This chapter is from the book
This chapter is from the book
This chapter is from the book
Principle #5: Base milestones on objective evaluation of working systems
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
The Problem with Phase-Gate Milestones
Developing today’s large systems requires substantial resources—investments that can total millions and even hundreds of millions of dollars. Developers and customers have a mutual fiduciary responsibility to ensure that investments in new Solutions will deliver the necessary economic benefits. Otherwise, why bother?
Clearly, stakeholders must collaborate in ways that help ensure the potential to realize the prospective economic benefit throughout the development process, versus engaging in wishful thinking until the end. The industry has generally applied a sequential phase-gated (waterfall) development process to address this challenge, measuring and controlling progress through a series of specific Milestones.
These phase-gate milestones are not arbitrary, but rather follow a seemingly logical and sequential process: discovery, requirements, design, development, test, and delivery. Of course, this approach doesn’t always work out all that well, as Figure 1 shows.
)
Figure 1. The problem with phase-gate milestones
The cause of the problem is the failure to recognize the four critical errors about the assumption that phase gates reveal real progress and, therefore, to mitigate risk:
Centralizing requirements and design decisions in siloed functions that may not be integral to the solution.
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.
- Later it’s discovered that the chosen path is not feasible (see Principle #3).
Assuming a point solution exists and can be built correctly 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.
Making up-front decisions creates large batches of requirements, code, and tests, as well as 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, so a different approach is needed. Principle #4, which calls for building incrementally with fast, integrated learning cycles, provides elements of the solution to this dilemma.
Throughout development, the system is built in increments, each of which is an integration point that demonstrates some evidence of the feasibility of the solution in process. Unlike phase-gated development, every milestone involves a portion of each step—requirements, design, development, testing; together, these steps produce an increment of value (Figure 2).
)
Figure 2. Milestones based on objective evaluation of working systems
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.
What is actually measured at these critical integration points is subject to the nature and the type of system being built. The key point is that the system can be measured, 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.