Research from the Product Development Management Association showed that in 2012, 70% of U.S. product development organizations managed their work with phase-gate Product Development Processes (PDPs).

While Agile has started to eat into that adoption rate, almost all companies that I encounter still use phase-gate in some form, and when an agile implementation fails to deliver, organizations fall back to phase-gate because it has a long history of providing management with visibility and control over a product development program.

Agilists tend to describe phase-gate processes as obsolete or inherently “waterfall” and therefore evil — but this is more a reflection of how poorly the agilist coach understands the nature of product development outside of software. In the hardware world and in many other places, phase gates are ubiquitous because they work.

What is a Phase Gate Product Development Process?

In the diagram above, the arrows are separated with a white gate — a checkpoint the team must pass before proceeding to the next phase. Most phase-gate life cycles have five to seven phases, each separated with a gate.

Phase-gate life cycles promised to shorten time-to-market and reduce development costs by systematizing the chaotic world of innovation into clearly-defined phases with oversight at the gates, and by giving business teams distinct points where bad projects can be recognized and killed. When these were introduced in the 1990s, they made a step-change in the performance of most product development teams, which is why they have become so ubiquitous.

It is true that an organization with phase-gates is more productive than a completely chaotic product development process with no controls at all. But is it the best way to organize the flow of work in product development?

Stage Gate Life Cycles are Essential!

One school of thought says that phase-gate life cycles form the basis for a stable, predictable product development process that can then be continuously improved to improve the flow and eliminate waste. In practice, this approach has not worked all that well, leading to incremental improvements in product development performance but no dramatic accelerations. Merely tweaking a phase-gate life cycle does not address the systemic problems that cause late design changes, reinvention and overloaded resources.

At the same time, it is true that an organization with a phase-gate process is likely to be much better prepared to adopt the product development practices that do address these systemic problems. It is nearly impossible for rapid learning cycles, convergent decision-making and effective design thinking to take place in a product development process that is ill-defined or nonexistent. If there is no process at all, phase-gate is a good way to avoid reinventing the wheel just to put a workable product development process in place.

Phase Gate Life Cycles are Evil!

Phase-gate life cycles do flout several of the tenets of good process flow, and that has led some to believe they should be abolished:

• They are large batch processes. In many companies, some types of work cannot proceed until a product has made it through a specific gate. The hand-off of requirements from Marketing to Engineering, system integration and verification testing, manufacturing process engineering and procurement are all processes that become vulnerable to large batch dumps in a phase-gate PDP that is too rigid. The gates tend to get overloaded with deliverables and checklist items.
• They impose a linear flow on an inherently cyclical learning process. Phase-gate life cycles assume that once a product is past a certain development phase, there should never be any need to go backwards. The reality for most product developers is that requirements change, technology plans don’t work out as expected and it is hard to invent on a schedule. While learning takes place mostly in the early phases of product development, it continues throughout.
• They drive teams to rush through early development only to get bogged down in late development, and make decisions earlier than they need to be made, limiting flexibility in late development. This is a natural consequence of the linear view of product development: if we want to cut time-to-market in half, then all of product development needs to go twice as fast. In reality, product development teams go faster when they spend more time in early product development to burn down technical risk before committing to specific solutions.

A Phase-Gate Life Cycle With Maximum Flow

While the “Phase Gate is Evil!” position makes a lot of good points, the reality is that product development needs a workflow model, and  in most organizations, the phase-gate model is much better than the chaos that would break out if the PDP did not exist.

My experiences in working with organizations through the transition from start-up to maturity have shown me that a company with a good phase-gate PDP is much better prepared for rapid learning, platform development and design thinking than a company without one.

Fortunately, four adjustments to the typical phase-gate process mitigate the ill effects of phase-gate without losing the benefits: 

• • Decouple business decisions from other decisions. Executives and other managers like phase-gate because it gives them defined points in the process to review the business case and make good decisions. The key business decisions are easier to make if the information needed is not drowned out with a lot of other deliverables. These business decision points still act as gates, because the project may be cancelled at the gate. The organization accepts the small risk that the project will be cancelled to eliminate a whole lot of the waste of waiting. Downstream partners accept the waste of a small amount of rework to eliminate a whole lot of waste from redesign work across the whole system.  Work becomes more concurrent and knowledge flows more easily across the teams. Learning proceeds throughout. With business decisions decoupled from the flow of work, all of the large batch hand-offs can be replaced with a more flexible release of information from one part of the development team to another. Downstream partners will get engaged sooner, when a little bit of their help will go a long way towards eliminating the root causes of late design changes.
  • Establish a regular cadence of Integration Events for converging on Key Decisions at the point in time when they need to be made, so that these major decisions don’t have to wait until the next Gate, or get force-fit into deliverables.
  • Seek to understand the last responsible moment for the Key Decisions that govern the product’s success and plan Integration Events so that the team converges on a solution just ahead of the last responsible moment.
  • Blur the boundaries between phases so that work gets done when it needs to get done, and not when the phase-gate process says that it should be done. Chances are, this is how your team is already working but there may be some partners (Procurement, Finance) who may need explicit permission from management to “bend the rules” and start work earlier.

How to Modify Your Phase-Gate PDP To Maximize Value and Speed

• • Reduce the checklists and deliverables for each gate down to the absolute minimum required for the managers to make the informed decision that is the reason for the gate. 
  • Move the rest of the deliverables to interim milestones that take place between the gates.
  • Dissolve the rigid boundaries between phases: bring key suppliers on board earlier, get process engineering engaged sooner and map out decisions according to the last responsible moment for making them.
  • Ensure that teams have a good handle on the Key Decisions that need to be made within a phase — they should lead up to the major business decision that will be taken at the end of the phase — and that the team understands the Last Responsible Moment for these major decisions.
  • Establish a regular cadence of Rapid Learning Cycles that will structure the time within a phase.