4.1 Projects, Project Management and the Seven Performance Targets

4.1 Projects, Project Management and the Seven Performance Targets

Quick summary: A project is a temporary organization created to deliver one or more products according to an agreed business case. Project management is planning, delegating, monitoring and controlling all aspects of it. Version 2 measures success against seven performance targets adopted from PRINCE2 Project Management Version 7: benefits, cost, time, quality, scope, sustainability and risk.

Project and project management

A project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case. Unpacking that:

• Temporary organization — a project is not just a piece of work, it is a structure of people with defined roles, created and then dissolved.
• One or more business products — projects deliver outputs; those outputs enable outcomes; those outcomes realize benefits.
• According to an agreed business case — the justification is not optional and not a one-off. It is agreed at the start and re-tested throughout.

Project management is the planning, delegating, monitoring and control of all aspects of the project, and the motivation of those involved, to achieve the project objectives within the expected performance targets.

The four characteristics that separate a project from business as usual, from section 2.1, are that it is temporary, unique, introduces change, and is delivered by a cross-functional team.

The seven performance targets

This is the single largest structural change from Version 1, and it is very likely to be examined.

Version 1 of PRINCE2 Agile taught the hexagon: six project performance aspects — time, cost, quality, scope, risk and benefits — with rules about which are fixed and which flex. Version 2 replaces the hexagon with the seven performance targets adopted from PRINCE2 7, which add sustainability as a seventh.

A performance target is the baseline against which the success of the project is measured. Each carries a tolerance: the permitted deviation before the matter must be escalated under the manage-by-exception principle.

Sustainability — the target candidates forget

Sustainability entered PRINCE2 with Version 7 and is carried into PRINCE2 Agile Version 2. It asks the project to account for environmental, social and economic impact rather than financial return alone — energy consumption, materials, accessibility, social outcomes, and the long-term maintainability of what is built.

Practically, it appears in the business case alongside the financial appraisal, it can carry its own targets and tolerances, and it connects to agile sustainability — the idea that a delivery pace and a way of working must be maintainable over the long run rather than burning teams out. If a question lists six of the targets and asks which is missing, sustainability is very often the answer.

Fixing and flexing in an agile context

The underlying logic that made Version 1's hexagon useful survives into Version 2's targets, even though the diagram is gone.

In a plan-driven project, scope is treated as fixed and everything specified must be delivered. When reality intervenes, the only variables left to absorb it are time (the project runs late) and cost (it overspends) — and, in practice, quality, because compressed testing is the first casualty of a deadline crunch.

In agile delivery this is inverted. Time and cost are held firm and scope flexes. When an iteration cannot fit everything, the lowest-priority items drop out and the timebox still ends on its date.

For this to be legitimate rather than a euphemism for under-delivery, three conditions must hold:

1. The backlog is genuinely prioritized, so that what drops out is the least valuable work, not the last work looked at.
2. Quality does not flex. The Definition of Done is the guard-rail; dropping scope is permitted, dropping testing is not.
3. The customer accepts that not everything is needed. The lowest-priority tail of a requirements list rarely repays its cost, and an honest prioritization exercise usually reveals a great deal of it.

MoSCoW prioritization is the standard tool: Must have (without which the release is worthless), Should have (important, painful to omit, but there is a workaround), Could have (desirable, dropped first under pressure), and Won't have this time (explicitly excluded from this timebox, so that it is decided rather than forgotten). The Won't have category is the one candidates forget — its value is that exclusion is made explicit rather than left ambiguous.

The flexible scope lives in the Should and Could categories. If everything in a release is a Must have, there is no flexibility, and the project has quietly returned to fixed scope with all the risk that entails.