Multi-Phase and Single-Phase Projects
The Power of a Visible Finish Line
Urgency comes from proximity. A team working toward a deadline four months away feels the pressure of each passing week. A team working toward a deadline two years away does not. The work is the same, the people are the same, but the motivational force is completely different. When the finish line is close enough to see, every week matters. When it is not, weeks slip without consequence — and by the time the team notices, months have been lost.
VPM uses this to its advantage. The fundamental structural principle is to keep the active execution horizon short enough that the finish line is always visible — typically 3 to 6 months. Within that window, the team can feel the shape of the remaining work. They know what is done, what is at risk, and how much time remains. That awareness drives a quality of attention that longer horizons simply cannot sustain.
This is why VPM distinguishes between single-phase and multi-phase projects. The distinction is not about project size or complexity in the abstract — it is about keeping the team's finish line close enough to sustain real urgency. A four-month project has this built in. A two-year project must create it deliberately, by breaking the work into phases that each function as their own execution cycle.
The Agile Release Parallel
If this sounds familiar, it should. Agile teams already operate on this principle through the concept of a release. A release is typically a 3-to-6 month horizon — a collection of work aimed at delivering something meaningful to users. Without a release target, work can churn indefinitely — tasks get completed, but they lack direction and urgency beyond the current iteration. The release gives the team its purpose by creating a finish line that everyone can see and work toward.
VPM's active phase serves the same function, but at a different scale. Where the Agile release coordinates a software team's work toward a delivery milestone, VPM's active phase coordinates all functions — engineering, operations, marketing, quality, regulatory, supply chain — toward a shared gate. The principle is identical: create a horizon close enough that every week feels consequential. The scope is wider: the active phase synchronizes across the entire cross-functional team, not just one discipline.
This is also why VPM and Agile are complementary, not competing. A software team can run Agile releases inside a VPM phase. The release manages the software team's internal work. The VPM phase manages the interfaces between the software team and everyone else — the handoffs to hardware, to operations, to regulatory. Both use the same insight — visible finish lines drive urgency — at different levels of the project.
Single-Phase Projects
A single-phase project is short enough — typically around four months or less — that one execution cycle covers the entire effort. The team conducts one planning event, makes one set of cross-functional commitments, and works toward one finish line from kickoff to completion. The urgency is built in because the end is always in sight.
Single-phase projects are common in sustaining work, incremental product updates, and smaller development efforts. They use the full VPM method — swim lanes, RACI-based task breakdown, daily stand-ups — but without the added structure of phase gates and phase transitions. The planning event and the execution cycle happen once. For teams new to VPM, a single-phase project is often the best place to start: it lets the team learn the method within a contained scope before applying it to larger, multi-phase efforts.
Multi-Phase Projects
Most significant product development projects are multi-phase. A new medical device, an industrial instrument platform, a complex embedded system — these efforts routinely span one to three years. Running one continuous execution cycle for that duration would be like asking a marathon runner to sprint the entire race. The urgency that makes VPM work depends on keeping the finish line close.
In a multi-phase project, the work is broken into phases of roughly 3 to 6 months. Each phase gets its own planning event and its own set of Accountable-level commitments. The team's area of intense execution shifts with each phase. Early phases may focus on requirements and concept development; middle phases on detailed design and prototyping; late phases on verification, validation, and launch preparation.
Each phase typically ends with a gate — a decision point where leadership evaluates progress and authorizes the next phase. A common phase-gate structure in product development looks like this: Gate 1 (Business Case) confirms the opportunity is worth pursuing. Gate 2 (Concept) validates that a viable technical and commercial approach exists. Gate 3 (Design) confirms the design is complete and ready for verification. Gate 4 (Verification) confirms the product meets its specifications. Gate 5 (Validation) confirms the product meets customer needs in real-world conditions. Gate 6 (Launch) authorizes full market release. Not every organization uses exactly this structure — gate names, counts, and criteria vary — but the pattern of phased decision-making is nearly universal in regulated and complex product development.
Each phase between gates operates as its own VPM execution cycle. The team plans the phase, builds the swim lane chart for that phase's deliverables, and runs daily stand-ups against that phase's commitments. When the phase ends and the gate is passed, the team resets: a new planning event, a new swim lane chart, new commitments. This reset is important — it gives the team a clean start and a renewed sense of urgency with a fresh, visible finish line.
Upgrading Execution with the Fever Chart
The phase structure described above works on its own. Swim lanes, RACI-based commitments, and daily stand-ups are enough to keep a team focused within a short active phase. Many teams start here and deliver real improvements in on-time performance.
For teams ready to go further, the fever chart takes phase execution to another level. The fever chart is a single visual scoreboard — one chart per active phase — that shows the team at a glance whether they are on track, at risk, or in trouble. It turns the daily stand-up from a status recitation into a focused conversation: "We're drifting toward yellow — what do we do about it today?" The fever chart creates a shared emotional stake in the outcome. It becomes the team's scoreboard, and teams that use it consistently report that it changes how they respond to problems.
The fever chart is optional because it introduces concepts that take time to learn. Buffer-based thinking — tracking how much schedule protection remains rather than whether individual tasks hit their dates — is unfamiliar to most teams trained on Gantt charts. The VPM fever chart uses structured team consensus rather than mathematical calculation, which makes it more accessible than Goldratt's original, but it still requires the team to develop a new muscle: collectively assessing project health rather than reporting task status. Teams that invest in learning it find it transformative. But it should not be a barrier to getting started with VPM.
In multi-phase projects, each phase gets its own fever chart. When a phase ends and the team resets for the next phase, the fever chart resets too — a clean scoreboard for a clean set of commitments. This per-phase reset is natural for paper-based and whiteboard-based VPM. For teams using software, maintaining separate fever charts per phase, resetting commitments at phase boundaries, and managing the overlap between outgoing and incoming phases is an operational requirement that few tools handle natively.
The Transition Between Phases
Phase transitions are not clean breaks. In practice, work from the current phase often overlaps with preparation for the next. The team may be closing out verification tasks while simultaneously preparing for validation. The gate review itself requires preparation — assembling evidence, preparing presentations, getting stakeholder alignment.
VPM handles this by allowing overlap in the swim lane chart near phase boundaries. The current phase's commitments remain the primary focus until the gate is passed. Pre-planning for the next phase can begin in parallel, but it does not get its own execution rhythm until the new phase formally kicks off with a planning event.
Managing this transition well — keeping the current phase sharp while preparing for what comes next — is one of the harder disciplines in multi-phase project management. Getting it right means the team never loses urgency at the end of one phase or stumbles at the start of the next.
Choosing the Right Structure
The decision between single-phase and multi-phase is not about following a rule — it is about keeping the finish line visible. If the team can see the end and feel genuine urgency throughout the project, a single phase is simpler and better. If the project stretches long enough that focus will fade in the middle, break it into phases.
When in doubt, err toward shorter phases. A four-month phase with a clear finish line will outperform a nine-month phase where urgency dissipates in the middle. The overhead of an additional planning event is real, but it is small compared to the cost of a team that loses focus because the end is too far away.
See Also
- The VpmWorks Process — for how planning events are structured within each phase
- Skyline Visualization — for how multi-phase status is visualized across a portfolio
- Agile, Waterfall, and VPM — for how VPM complements Agile and other internal methods