4.3 Tailor to Suit the Project

Why Tailoring Is Required

Tailor to suit the project means PRINCE2 is adapted to the project's environment, scale, complexity, risk, and organisation — it is never applied verbatim. A two-week, low-risk internal project and a multi-year, high-risk capital programme both use PRINCE2, but the way they apply it differs. The method is designed to be scaled, not bolted on wholesale.

What tailoring adjusts

Tailoring can combine or omit management products, adjust roles, and scale processes:

• Management products — a small project may combine the End Project Report and End Stage Report, or roll the Issue Register into the Daily Log. The information still exists; it lives in fewer documents.
• Roles — one person may hold several roles (for example, Executive and Senior User on a small internal project), or a role may be split across several people on a large programme. The responsibilities remain; who holds them changes.
• Processes — the formality of a process is scaled. A one-page Highlight Report may replace a multi-section report; a daily stand-up may supplement or replace checkpoint reporting. The control purpose is retained.

What tailoring never does

The critical exam point: tailoring never abandons PRINCE2 controls or principles. It scales them while keeping their purpose. A board that wants to cut all documentation is not asking for tailoring — it is asking to drop controls. The correct response is to combine management products and reduce formality, not to delete the controls themselves.

Documenting the approach

The tailoring approach is documented in the Project Initiation Documentation (PID) so that everyone understands how PRINCE2 is being applied on this project. The PID records which management products are combined or omitted, how roles are allocated, and the level of process formality. The Project Board approves the PID, which means the board agrees the tailoring before delivery proceeds.

Factors that drive tailoring decisions

• Scale — number of people, budget, and duration.
• Complexity — technical, organisational, and contractual interdependencies.
• Risk — higher risk demands tighter controls and more formal reporting.
• Organisation — existing governance, reporting lines, and corporate standards.
• Environment — regulatory, geographic, and cultural factors.

A higher-risk project tailors up (more formal controls, more frequent reporting); a lower-risk project tailors down (combined documents, lighter reviews). Both still apply the full set of principles.

Worked scenario — tailoring two projects differently

Project X — two-week internal process review, low risk, one team.

• Management products: combine the Project Brief and PID into one short document; roll the Issue Register and Daily Log into a single log; combine End Stage Report with the next Stage Plan.
• Roles: one person holds Executive, Senior User, and Senior Supplier; the Project Manager also runs team tasks.
• Processes: weekly one-page Highlight Report instead of multi-section reporting; checkpoint reporting replaced by a 15-minute daily stand-up.
• Controls retained: Business Case (one paragraph), stage boundaries (two stages), quality criteria (peer review), risk register (top three risks only).

Project Y — 18-month regulatory programme, high risk, three suppliers.

• Management products: full PID, separate Stage Plans, separate Issue and Risk Registers, formal End Stage Reports.
• Roles: full Project Board with distinct Executive, Senior User, Senior Supplier; separate Change Authority; dedicated Project Manager and Team Managers per workstream.
• Processes: formal Highlight Reports, checkpoint reports from each team, quality inspections with independent reviewers.
• Controls retained: the same set as Project X — only the formality and volume differ.

Both projects apply all seven principles. Project X tailors down; Project Y tailors up. Neither drops a control. The difference is one of degree, not of principle.

Tailoring at practice and process level

Tailoring operates at three layers:

• Method level — how the method as a whole is presented, for example integrated with an organisation's existing PMO framework or paired with an agile delivery approach.
• Practice level — how each practice is applied. The Quality practice on a small project may use peer review rather than formal inspection; the Risk practice may use a simple top-5 list rather than a weighted register; the Issues practice may rely on the daily-log entries in the Project Log rather than a separately maintained issue register. The practice's purpose is retained; its form scales.
• Process level — how each process is performed. Directing a Project on a small project may involve a short email authorisation rather than a full board meeting; Managing a Stage Boundary may combine the End Stage Report with the next Stage Plan in one document.

Common traps in tailoring questions

• "Small project, so no controls needed." Wrong. Small projects tailor down the formality of controls; they do not remove them. The Business Case, stage boundaries, and quality criteria all remain.
• "Agile project, so PRINCE2 does not apply." PRINCE2 7 explicitly supports agile delivery through tailoring — workstreams can be run as sprints with product descriptions written as user stories, while PRINCE2 provides the project-level controls and reporting.
• "The board approved dropping the Business Case." Even board approval cannot authorise removing a principle; principles are mandatory. The board can approve a lighter Business Case, not its removal.
• Tailoring not documented. If the PID has no tailoring section, the project has not satisfied the principle even if it is in fact scaling controls informally — the approach must be explicit and agreed.
• Confusing tailoring with exception handling. Tailoring is decided up front and recorded in the PID; an exception is a forecast breach during delivery. They are different mechanisms for different moments.

Common exam scenarios

Exam questions often present a board or sponsor who wants to remove documentation or controls to save time. The correct answer is rarely to remove the control; it is to combine the management product, reduce formality, and retain the purpose. A scenario where a project has no PID tailoring section suggests tailoring was not considered or documented — a defect, since the principle requires the approach to be explicit and agreed.