Email this Article Email   

CHIPS Articles: Phase Gate Development for Project Management-Part IV

Phase Gate Development for Project Management-Part IV
By Eric Verzuh, PMP - January-March 2004
This year, 2003, America celebrates the beginning of one of our country's greatest projects, the exploration of the American West by the Corps of Discovery — better known as the Lewis and Clark Expedition. This great journey shares many characteristics with 21st century IT projects: It had a clearly defined beginning and end, required a team of dedicated professionals, confronted previously unimaginable obstacles and finished a year behind schedule! It's true. The original schedule called for the explorers to begin traveling up the Missouri River in the spring of 1804, reach the Pacific Ocean and return to St. Louis before winter 1805. Instead, they completed their journey September 23, 1806, and were instantly hailed as national heroes.1

When your project finishes 10 months late, chances are there aren't any parades. Worse yet, there is often a sense of frustration and failure. Yet many IT projects face the same dynamic confronted by the Corps of Discovery: They are given a fixed deadline while the actual scope of the project is barely understood.

This is the fourth article in a series profiling project management techniques that apply to the IT environment. If you've read the previous articles, you may already be building detailed action plans, managing risks and developing a more cohesive project team. Those techniques focused on the day-to-day responsibilities of managing a project. This article will take a new perspective, examining an overall strategy for managing the risks of exploring new territory, a strategy called phase gate development.

Lewis and Clark have been described as having "undaunted courage" because of the physical dangers they braved and their willingness to journey into the unknown. They had little choice but to forge ahead with the best information and technology available. Many IT projects must begin the same way: Accepting a challenge with the best information at hand and the need to move forward.

I must be clear that not all IT projects can be characterized this way. IT projects come in many forms, ranging from mostly hardware oriented to mostly software oriented. Within that range some projects begin clearly scoped (extend network to the third floor of the office building because we are adding staff) while others are barely scoped (improve battlefield communication). Which kind is the source of runaway schedules and budgets? No surprise — it is those that are barely scoped. The answer to improving control over these projects is a phased commitment strategy, more commonly known as phase gate development.

A phase gate development strategy is based on common sense: Don't make a commitment when you don't have enough information to support it. Instead, make a series of decisions to move forward and at each decision point make it legitimate to re-scope or cancel the project.

The Root of the Problem

We can understand the problem better by thinking about data developed by Barry Boehm.2 Estimates at each phase of a software development life cycle can be off by as much as 400 percent, even for well-run projects. The problem is that the first estimate is often prepared when the project is barely scoped. These projects started with a general idea of what was to be accomplished and eventually that functionality was delivered — but along the way the understanding of how it would be accomplished evolved.

That is the nature of IT projects: We begin with a problem to solve and eventually use technology to solve it, but the discovery and creativity required along the way mean estimating will be difficult. Other fields have similar problems. For instance, in the pharmaceutical industry it is commonly accepted that out of 1,000 compounds identified (the chemical foundation for a potential product), only one gets to market as a drug.

Establish Multiple Decision Points

A phase gate development model accepts the reality documented by Boehm and confronts the real risk of over-budget or behind schedule projects: They are potentially business failures. Every project is designed to have a return on investment or ROI. Given the uncertainty demonstrated by Boehm, it makes sense that once a project is initiated we revisit the business case periodically to validate the ROI. Figure 2 illustrates how a series of business case reviews relates to standard activities in a development life cycle. (I fully acknowledge that this life cycle does not represent the complexity that can be found in a systems development methodology. The four phases shown here purposely simplify the example.)

A curve is included in the figure to indicate the amount of discovery remaining in the project. It should make sense that early in the project there will be much more discovery remaining than at the latter phases.

How many decision points are required depends on the clarity of the project scope. In the earlier example of extending a local area network to another part of an office building, it seems realistic that two gates would be sufficient: The initial go-ahead and a review based on a detailed design and estimate. For the other example — improving battlefield communication — many gates will be required as the team clarifies both the goal (how will we know communication is improved?) and proposes various methods of delivering the capability.

Understanding the Gate

The final, fundamental requirement of using a phase gate strategy is to understand what must occur at each gate and who is responsible for it. A mature gated development model uses consistent gates for similar projects. Each gate consists of three components:3

-- Required deliverables — what the project team will be asked to present at that decision point. These deliverables will change as the project progresses through development.
-- Gate criteria — a known set of questions for judging whether the project should proceed.
-- Specific outputs — what is the purpose of the gate? If it is to approve the next phase of the project, then an outcome should be a formal approval and action plan or budget for the next phase.

Passing a gate is a decision made by the project’s owner — the organization that is funding the project and will benefit from its result. The owner weighs the proposed scope and benefits against the estimated project cost, delivery schedule and risks. At each successive gate in the development process there should be more evidence to support each of these elements. On complex IT projects there is seldom a single person who represents all of the owner’s interests, so a steering committee performs this function.

The project team and project manager are responsible for supplying the estimates that make up the business case and for providing the evidence of their progress. That evidence takes the form of system development outputs such as documented requirements, system architecture, detailed designs, test results, etc.

At each gate, there are several legitimate outcomes including carrying on with the original project goals; adjusting the triple constraint of cost, schedule and scope; or project cancellation. If the project carries on as originally envisioned that means nearly all previous assumptions are being confirmed as the work progresses.

Managing Risk

Projects that are barely scoped often turn out to be two to four times as expensive as originally estimated because as they progress their scope gradually increases or we find them to be more difficult than initially envisioned. The gate decisions are opportunities to look at the facts gathered so far and determine if the project should be scoped up or down, and to assess the reality of the current budget and schedule. Note that in Figure 2 each gate is described as a business case review, emphasizing that the real decision at each gate is whether the evidence at hand supports the assumptions that make this project a good investment.

Here’s an example of how a phase gate strategy keeps projects on time and on schedule: If a project’s initial estimate is $50,000, but its revised estimate at completion of design is $150,000, the project team and the project owner have choices — if they choose to carry on and the project completes for $150,000 then it should be considered on budget! In other words, the baseline for measuring performance should not be the initial estimate based more on assumptions than facts. Rather, consider the baseline to be reset at each phase gate.

To do it any other way would be like the family that decided to spend $50,000 on remodeling their house, heard from both the architect and builder that their ideas were easily going to cost $150,000, yet forged on and complained upon completion that the project was three times their original budget. Performance baselines should not be confused with wishes!

The other legitimate option at a gate is project cancellation. Though most project teams are disappointed when their project is canceled at a phase gate, it is not necessarily a sign of failure. In fact, canceling projects can be a sign of success.

Even in an ideal IT organization — where everyone is smart and knows how to do their job well — we’ll still have projects canceled. That’s because we must and should take business risks. We can initiate projects with thorough planning, using all our best estimating techniques, yet we lack a crystal ball to clearly forecast the future. Recall the earlier example of the pharmaceutical companies that find only 1 of 1,000 compounds turn into a marketable drug; if they had no canceled projects they would either have 999 unmarketable drugs or no drugs at all. Canceled projects are a sign that an organization is willing to try something new, yet is carefully managing its investments.

Another valid reason to cancel a project in our ideal IT organization is that as we make progress on several projects, a new, more valuable, more urgent project can arise. If all current projects are evaluated at regular gated intervals it will be apparent, which is the best candidate to cancel so resources can be redirected toward an investment with a better return. In reality, we make mistakes due to ignorance and incompetence so it is even more important that we scrutinize every project repeatedly. That is why I originally referred to phase gates as a phased commitment strategy — each gate represents a commitment to pursue the next phase of the project.

The Essential Element

A phase gate strategy is unlike risk management and detailed planning, which can be performed by the project manager and team with or without the cooperation of other stakeholders. In contrast, the phase gate strategy only works if it is embraced consistently by those who initiate projects and oversee the project portfolio (the collection of all planned and active projects).

Phase gates must be used at consistent points along the development life cycle so that each project encounters the same gates. Through this common experience all project stakeholders develop a common understanding of the strategy. If only a few projects use gates or each project sets its own gates, the process will never mature and the benefits will never be realized.

The project management office may be given responsibility for establishing and managing phase gates, but the PMO only provides the structure. Those who fund and prioritize projects determine actual use of the process. Fortunately, these are also the people who gain the most from the process, because it allows them to initiate projects that are barely scoped yet retain control of the cost-schedule-scope equilibrium, even as this balance evolves.

Common Criticisms and Obstacles

There are two common objections raised to a phased commitment strategy for IT projects: The first objection is that project teams lose accountability. The second obstacle, strangely enough, is a mistaken belief that an IT organization is already using the strategy. How can we use the example of Lewis and Clark, whose raw determination and perseverance delivered one of our country’s greatest accomplishments and at the same time claim canceling a project is legitimate and even a sign of success? Heroes aside, how do we keep a project team accountable for cost and schedule goals if we let them reset the baseline every time they fall too far behind?

Excellent questions!

On June 13, 1805, Meriwether Lewis arrived at the foot of the Great Falls of the Missouri River. The expedition was on schedule to reach the Pacific Ocean by the end of summer and make the return trip down the Missouri River before winter. Twenty-nine days later the Corps had traveled only 20 miles; portaging the falls had taken longer than expected. Within days, the expedition leaders faced another unexpected obstacle: the Rocky Mountains. The huge mountain range they confronted was vastly different than the high plateau they expected. 4

At this point it became clear that their original plan to reach the journey’s end by that winter was no longer realistic. Given the reality of their situation, they changed their plans and determined they would winter on the Pacific Coast and return home in summer 1806. Some of their original assumptions proved to be wrong, so they made a new plan based on the best available information — a relevant lesson for any project manager.

Still the objection remains: How will we keep our project team accountable to goals if we allow them to reset baselines? We should also ask whether a team will accept accountability to a goal once it is clearly impossible. The art of setting realistic yet challenging goals combines the ability to estimate with the savvy to distinguish between poor performance and unexpected obstacles. At each gate a team should be asked to justify cost and schedule projections. If these have changed from one gate to the next, they should also be able to produce evidence that the scope or difficulty changed.

The second obstacle to implementing a phase gate approach is mistaking the phases of a development life cycle for phase gates. If you’ve been thinking, “Yes, we have a phased development methodology, so we are already doing this,” you may be guilty of this mistake. Many organizations have multiple phases in their development methodology; yet don’t apply the phase gate discipline.

The distinction is in execution. If your projects have end-of-phase reviews then see if the following actions really take place: 1) The business case for the project is actually updated with changes noted so the evolution of the business case is apparent; 2) The baseline cost and schedule estimates for measuring project performance are formally changed; 3) The scope of some projects is increased, reduced or redirected based on the work performed in the previous phase; 4) Some projects are canceled as the original assumptions about cost, schedule and scope are proved false; 5) Some projects get higher priority because the underlying business case is stronger than originally anticipated.

If you have phase “reviews” without these results, you don’t really have gates you have milestones — and you aren’t managing the big picture — only the details.


The nature of projects is that we must often begin them with a hazy understanding of the actual work required to meet our goals. As a result, projects are initiated with an uncertain relationship between cost, schedule and scope — we have no choice. If final project performance is compared against the initial cost and schedule goals, we should expect to find wide (and wild) variances. A phase gate development strategy recognizes the inherent need to start projects without full information and responds by repeatedly forcing the project team to justify its scope and value at predetermined points in the development process.

Phase gate development does not mean an open checkbook to the project team. It is not a license to “work as long as it takes.” Instead, it is a method to manage the business risk of the project, the risk that if the benefits, cost or delivery date changes, the project may no longer be worthwhile. The primary benefits of a phase gate strategy are to the owner, the person who is funding the project and gaining its benefits. It gives the owner greater control over the ultimate duration, cost and deliverables.

Though few IT project teams risk their lives as the members of the Corps of Discovery did, there are useful comparisons to managing projects that begin with uncertain scope. It is unrealistic and ultimately destructive to stick fast to original project goals of cost, schedule and scope when the facts are proving those goals to be a fantasy.

1. Fifer,Barbara and Soderberg,Vicky. Along the Trail with Lewis and Clark. Helena, MT: Farcountry Press, 1998.
2. Boehm, Barry, et. al. Cost Models for Future Software Life Cycle Processes: COCOMO 2.0. Upper Saddle River, New Jersey: Prentice Hall, 1995.
3. Cooper, Robert G. “Stage-Gate New Product Development Processes.” Eric Verzuh. The Portable MBA in Project Management. New York: John Wiley & Sons, 2003. (pp. 320-321)
4. Fifer and Soderberg, Ibid.

Eric Verzuh is the best-selling author of two books on project management. Each year his firm delivers project management training to thousands of IT professionals.

Figure 1 shows phase gates in the development cycle: requirements, design, construction and operation.
Figure 1. Phase gates in the development cycle.

Figure 2.
Figure 2.
Related CHIPS Articles
Related DON CIO News
Related DON CIO Policy

CHIPS is an official U.S. Navy website sponsored by the Department of the Navy (DON) Chief Information Officer, the Department of Defense Enterprise Software Initiative (ESI) and the DON's ESI Software Product Manager Team at Space and Naval Warfare Systems Center Pacific.

Online ISSN 2154-1779; Print ISSN 1047-9988
Hyperlink Disclaimer