PRINCE2 2017 Plans Theme: Planning Levels, Stages and Controls
Plan at the level of certainty and authority that management actually needs: high-level for the whole project, detailed for the current stage, and recover through an exception plan when authorised tolerances can no longer be met.
Executive summary
Four plan types
Project, stage and optional team plans are management levels; an exception plan is a replacement plan rather than an additional management level.
Progressive detail
The project plan is high level, while the current stage plan contains the detail needed for day-to-day control within a realistic planning horizon.
Stages are governance controls
Management stages create decision points for commitment of resources and authority to spend; they need not match technical delivery stages.
Planning starts with products
Plans are intended to enable the business case and use product-based planning before detailed activities, estimates and schedules are built.
Purpose of the Plans theme
The Plans theme facilitates communication and control by defining how the project will deliver its products: where and how work will be done, by whom, when and for how much. The method does not treat a plan simply as a schedule. A plan is a management baseline that links products, activities, resources, cost, time, risks and tolerances so that progress can be judged and decisions can be made.
Planning is deliberately layered because certainty reduces as the planning horizon extends. The whole project needs enough information for investment and governance decisions, but attempting to plan distant detailed work too early can create false precision. PRINCE2 therefore combines a high-level Project Plan with detailed Stage Plans created as the project progresses.
The supplied material also connects planning with continued business justification. Plans are not valuable merely because they are detailed; they must show a credible means of realising the business case. If the plan no longer supports the justification, management should reconsider the project rather than preserve an obsolete baseline.
The four plan types
| Plan | Level and purpose | When used |
|---|---|---|
| Project Plan | High-level plan for the project as a whole; major products, indicative timescales, milestones, costs and resources; principal control for the Project Board. | Created during initiation and updated at stage boundaries as actuals and forecasts improve. |
| Stage Plan | Detailed plan for one management stage; basis for the Project Manager’s day-to-day control and stage tolerances. | Prepared before the stage starts. The initiation Stage Plan is prepared during Starting Up a Project; later Stage Plans are prepared at stage boundaries. |
| Team Plan | Optional detailed plan used by a Team Manager to manage one or more Work Packages. | Prepared where specialist delivery benefits from a separate team-level planning baseline. |
| Exception Plan | Replacement plan created in response to a forecast exception and management direction. | Replaces the affected Stage Plan or Project Plan for the remaining period covered by that plan. |
An exception plan is frequently misunderstood. It is not a fourth level of management. The source identifies three planning levels—project, stage and optional team—and describes the exception plan as a replacement baseline. A stage-level exception plan normally covers from the current point to the end of the affected stage. A project-level exception plan replaces the Project Plan and may require approval from the authority above the Project Board.
Planning horizon and progressive commitment
A Stage Plan should not extend beyond the horizon at which useful detail can be forecast. The Project Plan can show the longer journey, but detailed activity estimates for distant work are likely to change. Near the end of each stage, the Project Manager uses actual performance and fresh information to plan the next stage more accurately.
This is one reason manage by stages is a governance principle rather than a scheduling convenience. At a boundary, management can compare actual progress with the Project Plan, review risks and the Business Case, inspect the plan for the next stage and decide whether to commit further resources. The organisation therefore avoids granting detailed authority for the entire project before enough information exists.
The source suggests choosing the number and length of management stages using project scale, duration, risk, planning horizon, technical delivery steps and alignment with programme activities. Higher uncertainty may support shorter management stages so that formal review and re-authorisation occur more frequently.
A shorter stage can increase governance frequency when uncertainty is high. A longer stage may reduce management overhead when work is stable and predictable. The appropriate choice depends on risk and decision needs, not a fixed calendar rule.
Management stages versus technical stages
The source distinguishes management stages from technical stages. A management stage is a section of the project for which the Project Board delegates authority to the Project Manager and commits resources. Technical stages describe the use of particular specialist skills or delivery steps, such as design, build, test or commissioning.
Management stages cannot overlap because the Project Manager needs one clear authorised stage baseline at a time. Technical stages may overlap and may cross management-stage boundaries. For example, design work for one product may continue while build work begins for another. The management structure should therefore not be forced to mimic a technical lifecycle if that would create poor decision points.
When designing the plan, first choose management boundaries where a meaningful governance decision can be made. Then map technical delivery activities across those boundaries. This keeps authority, investment decisions and reporting clear while allowing specialists to use the lifecycle that best suits the product.
| Dimension | Management stage | Technical stage / delivery step |
|---|---|---|
| Primary purpose | Governance, resource commitment, authority to spend and management control | Organise specialist work according to technical lifecycle or skills |
| Overlap | No | May overlap |
| Owner of day-to-day control | Project Manager within stage tolerance | Specialist/team management under authorised Work Packages |
| Relationship | Can contain several technical steps or portions of them | May span one or more management stages |
Designing a plan before scheduling
The source calls the first product-based-planning step “design the plan” or the plan prerequisite. Before estimates and dates are built, determine the planning method and presentation. Decide the number and length of management stages, the delivery approach, the relationship between management and technical stages, and the format in which the plan will be communicated.
Format should serve decision-making. A high-level product roadmap, milestone chart or schedule may be suitable for the Project Board, whereas the Project Manager may need a more detailed network or task schedule for the current stage. The source allows corporate, programme or customer planning standards to shape presentation.
Planning design should also identify who contributes. Senior Users bring operational and acceptance knowledge; Senior Suppliers contribute specialist estimates and resource constraints; Team Managers contribute work-package scheduling; Project Assurance checks consistency with the Business Case and tolerances; Project Support may provide planning-tool expertise and baseline control.
Design the plan
Choose stages, delivery approach, format and planning rules.
Define products
Identify what must exist and how products relate.
Identify work
Determine activities and dependencies needed to create the products.
Estimate
Estimate effort, duration, resources and costs.
Schedule
Sequence work and create an achievable timetable.
Document
Record assumptions, controls, budgets, tolerances and narrative needed to use the plan.
Plans as control baselines
A plan has management value only when actual progress can be compared with it. The Project Plan provides the Project Board with the overall baseline and is updated with actuals and revised forecasts as the project progresses. The Stage Plan is detailed enough for the Project Manager to assess the current stage and authorise Work Packages. Team Plans, where used, support specialist control.
Tolerances convert these plans into delegated authority. Project tolerances are set for the Project Board. Stage tolerances are delegated to the Project Manager. Work-package tolerances are agreed with Team Managers. A forecast that the authorised tolerance will be exceeded is not merely a scheduling variance: it means the current level of management no longer has authority to continue unchanged and must escalate.
When an exception is escalated, upper management may decide how the project should recover. If it asks for an Exception Plan, that plan describes the revised path and, once approved, replaces the baseline that could no longer be met. This preserves governance: management does not simply rewrite history by moving the original dates or budget without an explicit decision.
Planning responsibilities in practice
The commissioning authority provides project-level tolerances and planning standards and approves project-level exception plans where required. The Executive approves the Project Plan, defines stage tolerances, approves Stage Plans and commits business resources. Senior Users and Senior Suppliers assist planning and commit resources from their respective interests.
The Project Manager designs the planning approach, prepares the Project and Stage Plans, decides how management stages and delivery steps will be applied, and prepares Exception Plans when directed. Team Managers prepare Team Plans and work-package schedules where these are needed. Project Assurance reviews planning changes and progress for consistency with business needs and tolerances. Project Support can help compile, baseline, store and distribute plans.
This distribution of responsibility improves estimate quality because the Project Manager is not expected to invent specialist detail alone. A practical planning workshop should therefore bring together the people who understand user needs, specialist work, resource availability, risk and governance constraints before the schedule is committed.
Practical verification checklist
- Create a high-level Project Plan that supports the Business Case.
- Use at least an initiation stage and one or more delivery stages.
- Prepare a detailed Stage Plan before each management stage begins.
- Use Team Plans only where they improve control of specialist delivery.
- Treat an Exception Plan as a replacement baseline, not as a routine reforecast.
- Choose management-stage boundaries according to governance and risk, not simply technical phases.
- Apply product-based planning before detailed activity scheduling.
- Document tolerances and use plans as active control baselines.
- Use lessons and updated actuals when planning subsequent stages.
Common mistakes to avoid
- Treating a Gantt chart alone as the complete project plan.
- Planning every distant activity in detail despite low certainty.
- Assuming management stages must match technical phases.
- Allowing management stages to overlap.
- Calling an exception plan a fourth management level.
- Silently rebasing an over-running stage instead of escalating a forecast tolerance breach.