14.3 Tailoring PRINCE2 to Agile, Scale, Commercial Environment & Sustainability

Tailoring PRINCE2 to Agile, Scale, Commercial Environment & Sustainability in PRINCE2 7

Practitioner Core Mandate: Project governance must never become a thoughtless bureaucratic ritual. Applying a 50-page documentation framework designed for a nuclear power station to a two-week internal software update is an exercise in administrative paralysis; conversely, attempting to govern a high-risk multi-million-dollar infrastructure joint venture with informal verbal chats invites catastrophic failure. The core principle Tailor to Suit the Project Context ensures that PRINCE2 remains agile, proportionate, and effective across any industry, organizational culture, or delivery methodology. Mastery of tailoring is what separates certified practitioners from theoretical exam candidates.

---

1. The Tailoring Principle: Mandatory Application & Boundary Rules

What is Tailoring in PRINCE2?

Tailoring is the act of adapting the PRINCE2 method to suit the scale, complexity, organizational environment, importance, team capability, delivery method, and risk profile of a specific project. Tailoring ensures that:

• Governance overhead is proportionate to the project's risk exposure and investment value.
• Terminology, management products, and reporting cycles align with organizational culture and existing business systems.
• Controls remain robust and effective without imposing unnecessary administrative burden.

                 THE BOUNDARIES OF PRINCE2 TAILORING

   ┌─────────────────────────────────────────────────────────────┐
   │ NON-NEGOTIABLE CORE: THE SEVEN PRINCIPLES                   │
   │ (Universal, mandatory, absolute — CANNOT be tailored)       │
   │                                                             │
   │ 1. Ensure continued business justification                  │
   │ 2. Learn from experience                                    │
   │ 3. Defined roles, responsibilities, and relationships       │
   │ 4. Manage by stages                                         │
   │ 5. Manage by exception                                      │
   │ 6. Focus on products                                        │
   │ 7. Tailor to suit the project context                       │
   └──────────────────────────────┬──────────────────────────────┘
                                  │ Directs and bounds
                                  ▼
   ┌─────────────────────────────────────────────────────────────┐
   │ THE TAILORABLE PERIMETER:                                   │
   │ (Flexible, adaptable, scalable — MUST be tailored)          │
   │                                                             │
   │ • PRACTICES: Adapted procedures, scoring matrices, tools    │
   │ • PROCESSES: Activities combined, streamlined, or refocused │
   │ • ROLES: Roles combined or delegated (maintaining limits)   │
   │ • PRODUCTS: Combined, decomposed, converted to digital apps │
   │ • TERMINOLOGY: Aligned with corporate or agile lexicons     │
   └─────────────────────────────────────────────────────────────┘

What Can and Cannot Be Tailored

A primary testing area on the Practitioner exam is understanding the strict boundary of tailoring:

• What CANNOT be tailored: The Seven Principles are absolute and non-negotiable. If a project team abandons or violates any of the seven principles, it is not managing a PRINCE2 project. This anti-pattern is known as "PRINCE2 in Name Only" (PINO).
• What CAN be tailored:
  • Practices: Procedures (such as risk management steps or change control workflows), toolchains, scoring matrices, and registers.
  • Processes: Activities within processes can be streamlined, merged, or adapted to corporate governance tempos.
  • Roles and Responsibilities: Project roles can be combined, delegated, or mapped to corporate titles (subject to explicit separation-of-duty constraints).
  • Management Products: Formal baseline documents can be condensed, formatted as digital wiki pages, slide presentations, Jira boards, or combined into single composite products.
  • Terminology: Words and labels can be adapted to match corporate standards (e.g., calling "Highlight Reports" "Sprint Summaries" or "Work Packages" "Sprint Backlogs").

Tailoring vs. Embedding

Practitioners must distinguish between two related concepts:

• Embedding: What an organization does to adopt PRINCE2 across its business—integrating PRINCE2 into corporate policies, standard operating procedures, PMO toolchains, career paths, and cultural training.
• Tailoring: What a Project Manager and Project Board do on a specific project to adapt the embedded organizational method to the unique context of that individual initiative.

---

2. Dimension 1: Tailoring for Agile Delivery Frameworks

One of the most powerful applications of PRINCE2 7 is its seamless compatibility with agile delivery frameworks (such as Scrum, Kanban, SAFe, and XP). PRINCE2 does not compete with agile; it provides the governance architecture (steering, directing, funding, business justification, and stage control) within which agile teams execute iterative product development.

┌─────────────────────────────────────────────────────────────────────────────┐
│               THE PRINCE2 AND AGILE COLLABORATIVE ARCHITECTURE              │
├─────────────────────────────────────────────────────────────────────────────┤
│ PROJECT GOVERNANCE LAYER (PRINCE2 DIRECTION & MANAGEMENT)                   │
│ • Directing a Project (Project Board): Why, When, Investment, Direction     │
│ • Controlling a Stage (Project Manager): Stage tolerances, boundary reviews │
│ • Focus on Products: Baselines, business justification, governance gates    │
├─────────────────────────────────────────────────────────────────────────────┤
│                          ▲                            │                     │
│         Highlight Reports│                            │ Work Packages       │
│         & Escalations    │                            │ & Tolerances        │
│                          │                            ▼                     │
├─────────────────────────────────────────────────────────────────────────────┤
│ SPECIALIST DELIVERY LAYER (AGILE EXECUTION IN MANAGING PRODUCT DELIVERY)    │
│ • Team Managers / Scrum Masters: Sprint backlogs, stand-ups, WIP limits     │
│ • Agile Delivery Teams: 2-week sprints, CI/CD pipelines, daily releases     │
│ • Product Owners: Story grooming, acceptance verification, backlog priority │
└─────────────────────────────────────────────────────────────────────────────┘

Integrating Key Concepts: PRINCE2 vs. Agile

Managing by Exception in Agile (The Flexing Mindset)

In traditional predictive waterfall projects, scope and quality are often fixed, while time and cost flex. In an agile PRINCE2 project, this relationship is inverted:

• Time and Cost are Fixed (Timeboxed): Sprints and management stages operate on fixed durations and resource allocations.
• Scope and Quality Specifications are Flexed: Tolerances are established around scope (using MoSCoW prioritization—Must have, Should have, Could have, Won't have). The team delivers 100% of the "Musts", flexing "Shoulds" and "Coulds" within agreed stage tolerances to guarantee timely delivery without compromising core functionality.

Mapping Agile Roles into the Project Management Team

• Senior User: Often represented by or partnered with the Lead Product Owner, ensuring that business user priorities drive the agile backlog.
• Team Manager: Naturally filled by a Scrum Master, Agile Delivery Lead, or Product Owner, who manages the delivery team and interfaces with the Project Manager.
• Project Manager: Remains focused on overall project direction, Business Case viability, stage boundaries, stakeholder management, and cross-team dependencies, avoiding day-to-day micromanagement of sprint tasks.

---

3. Dimension 2: Tailoring for Scale and Complexity (Small vs. Large Projects)

Tailoring for Small or Low-Complexity Projects ("Simple Projects")

When applying PRINCE2 to small, low-risk, or short-duration initiatives, the objective is to eliminate administrative friction while preserving governance integrity:

┌─────────────────────────────────────────────────────────────────────────────┐
│                  TAILORING FOR SMALL / SIMPLE PROJECTS                      │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. ROLE COMBINATIONS:                                                       │
│    • Project Executive absorbs the Senior User role (business & user)       │
│    • Project Manager acts as Team Manager and provides Project Support      │
│    • CRITICAL RULE: Project Executive and PM roles can NEVER be combined!   │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. PROCESS COLLAPSING:                                                      │
│    • Starting Up (SU) and Initiating (IP) combined into a single workshop   │
│    • Number of stages reduced to exactly TWO: Initiation + 1 Delivery stage │
│    • CRITICAL RULE: A project must have at least two stages!                │
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. DOCUMENT CONSOLIDATION:                                                  │
│    • Project Brief and PID merged into a concise 4-page briefing document   │
│    • Risk, Issue, and Quality Registers merged into the PM's Daily Log      │
│    • Highlight Reports delivered verbally during brief weekly stand-up syncs│
└─────────────────────────────────────────────────────────────────────────────┘

[!CRITICAL EXAM RULE] Two Inviolable Rules for Small Projects:

1. The Project Executive and Project Manager can NEVER be the same person. Combining direction and day-to-day management destroys independent oversight and accountability.
2. A project MUST have at least two management stages. A "one-stage project" is impossible in PRINCE2 because initiation (the Initiation Stage) must be authorized and separated from delivery (the Delivery Stage).

Tailoring for Large, High-Complexity, or Mega Projects

On multi-million-dollar infrastructure, aerospace, or public-sector transformations, governance must scale upward:

• Expanded Project Board: Multiple Senior Users representing disparate operational departments; multiple Senior Suppliers representing specialized technical domains.
• Dedicated Roles: Independent Project Assurance roles appointed for Business, User, and Supplier interests; a dedicated Project Support office (PMO) handling configuration and registers.
• Dedicated Change Authority: A formally chartered Change Authority equipped with a substantial Change Budget to process high volumes of Requests for Change.
• Multiple Management Stages: Dividing delivery into numerous stages aligned with major investment decision gates, technical feasibility milestones, or funding tranches.
• Programme Governance Integration: Aligning Project Board decision gates with overarching Programme Management (e.g., MSP) governance and corporate portfolio reviews.

---

4. Dimension 3: Tailoring for Commercial Customer/Supplier Environments

When a project is commissioned by an external customer and delivered by a commercial contractor, the organizational dynamics fundamentally alter. The customer and supplier are independent legal entities with different corporate motivations, risk tolerances, and accounting standards.

┌─────────────────────────────────────────────────────────────────────────────┐
│         THE DUAL PERSPECTIVE IN COMMERCIAL CUSTOMER/SUPPLIER PROJECTS       │
├─────────────────────────────────────────────────────────────────────────────┤
│ CUSTOMER PERSPECTIVE (BUYER)             SUPPLIER PERSPECTIVE (SELLER)      │
│                                                                             │
│ • Business Case Focus: Value for money,  • Business Case Focus: Revenue,    │
│   operational benefits, business ROI,      profit margins, billable hours,  │
│   and long-term strategic alignment.       intellectual property, capability│
│                                                                             │
│ • Project Executive: Customer director      • Senior Supplier: Vendor exec  │
│   accountable for investment.              accountable for technical delivery│
│                                                                             │
│ • Governance Instrument: Commercial      • Governance Instrument: Contractual│
│   procurement contract, RFP, SLA.          statement of work (SOW), task ord│
│                                                                             │
│ • Stage Gate: Authorize funding for      • Stage Gate: Milestones triggered,│
│   subsequent contractual stage.            progress invoices submitted.     │
└─────────────────────────────────────────────────────────────────────────────┘

Key Tailoring Mechanisms in Commercial Projects

1. The Dual Business Case: There is never a single shared Business Case. The customer maintains a Business Case justifying the capital expenditure against anticipated business benefits. The supplier maintains an internal Business Case justifying the bid against commercial profit margins, contract risks, and strategic market positioning.
2. Contractual Alignment of Work Packages: In commercial settings, Work Packages correspond directly to legally binding Statements of Work (SOW), task orders, or purchase agreements. Acceptance criteria in Product Descriptions serve as legal verification criteria for contractual sign-off.
3. Change Management and Contractual Variations: Any change affecting project scope, delivery approach, or tolerances must comply with formal contract variation clauses. The Change Management Approach must explicitly incorporate commercial legal reviews, dispute escalation pathways, and formal contractual change orders.
4. Multi-Supplier Ecosystems: When a prime contractor manages subcontractors, the Senior Supplier role on the Project Board is typically held by the prime contractor's account director, who coordinates subcontractor performance and provides unified supplier assurance to the Board.

---

5. Dimension 4: Tailoring for Sustainability and ESG (PRINCE2 7 Seventh Target)

PRINCE2 7 firmly embeds environmental, social, and economic sustainability into project management. Sustainability is no longer a peripheral corporate social responsibility (CSR) afterthought; it is one of the seven core project performance targets, requiring systematic tailoring across the entire lifecycle.

┌─────────────────────────────────────────────────────────────────────────────┐
│               EMBEDDING SUSTAINABILITY ACROSS THE LIFECYCLE                 │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. INITIATING A PROJECT (IP):                                               │
│    • Prepare the SUSTAINABILITY MANAGEMENT APPROACH (standards, toolchains) │
│    • Baseline explicit sustainability tolerances across the project         │
│      (e.g., max 50 tonnes embodied carbon, 90% recyclable components)       │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. PLANS & PRODUCT DESCRIPTIONS:                                            │
│    • Specify environmental standards and circular-economy criteria into     │
│      Product Descriptions (e.g., energy efficiency ratings, fair trade)     │
│    • Factor sustainable procurement and recycling logistics into schedules  │
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. CONTROLLING A STAGE & PRODUCT DELIVERY:                                  │
│    • Work Packages mandate environmental controls (waste sorting, low power)│
│    • Checkpoint and Highlight Reports monitor carbon/waste KPI variances    │
│    • Sustainability exceptions escalated to Project Board via Exception Rep │
├─────────────────────────────────────────────────────────────────────────────┤
│ 4. CLOSURE & POST-PROJECT:                                                  │
│    • End Project Report audits actual carbon/ecological impact vs baselines │
│    • Benefits Management Approach schedules post-project operational        │
│      sustainability reviews (e.g., 5-year solar energy generation metrics)  │
└─────────────────────────────────────────────────────────────────────────────┘

Sustainability Tailoring in Action

• Sustainability Tolerances: Defining permissible variances for environmental metrics (e.g., carbon footprint: 1,000t CO2e +0%/-10%; construction waste to landfill: 0% tolerance).
• Product Acceptance Criteria: Explicitly embedding ESG metrics into acceptance checklists (e.g., server equipment must carry Energy Star 8.0 certification; office furnishings must be 100% FSC-certified).
• Commercial Procurement: Weighting sustainability criteria in supplier selection tenders, making carbon reporting a contractual obligation in supplier Work Packages.
• Dis-benefits Realization: Explicitly quantifying environmental dis-benefits in the Business Case (e.g., temporary habitat disruption during solar farm installation) and defining mitigating ecological offsets.

---

6. Comprehensive Tailoring Matrix Across the Four Dimensions

---

7. Practical Scenario Evaluations

Scenario A: The Agile Purist Who Abandons Business Justification ('PINO')

An online fashion retailer transitions its e-commerce website redevelopment to an agile delivery model. The lead Scrum Master convinces the executive sponsor that because they work in two-week sprints with continuous user story refinement, maintaining a Project Board, approving Stage Plans, and updating a Business Case is 'rigid waterfall bureaucracy.' Sprints run continuously for 14 months. Over £1.8M is spent developing elaborate virtual-reality dressing room features that generate zero customer engagement, while the original business case objectives—cutting checkout friction and increasing mobile conversion—are completely neglected.

Practitioner Evaluation:

• Governance Failure: Degeneration into "PRINCE2 in Name Only" (PINO). The team abandoned the non-negotiable principles of Ensure continued business justification, Manage by stages, and Defined roles and responsibilities.
• PRINCE2 Violation: Tailoring allows Work Packages and technical delivery to use Scrum sprints, but the project must retain management stages, Project Board direction, and periodic Business Case verification. Agile delivery without business case governance is merely uncontrolled organizational expenditure.
• Consequences: The retailer wasted nearly £2M on low-value deliverables because no Project Board was verifying continued business justification at stage boundaries.

Scenario B: The Small Project Governance Paralysis (Bureaucracy Overkill)

A local community sports club undertakes a £15,000 project over four weeks to install floodlights on its tennis courts. The newly certified Project Manager insists on producing a 60-page Project Initiation Documentation (PID), separate 15-page strategy documents for Risk, Quality, Change, and Communication, a standalone Change Authority with a formal Change Budget, and bi-weekly 10-page Highlight Reports to the three-person sports club committee.

Practitioner Evaluation:

• Governance Failure: Complete failure to apply the principle of Tailor to Suit the Project Context.
• PRINCE2 Violation: For a simple, low-cost initiative, the PM should have collapsed Starting Up and Initiating into a single planning workshop, condensed the PID into a 4-page briefing slide deck, merged all registers into the Daily Log, and combined the PM and Team Manager roles.
• Consequences: The project was delayed by four weeks and incurred thousands of pounds in wasted administrative effort before any physical construction began.

Scenario C: The Commercial Supplier Misalignment

An aerospace manufacturing corporation engages a specialist software vendor to build an avionics flight simulation module. The customer Project Manager assumes that the vendor will share the customer's internal Business Case and agree to flexible verbal scope changes. Mid-way through delivery, the customer demands a 30% scope expansion without adjusting the delivery budget. The vendor halts all development, citing that the work falls outside the contractual Statement of Work and threatens their internal commercial profitability. The project collapses into legal litigation.

Practitioner Evaluation:

• Governance Failure: Failure to tailor PRINCE2 for a commercial customer/supplier environment.
• PRINCE2 Violation: The PM failed to understand that in commercial environments, the customer and supplier have separate Business Cases. Scope boundaries must be managed through formal contract variation procedures aligned with the Change Management Approach. Attempting to force uncompensated scope changes onto a commercial supplier violates commercial governance and the Manage by exception principle.

---

8. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Believing Tailoring Allows Dropping Principles: Any exam option suggesting that a project team can skip "Manage by stages" because they use Agile, or omit the "Business Case" because the project is small, is strictly wrong. The seven principles are non-negotiable.
• Trap 2: Combining Project Executive and Project Manager on Small Projects: While small projects allow extensive role consolidation (e.g., Project Executive absorbing Senior User, PM absorbing Team Manager), the Project Executive and Project Manager roles can NEVER be combined into one person.
• Trap 3: Equating a 2-Week Sprint to a Management Stage: A Sprint is a technical timebox for building specialist products; a Management Stage is an executive governance gate where the Project Board reviews viability and authorizes continued funding. Sprints occur inside stages.
• Trap 4: Believing a One-Stage Project is Permitted: In PRINCE2, every project must have at least two management stages: the Initiation Stage (to plan and establish foundations) and at least one Delivery Stage. A "one-stage project" violates the Manage by stages principle.
• Trap 5: Assuming Sustainability is Optional in Tailoring: Sustainability is an explicit, mandatory project performance target in PRINCE2 7. It cannot be omitted on the grounds of simplicity or convenience. Tailoring adapts how sustainability is controlled (e.g., lightweight checklists vs. formal life-cycle carbon models), but the target itself must be managed.