14.1 Tailoring to Project Environment, Scale & Agile
Key Takeaways
- Tailoring adapts PRINCE2 to the project's environment, scale, complexity, risk, and organisation, and every tailoring decision is documented in the Project Initiation Documentation (PID).
- Valid tailoring scales a control's effort to the project's risk — it never removes a PRINCE2 principle or strips a control of its purpose.
- Common tailoring levers are combining or simplifying management products, adjusting roles (for example merging Senior User and Senior Supplier on a small, low-risk project where one person can genuinely perform both), scaling processes, and simplifying plans.
- PRINCE2 7 integrates agile-friendly concepts — iterative delivery, frequent feedback, co-creation, and the people element — and the dedicated PRINCE2 Agile extension adds deeper agile techniques while keeping PRINCE2 governance.
- When tailoring for agile delivery, stage boundaries, tolerances, and the Business Case still provide governance; agile changes how products are built inside a stage, not whether the board re-justifies the project at stage end.
What Tailoring Means in PRINCE2 7
Tailoring is the deliberate adaptation of PRINCE2 to suit the project's environment, scale, complexity, risk, and organisation. The method is not a rigid checklist to apply identically to a two-week research study and a three-year infrastructure programme. Tailoring is the mechanism that keeps the method proportionate: enough governance to control risk, not so much bureaucracy that the team cannot move.
A useful mental model is that principles are immutable, practices and processes are scalable, and management products are combinable. You cannot tailor away the principle manage by exception — but you can scale the tolerance structure so that a small project carries a single stage with wider tolerances rather than three narrow stages. You cannot tailor away the focus on products principle — but you can combine the Project Product Description with a lightweight Product Description for a simple project where the deliverable is one report.
Every tailoring decision is documented in the Project Initiation Documentation (PID) so that the Project Board, Project Manager, and team share a common understanding of how the method is being applied. The PID's controls section is the natural home: it states what has been simplified, what has been combined, and why. A decision to combine Senior User and Senior Supplier that lives only in the PM's head is not tailoring — it is an uncontrolled deviation.
Tailoring Levers
| Lever | What you change | Example |
|---|---|---|
| Combine management products | Merge related documents into one | PID includes a combined Quality, Risk, and Change Management Approach for a small project |
| Simplify management products | Reduce a product to its essential content | A one-page Stage Plan for a two-week stage instead of a multi-page plan |
| Adjust roles | Merge roles where one person can genuinely perform both | Senior User and Senior Supplier combined on a small, single-supplier project |
| Scale processes | Perform a process lighter or fold it into another | Directing a Project activities performed by a single sponsor on a small project |
| Simplify plans | Reduce plan layers | A single Project Plan with no separate Stage Plans for a short, low-risk project |
| Scale tolerances | Wider or narrower limits | Wider cost tolerances on a low-risk internal study |
The test for any tailoring decision is: does this still achieve the control's purpose at a level proportionate to the project's risk? If combining the issue and risk entries into one Project Log section still captures, assesses, and routes issues and risks, the combination is valid. If it means risks are lost because there is no structured place to record them, the tailoring has broken the control.
Tailoring to Commercial and Programme Context
PRINCE2 is designed for a customer/supplier environment, and tailoring often reflects where the project sits in that relationship. A project delivered inside a programme may inherit programme-level controls — programme tolerances, programme reporting cadence, programme quality standards — and the project's tailoring should state which controls are delegated to the project and which are owned by the programme. A standalone project has no programme overhead and must carry its own full governance, though it can still simplify where scale allows.
A project with an external supplier under a fixed-price contract will typically tailor a stricter Change Management Approach (so that scope changes flow through contractual change control) and a formal Product Description for each deliverable that the supplier must meet. An internal project with a co-located team may relax formality but should still record work packages and Checkpoint Reports so that progress is visible.
Tailoring for Agile Delivery
PRINCE2 7 is explicitly designed to support agile delivery. The method's co-creation emphasis, the people element, and the focus on products principle all align with agile behaviours: iterative delivery, frequent feedback, self-organising teams, and working products over comprehensive documentation.
Two things must be kept distinct in the exam:
- PRINCE2 7 itself integrates agile-friendly concepts. You can deliver a project using agile techniques inside PRINCE2 stages — short iterations, daily stand-ups, retrospectives, a prioritised backlog — while the PRINCE2 governance (stage boundaries, tolerances, Business Case, Project Board authorisation) wraps around the agile delivery.
- PRINCE2 Agile is the dedicated extension that adds deeper agile techniques — the Agilometer, Cynefin, MoSCoW prioritisation, timeboxing, and the five targets — on top of PRINCE2 governance. It is a separate qualification and a richer integration, not a replacement for PRINCE2.
The critical rule for agile tailoring is the same as for any tailoring: governance controls are scaled, not removed. A common exam trap is a scenario where an agile team proposes dropping stage boundaries because we iterate continuously. That is invalid tailoring: the Project Board still needs a point at which it re-justifies the project, reviews the Business Case, and authorises the next tranche of work. What can change is the content of a stage — a stage may contain several iterations, and the Stage Plan may be expressed as a release plan with iteration goals rather than a Gantt chart.
Valid vs Invalid Tailoring — A Quick Test
| Scenario | Valid? | Why |
|---|---|---|
| Combine Senior User and Senior Supplier on a 3-person internal project | Yes (if one person genuinely performs both roles) | Role merging is permitted when the role purposes can still be met |
| Drop the Business Case because the project is low cost | No | The Business Case is the project's justification — removing it breaks the continued business justification principle |
| Replace a Stage Plan with a release plan showing iteration goals | Yes | The Stage Plan's purpose (what will be delivered, when, at what cost/risk) is preserved in an agile format |
| Skip Managing a Stage Boundary because the team uses continuous delivery | No | The board still needs a re-justification point; the process can be lighter but cannot be removed |
| Combine the Quality and Risk Management Approaches into one section of the PID | Yes (for a small, low-risk project) | Management products can be combined when their purposes are still served |
A well-tailored project feels like PRINCE2 at the right weight: the principles are visible, the practices are working, the processes happen at the right points, and nothing is done purely because the manual says so.
A Project Manager proposes combining the Senior User and Senior Supplier roles on a small, single-supplier project where the same executive will both champion the product and oversee the supplier. Where must this tailoring decision be recorded, and what is the governing test of whether it is valid?
An agile delivery team proposes removing stage boundaries entirely because they iterate continuously and release every two weeks. According to PRINCE2 7 tailoring rules, which statement is correct?