2.4 Focus on Products & Tailoring to Suit the Project Context
Key Takeaways
- Principle 6 (Focus on Products) enforces an output-oriented delivery approach, requiring unambiguous Product Descriptions with explicit quality specifications and tolerances agreed before production begins.
- Management products support project governance, planning, and control (e.g., Business Case, PID, Work Packages), whereas specialist products represent the operational deliverables created for user benefit.
- Principle 7 (Tailor to Suit the Project Context) dictates that PRINCE2 practices, processes, products, and roles must be adapted to match project scale, complexity, commercial environment, and delivery method (e.g., Agile).
- The seven PRINCE2 principles are universal, non-negotiable, and absolute: while processes, practices, and documents can be adapted, the seven principles can never be tailored out.
2.4 Focus on Products & Tailoring to Suit the Project Context
Practitioner Core Mandate: Projects frequently fail not because team members lack skill, but because they pour immense effort into poorly defined activities without a shared understanding of what constitutes an acceptable deliverable. PRINCE2 counters this via Focus on Products, anchoring all planning and delivery to tangible, quality-checked deliverables. Simultaneously, PRINCE2 is never a bureaucratic straightjacket: Tailor to Suit the Project Context demands that the method is adapted to project scale, complexity, and delivery methods, while preserving the non-negotiable governance principles.
Principle 6: Focus on Products
The principle of Focus on Products mandates an output-oriented approach to project management. Traditional project planning often falls into the "activity trap"—teams generate vast Gantt charts listing hundreds of tasks ("write code," "conduct interviews," "pour concrete") without first agreeing on the precise technical requirements, quality standards, and acceptance criteria of the products those activities must yield.
Why the Activity Trap Fails
When projects focus on activities rather than products, several critical failures consistently emerge:
- The "90% Complete" Syndrome: A software team reports being 90% finished because 90% of estimated programming hours have elapsed, yet the module fails basic security integration and cannot be deployed.
- Unclear Scope Boundaries: Without detailed product specifications, stakeholders continuously argue over whether specific features were included in the scope.
- Subjective Quality Acceptance: At project handover, users reject deliverables because their unspoken operational expectations were never captured in writing.
Traditional Activity-Based Planning (Vulnerable):
[List Activities] ──► [Assign Hours] ──► [Execute Work] ──► [Dispute Deliverable Quality]
PRINCE2 Product-Based Planning (Robust):
[Define Products & Quality Specifications] ──► [Map Dependencies] ──► [Derive Activities & Estimates]
Specialist Products vs. Management Products
PRINCE2 explicitly categorizes all project deliverables into two distinct groups:
| Deliverable Category | Definition & Core Purpose | Typical Examples |
|---|---|---|
| Specialist Products | The unique deliverables, tangible assets, or technical outputs created to realize business benefits for the customer and operational users. | A clinical mobile app, a physical hospital wing, a wind turbine, an e-commerce checkout workflow, an employee training syllabus. |
| Management Products | The governance, planning, administrative, and reporting instruments created by the project management team to direct, manage, and control the project. | Business Case, Project Brief, Project Initiation Documentation (PID), Stage Plan, Highlight Report, Work Package, Exception Report, End Stage Report. |
Anatomy of a Product Description
Under Principle 6, no specialist product should be produced without an approved Product Description. Created during product-based planning, a Product Description establishes a binding agreement between the user, supplier, and management:
- Identifier & Title: Unique reference name and numbering.
- Purpose: Why the product is required and what operational objective it fulfills.
- Composition: The internal components, sub-assemblies, or structural elements that make up the product.
- Derivation: Source data, preceding deliverables, or external assets required to build the product.
- Format & Presentation: Physical appearance, technical architecture, or file formats.
- Quality Specifications: The measurable technical specifications, performance metrics, and compliance standards the product must satisfy.
- Quality Tolerances: Allowable variations within measurable quality parameters.
- Quality Method: The testing, inspection, review, or audit procedures used to verify compliance.
- Quality Skills: The specialist skills or independent certifications required to execute the quality check.
- Quality Responsibilities: Explicit identification of the Producer (author/builder), Reviewer(s), and Approver (the person authorized to sign off acceptance).
Principle 7: Tailor to Suit the Project Context
Principle 7 establishes that PRINCE2 is not a one-size-fits-all methodology. The value of PRINCE2 lies in its adaptability: the method must be tailored to match the project's scale, complexity, importance, team capability, commercial environment, and risk profile.
Tailoring ensures that project governance is proportionate:
- A $50,000 internal workflow upgrade must not be burdened with the same administrative volume as a $250,000,000 aerospace defense contract.
- An agile software development project requires different communication cadence and product documentation formats than a heavy civil engineering initiative.
Tailoring Dimensions and Environmental Contexts
┌───────────────────────────────┐
│ PROJECT CONTEXT │
└──────────────┬────────────────┘
┌────────────────────────┼────────────────────────┐
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ SCALE & RISK │ │ DELIVERY METHOD │ │ COMMERCIAL ENV. │
├─────────────────┤ ├─────────────────┤ ├─────────────────┤
│ • Budget size │ │ • Agile/Scrum │ │ • Fixed-price │
│ • Team size │ │ • Waterfall/Seq.│ │ • Time & mat. │
│ • Business risk │ │ • Hybrid │ │ • Multi-vendor │
└─────────────────┘ └─────────────────┘ └─────────────────┘
When tailoring PRINCE2, the Project Manager and Project Board adapt five core elements:
- Processes: Combining or simplifying activities (e.g., combining Starting Up a Project and Initiating a Project for a minor internal initiative).
- Practices (Themes): Adjusting how risk, quality, issues, and plans are managed (e.g., utilizing automated continuous integration testing for Quality, or digital Kanban boards for Progress tracking).
- Management Products: Consolidating documentation (e.g., merging the Project Brief, Risk Register, and Quality Register into a single lightweight PID document; replacing lengthy written Highlight Reports with verbal standup summaries or digital dashboard snapshots).
- Roles and Responsibilities: Combining roles where appropriate (e.g., the Project Manager also acting as Team Manager and Project Support).
- Terminology: Aligning PRINCE2 terms with corporate or industry standards (e.g., calling the Project Board the "Steering Committee" or Product Descriptions "User Stories").
What Can Be Tailored vs. What is Non-Negotiable
A critical distinction on the Practitioner exam is understanding the hard boundary of tailoring. Tailoring does not mean omitting governance or abandoning control.
| Project Aspect | Can It Be Tailored? | Permissible Tailoring Approach | Forbidden Practice |
|---|---|---|---|
| The 7 Principles | NEVER | Non-negotiable and absolute. Must be demonstrably applied in every PRINCE2 project. | Eliminating stages, abandoning business justification, or ignoring tolerances. |
| The 7 Practices | YES | Right-sized techniques, tools, and depth of analysis appropriate to project risk. | Skipping risk management or quality verification entirely. |
| The 7 Processes | YES | Combining activities, merging steps, or tailoring process triggers. | Bypassing project authorization or stage-end decision gates. |
| Management Products | YES | Merging products, adopting digital formats, utilizing oral briefings or wall displays. | Omitting product quality specifications or abandoning baseline plans. |
| Roles & Structures | YES | Combining roles (e.g., Exec + Senior User; PM + Team Manager). | Permitting the PM to act as Project Assurance or Board Project Executive. |
The Universal Rule: If any of the seven principles is compromised, eliminated, or breached, the project is not being managed with PRINCE2. A project that claims to use PRINCE2 but operates without continued business justification or without defined tolerances is merely using "PRINCE2 in name only" (PINO).
PRINCE2 7 in Agile and Modern Delivery Environments
A major focus of PRINCE2 7 is seamless integration with modern, iterative delivery approaches (such as Scrum, Kanban, Lean, and DevOps).
Rather than competing with Agile, PRINCE2 provides the overarching governance, business justification, and project direction, while Agile provides the iterative product delivery engine:
PRINCE2 Governance Layer (Project Board & PM):
[Business Justification] ──► [Manage by Stages] ──► [Manage by Exception / Tolerances]
│
▼ Delegated via Work Packages
Agile Specialist Delivery Layer (Team Managers & Delivery Teams):
[Sprint Planning] ──► [Daily Standups] ──► [Iterative Sprints] ──► [Continuous Delivery]
How PRINCE2 and Agile Harmonize:
- Work Packages as Sprints / Timeboxes: A Work Package issued by the Project Manager can define the objectives, tolerances, and quality specifications for a two-week sprint or a release cycle.
- Product Descriptions as Epics and User Stories: High-level Product Descriptions define the overall deliverable, while detailed Acceptance Criteria within user stories establish the specific quality specifications and tolerances.
- Progress via Burndown Charts and Kanban: Instead of demanding extensive written progress reports from technical teams, the Project Manager monitors sprint burndown charts, cumulative flow diagrams, and attends sprint reviews to compile the Highlight Report.
- Tolerances on Scope and Quality: In agile delivery, cost and time are typically fixed per sprint, while scope is made flexible. PRINCE2 tolerances accommodate this by establishing scope tolerances (e.g., minimum viable product vs. optional user stories).
PRINCE2 7 Practitioner Scenario Analysis
Scenario A: Fast-Tracking Without Product Descriptions
Under extreme commercial pressure to launch a fintech payments engine, a software startup decides to bypass writing Product Descriptions. The lead developer argues that agile development values "working software over comprehensive documentation," and that detailed quality specifications slow down velocity. During integration with payment clearinghouses, the software is rejected because data encryption algorithms failed to meet international banking regulatory standards, requiring an eight-week complete rewrite.
Practitioner Evaluation:
- The project team misunderstood both Agile and PRINCE2 Principle 6 (Focus on Products). Agile development emphasizes working software, but working software cannot be delivered without clear acceptance criteria.
- Omitting Product Descriptions eliminated the formal agreement on technical encryption standards and quality verification methods.
- Mandatory Action: The team should have tailored the Product Description into agile-compatible user stories with explicit "Definitions of Done" and compliance acceptance criteria, ensuring developers knew the regulatory encryption constraints before coding.
Scenario B: "De-Princing" Under the Guise of Tailoring
A corporate IT department adopts what it calls "Lean PRINCE2" for internal digital projects. Under this tailored standard, projects operate without a Business Case (to eliminate paperwork), stages are removed so developers can deploy features continuously, and project tolerances are abolished because "agile teams are self-organizing." The department insists this represents modern tailoring under Principle 7.
Practitioner Evaluation:
- This configuration is an extreme exam trap. The department has not tailored PRINCE2—it has dismantled it into "PRINCE2 in name only" (PINO).
- Tailoring applies to processes, practices, products, and roles. The seven principles are universal and non-negotiable.
- Eliminating the Business Case violates Principle 1 (Continued Business Justification); removing stages violates Principle 4 (Manage by Stages); abolishing tolerances violates Principle 5 (Manage by Exception).
- Mandatory Assessment: The standard is non-compliant and cannot be recognized as a PRINCE2 project.
Practitioner Exam Traps & Governance Verification
- Trap 1: Confusing Tailoring with Exemption: Candidates often choose answers that excuse small or agile projects from applying PRINCE2 principles. No project is exempt from the seven principles; tailoring alters how a principle is demonstrated, never whether it is applied.
- Trap 2: Activity Checklists Disguised as Product Descriptions: When reviewing Product Descriptions in practitioner scenarios, look for measurable quality specifications and clear quality methods. A document that simply lists tasks for an engineer to complete is an activity checklist, not a Product Description.
- Trap 3: Assuming Agile Incompatibility: Exam distractors frequently claim that PRINCE2 cannot support iterative software releases. In reality, PRINCE2 7 is explicitly designed to wrap robust governance around agile delivery mechanisms, using Work Packages and scope tolerances to empower iterative teams.
An agile development team is building an automated claims processing engine. The team lead insists that writing formal Product Descriptions contradicts agile values, and proposes relying entirely on verbal discussions during daily standups. During user acceptance testing, the claims processing department rejects the release because transaction throughput fails to meet mandatory audit benchmarks. Which PRINCE2 principle was violated, and what was the underlying cause?
A public utility is launching a 3-month, $60,000 internal training project. The newly appointed Project Manager establishes 8 management stages, authorises 24 separate written management documents, and mandates weekly formal written Highlight Reports to the Project Executive. The project quickly stalls under administrative overhead. How should this situation be evaluated under Principle 7 (Tailor to Suit the Project Context)?
A corporate PMO issues a revised project management standard for cloud adoption. The PMO states that to ensure maximum agility, project teams will no longer maintain a Business Case, stage boundary decision gates will be eliminated, and no project or stage tolerances will be established. The PMO markets this framework as 'Tailored Ultra-Agile PRINCE2'. What is the accurate PRINCE2 Practitioner assessment?