PRINCE2 2017 Project Management Foundations
Understand what makes work a project, what must be controlled, and why successful delivery is judged by more than finishing on time and within budget.
Executive summary
Project versus operations
Projects are temporary, purpose-built management environments used to create one or more agreed business products; routine operations are repetitive, continuing work.
Six performance targets
Time, cost, quality, scope, benefits and risk form the connected set of performance dimensions that the project management team must keep under control.
Management is active
Planning alone is not project management. The method describes planning, delegating, monitoring and controlling while motivating the people doing the work.
Benefits matter
A project that delivers outputs but fails to enable the expected beneficial outcomes cannot be judged solely by schedule and budget performance.
Why a project needs a management method
Project work differs from routine operations because it creates a temporary environment in which people, authority, information and resources are brought together to make a defined change. The supplied material contrasts this with business-as-usual work, which is normally repetitive, ongoing and embedded in the standing organisation. A method becomes useful because temporary work introduces uncertainty, cross-functional interfaces, changing information and a need for explicit decisions that routine work may not require.
The 2017 material presents PRINCE2 as a process-based project management method. Its purpose is not to replace specialist engineering, design, construction, software, procurement or operational methods. Instead, it provides a management layer around specialist work so that the right people can make the right decisions at the right time. This distinction is important: a schedule, a cost model or a project-management software package can support management, but none of them manages the project by itself.
Use the method to govern how a project is justified, organised, planned, delegated, monitored, escalated and closed. Keep the specialist delivery method separate but connected to these management controls.
What counts as a project
The source defines a project as a temporary organisation created to deliver one or more business products according to an agreed business case. Three ideas sit inside that definition. First, the project organisation is temporary: it is assembled for a purpose and is expected to end. Second, attention is directed to products, meaning the outputs that must be created and accepted. Third, the work exists because there is an approved justification for investing resources in it.
Projects also have characteristics that make deliberate management necessary. They are unique in at least some respects, they involve uncertainty, and they commonly cross functional boundaries. Even when a project resembles previous work, the exact combination of people, timing, interfaces, constraints, stakeholders and risks will vary. That is why lessons from previous work can inform a project without turning it into routine operations.
| Characteristic | Project work | Business-as-usual work |
|---|---|---|
| Duration | Temporary; has an intended end point | Continuing or repetitive |
| Organisation | Temporary project structure layered across or beside functional structures | Standing functional or operational structure |
| Purpose | Create defined products and enable change | Maintain ongoing services or operations |
| Uncertainty | Material uncertainty and project-specific risks | Usually more stable and repeatable |
| Control basis | Business case, plans, tolerances, product definitions and staged decisions | Operational policies, procedures, service targets and routine controls |
The six performance targets
The source identifies six aspects of performance that need active management. They are connected, not independent. A change in scope may alter cost, time, quality exposure, risk and the benefits that can ultimately be achieved. Good project control therefore avoids treating one target as the only measure of success.
Time
The schedule and the forecast date for delivery. Management asks whether planned products can be completed within the authorised timescale and tolerance.
Cost
The authorised budget and forecast expenditure. Cost control includes understanding the financial consequence of changes, risks and corrective action.
Quality
Whether products are fit for their intended purpose and meet defined quality criteria and acceptance expectations.
Scope
What the project is expected to deliver. Scope must be sufficiently clear for acceptance, planning and change control.
Benefits
The measurable improvements expected from using the project outputs. Benefits may be realised after the project has closed.
Risk
The uncertainty the project is exposed to and the amount of uncertainty that can be accepted while still protecting the justification and objectives.
Outputs, outcomes and success
A recurring message in the source is that delivering a product is not the same as realising a benefit. The product is an output. People or operations then use the output, producing a change in behaviour or circumstances: an outcome. If that outcome creates a measurable improvement that stakeholders value, the project has enabled a benefit. This distinction prevents teams from declaring success merely because a technical deliverable was completed.
Output
The project creates and hands over a specialist product.
Use
The receiving organisation adopts or operates the product.
Outcome
Use changes behaviour, capability or circumstances.
Benefit
A measurable improvement is confirmed against an agreed baseline.
The same logic also makes room for dis-benefits: negative consequences that are expected to occur as a result of undertaking the project. They differ from threats because they are planned or expected rather than uncertain events. A sound project decision considers benefits, dis-benefits, cost and uncertainty together.
What project management actually does
The source describes project management as planning, delegating, monitoring and controlling all aspects of the project, while motivating those involved to achieve the objectives within the expected performance targets. These actions form a continuous management cycle. Planning defines intended results and constraints. Delegation gives people authority to perform defined work. Monitoring compares actual and forecast performance with the plan. Control means deciding what to do when information indicates that action is required.
Plan
Define products, sequence, resources, responsibilities, controls and tolerances.
Delegate
Authorise work and make accountability clear at the appropriate management level.
Monitor
Collect progress, risk, issue, quality and forecast information at a useful frequency.
Control
Take corrective action within authority, or escalate when a forecast exceeds delegated tolerance.
The information system around those actions matters. The method is designed so that decision-makers receive enough information to act without being drawn into every operational detail. Later articles in this handbook show how management stages, tolerances, reports, registers and exception escalation make that principle practical.
Applying the foundation in a real project
At the start of a project, the foundation can be tested with a small number of disciplined questions. Is the work genuinely temporary and change-oriented, or is it routine operations? What products are expected? What business need or problem makes the work worth doing? Who will use the products? What benefits are expected from that use? What six performance dimensions need explicit targets or tolerance? What authority is available to the project manager and what decisions remain with higher management?
The questions are deliberately broader than “What is the schedule?” because a detailed schedule built around an unclear product or weak justification creates false confidence. Conversely, a clear product and business need without delegated authority or progress controls leaves the project unable to respond when circumstances change. The strength of the method comes from linking justification, organisation, planning, risk, quality, change and progress rather than optimising one control in isolation.
The supplied material is training material for the 2017 edition. It gives the foundation and key method requirements but is not a complete reproduction of every manual detail. No additional mandatory thresholds or clauses have been added here.
Applying the foundations as one management system
The foundations work best when used together rather than as independent definitions. Start by describing the project product and the change it is intended to enable. Identify the customer/user, the supplier capability and the business interest that will justify the investment. Then set meaningful targets for time, cost, quality, scope, benefits and risk. These targets become the basis for planning, tolerance and later decisions.
Next, separate the temporary project from the permanent organisation. The project exists to create agreed products; operational teams normally use those products to create outcomes and benefits. This distinction should be visible in ownership. The project team owns delivery and acceptance work within its authority, while permanent business/user roles own the operational change and benefit realisation that may continue after closure.
Finally, use the definitions to challenge project health. A project that is busy but cannot state its products has weak scope control. A project that can state its products but cannot explain the expected outcome has weak justification. A project that can state benefits but has no owner or measurement path has not completed the value chain. The foundation concepts therefore form a practical diagnostic framework, not merely introductory terminology.
Practical verification checklist
- Confirm the work is temporary, change-oriented project work rather than routine operations.
- State the project products in terms that can later be planned, quality-controlled and accepted.
- Record the business need or problem that makes investment in the project worthwhile.
- Define how time, cost, quality, scope, benefits and risk will be controlled rather than tracking only schedule and cost.
- Separate outputs from outcomes and benefits so that expected value is not confused with technical completion.
- Make delegation and decision authority explicit so that the project manager knows when to act and when to escalate.
- Use specialist delivery methods inside the project-management framework instead of expecting the management method to replace technical practice.
- Plan how useful progress information will reach decision-makers in time for corrective action.
Common mistakes to avoid
- Treating project-management software or a Gantt chart as the project-management method.
- Assuming on-time and on-budget completion proves that expected benefits will be realised.
- Managing scope, cost or schedule independently without considering the effect on the other five performance targets.
- Starting detailed execution before there is enough clarity about products, justification, roles and decision authority.
- Confusing operational work with project work and creating unnecessary temporary governance around routine activity.