Project Delivery · Project Control Methods
Product-Based Project Planning and Stage Plans
Product-based planning starts with what must exist and be accepted, then derives the work, resources and schedule required to create it. This guide connects the project plan with detailed stage plans, optional team plans, work packages and exception plans so planning supports communication, delegation, forecasting and staged investment rather than becoming a static activity list.
Executive summary
What this guide enables
Product-based planning starts with what must exist and be accepted, then derives the work, resources and schedule required to create it. This guide connects the project plan with detailed stage plans, optional team plans, work packages and exception plans so planning supports communication, delegation, forecasting and staged investment rather than becoming a static activity list.
Learning outcomes
- Create a product-led planning baseline before estimating activities.
- Distinguish project, stage, team and exception plans by decision purpose.
- Design management stages around planning horizon and investment decisions.
- Build a credible schedule from dependencies, resources, risk and quality work.
Control guidance
Planning as a control and communication system
A plan defines what will be delivered, how and where it will be delivered, by whom, when and at what cost. It also explains the assumptions, dependencies, quality activities, resources, controls and tolerances that make the forecast credible. Its purpose is not to predict the future with artificial precision; it creates a common basis for authorising work, comparing actual and forecast performance, testing the business case and deciding when management intervention is required.
Planning should reflect the available horizon. The overall project plan shows major products, stages, milestones, resource demand, cost and benefits at a level suitable for investment control. The next management stage is planned in greater detail because near-term information is more reliable. Later stages remain progressively elaborated. This avoids both extremes: committing to detailed dates that are unsupported by knowledge, and starting delivery without a controllable near-term baseline.
The plan must be product-oriented. Activity plans can hide incomplete scope because teams can report effort without demonstrating usable output. Product descriptions establish the definition of done; a product breakdown structure establishes scope; a product flow shows logical order and interfaces; activities and resources are then derived from the work needed to create, review and approve those products.
Communication
Aligns decision-makers, managers, users and suppliers around products, dates, assumptions and responsibilities.
Authorisation
Defines the work and exposure approved at project, stage and work-package levels.
Forecasting
Provides the baseline and remaining-work model used to predict outcomes.
Control
Connects tolerances, checkpoints, quality events and stage gates to decisions.
Control guidance
The planning hierarchy
The project plan provides the governing body's high-level view for the whole project. It supports the business case, shows management stages and indicates overall products, milestones, cost, resource requirements and major dependencies. It is baselined during initiation and updated at stage boundaries and approved exceptions. It should be detailed enough to judge viability while avoiding unsupported detail for distant work.
A stage plan is the detailed baseline for one management stage. It is owned by the project manager and authorised by the governing body. It contains the products, activities, resources, controls and tolerances needed for day-to-day management. Team plans are optional and help delivery leads organise one or more work packages. They sit within the authorised package and do not change its products or tolerances without agreement.
An exception plan replaces the plan that is forecast to exceed tolerance; it does not run alongside the failed baseline indefinitely. It may replace a stage plan or, for a project-level exception, the project plan. It starts from the current position, describes recovery products and work, and is approved by the authority that set the affected tolerance.
| Plan | Decision audience | Planning horizon | Control use |
|---|---|---|---|
| Project plan | Governing and commissioning authorities | Whole project at suitable summary | Viability, stages, overall forecast and project tolerance |
| Stage plan | Governing body and project manager | One management stage in operational detail | Stage authorisation and day-to-day control |
| Team plan | Delivery lead and project manager | One or more work packages | Team coordination and checkpoint forecasting |
| Exception plan | Authority that set affected tolerance | Remainder of replaced stage or project | Recovery or revised delivery authorisation |
Control guidance
Design the plan before adding dates
Plan design establishes the planning prerequisites: scope and objectives, available standards and tools, units of estimating, required levels of plan, stage boundaries, reporting and control needs, planning roles, data sources and how baselines will be approved. Decide how uncertainty and contingency will be represented and how supplier schedules will integrate. Without this design, different teams may use incompatible assumptions and status rules.
Management-stage boundaries should follow decision value. Suitable points include completion of feasibility, approval of a major design, commitment to a contract, readiness for installation, release to users or transition into operations. Technical stages organise specialist work and may overlap; they are not automatically management stages. A management stage controls commitment and authority, while a technical stage groups work by discipline or method.
Plan presentation should suit the decision. A product map, milestone schedule, dependency network, cost profile and responsibility table may communicate better than one enormous Gantt chart. The authoritative data may reside in planning tools, but the approved baseline, assumptions and status date must be unambiguous.
| Boundary driver | Why it creates decision value | Evidence expected at the gate |
|---|---|---|
| Uncertainty reduction | Later commitment depends on feasibility or test results | Approved findings, updated risk and viable next-stage plan |
| Major expenditure | Commitment is difficult or expensive to reverse | Business-case confirmation, funding and contract readiness |
| Product maturity | Downstream work requires an approved baseline | Product approval, configuration status and dependency release |
| Operational impact | Deployment affects service, safety or production | Acceptance, transition, rollback and support readiness |
Control guidance
Define and analyse the products
- 1
Write the project product description
Define the final product, purpose, composition, customer expectations, acceptance criteria, tolerance, method and acceptance authority.
- 2
Create the product breakdown
Decompose the final product into manageable specialist and supporting products until ownership, estimation and acceptance are practical.
- 3
Write product descriptions
For each significant product, document purpose, composition, derivation, format, criteria, method, tolerance, reviewer and approver.
- 4
Create the product flow
Arrange products in logical creation and dependency order, showing parallel work, external inputs and approval dependencies.
- 5
Check completeness and interfaces
Confirm every acceptance need is supported, no product is orphaned, and responsibility for externally supplied inputs is explicit.
A product breakdown is a scope model, not an organisation chart or task list. It should include management or enabling products only when they are part of the planning purpose; the hierarchy must make specialist delivery visible. A product flow is strongly recommended when sequence is not obvious. It reveals missing inputs, approval lead times and opportunities for parallel delivery before schedule commitments are made.
Decomposition should stop when a product can be assigned, estimated, verified and controlled. Excessive decomposition creates maintenance effort and hides the main outcomes; insufficient decomposition leaves broad packages that cannot be forecast. The correct depth can vary by stage and risk.
Control guidance
Estimate, schedule and resource the work
Activities are derived from the creation, review, approval and handover of products. Estimate effort, duration, cost and resource need separately where they differ. Duration depends on resource availability, productivity, calendars, constraints and waiting time; it is not simply effort divided by an assumed headcount. Include procurement, approvals, testing, rework, data preparation, training and transition work rather than scheduling only technical creation.
Build the dependency network before fixing dates. Identify mandatory logic, discretionary sequence and external dependencies. Locate the path or paths that drive the completion forecast and examine near-critical work where small delays could become controlling. Resource-limit the schedule, check specialist bottlenecks and resolve overload through sequence, scope, capacity or stage design rather than leaving impossible simultaneous assignments.
Risk responses and contingency belong in the plan. Some responses are explicit activities or products; residual uncertainty may justify time or cost reserve under defined authority. Do not hide contingency by padding every estimate. State the estimating basis, confidence and assumptions so later forecast changes can be understood.
Forecast finish = status date + resource-feasible duration of remaining dependency path + authorised contingencyUse current remaining work and constraints. Repeating the original duration after evidence has changed is not a forecast.
Schedule credibility check
- All products have creation and approval work
- External inputs and decision lead times are visible
- Resource calendars and specialist bottlenecks are applied
- Mandatory and discretionary dependencies are distinguished
- Risk responses and contingency are explicit
- Milestones represent evidence or decisions, not arbitrary dates
- Cost and cash-flow profiles align with the schedule
- Assumptions and estimating basis are recorded
Control guidance
Authorise work through work packages
A work package is the agreement between the project manager and a delivery lead for creating one or more products. It references product descriptions, constraints, interfaces, production and quality methods, reporting frequency, problem and escalation arrangements, resources, tolerances, approval and handover. It may be a short controlled record or part of a contract, but it must distinguish authorised work from informal requests.
The package should be negotiated. The delivery lead checks feasibility, capability, dependencies and acceptance before accepting it. The project manager confirms that it sits inside the approved stage plan and that package tolerances do not threaten stage tolerance. Checkpoint reports then focus on product status, remaining work, forecast, issues, risk and decisions rather than a subjective percentage complete.
Completion requires approved products and records, not the exhaustion of budget or time. When products change, the package and plan need controlled updates. When a package forecast exceeds tolerance, the delivery lead raises an issue to the project manager early enough for correction or escalation.
| Control question | Evidence to inspect | Decision or response |
|---|---|---|
| Is the package authorised? | Approved stage plan, product descriptions, budget, resources and tolerance | Accept, negotiate or reject authorisation |
| Is delivery on forecast? | Product status, remaining work, dependency and quality evidence | Continue, correct or raise a forecast deviation |
| Is the package complete? | Approved product versions, records, handover and open-item disposition | Accept completion or return for action |
Control guidance
Plan control, updating and exceptions
A baseline is the approved version against which performance is controlled. Status updates should use a defined data date and preserve the baseline while recording actual start and finish, remaining duration, cost commitments, product status and forecast. Replanning within tolerance may adjust operational detail, but changes to approved scope, quality, stage or project commitments require the defined issue and change route.
At a stage boundary, compare actual performance with the stage plan, update the project plan using current evidence, prepare the next stage in detail and refresh the business case and risk profile. Lessons from estimating, suppliers, quality and controls should change future planning. The governing body then decides whether the next commitment remains justified.
If a stage or project is forecast beyond tolerance, prepare an exception report first. Governance decides whether an exception plan is required. The exception plan begins from the actual current position and replaces the affected plan when approved. It should not erase variance history or pretend the original baseline was achieved.
Turning an activity plan into a controllable stage plan
Situation: A draft plan lists design, procurement, build and install tasks, but it has no acceptance events, supplier inputs or operational handover products. The end date appears achievable only because approvals and training are absent.
- The team writes the final and component product descriptions, including installation acceptance and support readiness.
- A product flow reveals that a data approval and long-lead component are external inputs to build, while training material depends on the approved final configuration.
- Activities, resources and review lead times are derived from the flow; the schedule is resource-limited and risk responses are added.
- The stage boundary is placed before installation because shutdown commitment and operational exposure justify a decision gate.
Control outcome: The revised plan may show a later forecast, but it is credible, evidence-based and capable of supporting authorisation.
Is a Gantt chart the project plan?
It can be one view. A complete control plan also includes products, assumptions, resources, cost, quality, controls, tolerances and responsibilities.
Must every project have team plans?
No. A delivery lead needs a workable way to organise accepted work; a separate formal team plan is optional.
Can technical phases be management stages?
Yes when their boundaries also create suitable investment and authority decisions. They should not be aligned mechanically.
What does an exception plan replace?
The approved stage plan or project plan whose tolerance is forecast to be exceeded, once the relevant authority approves the replacement.