Projects, Programmes, Portfolios and Project Context in PRINCE2 2017

Executive summary

Why project context matters

A project can be well managed internally and still fail to serve the organisation if it is disconnected from the strategy, programme, portfolio or operational environment around it. The source therefore places the project inside a broader management context. That context determines where the project mandate comes from, who owns the business need, who will realise benefits, what standards apply, how funding is authorised and how the project should interface with suppliers or other projects.

Understanding context also prevents a common governance problem: assigning the project manager responsibility for decisions or benefits that belong outside the project. The project manager manages the authorised project. Higher management commissions and governs the change environment, while users and operations may continue benefit-realisation work after the project team has been disbanded.

Project, programme and portfolio

The distinction is useful because the same decision can look different at each level. A project may be performing within its tolerances, yet the programme may decide that another initiative now has higher strategic priority. Likewise, a portfolio may change investment allocation because risk, capacity or expected value has shifted across the organisation. The project-management method needs an interface through which those higher-level decisions can reach the project.

Customer, supplier and commissioning authority

The source states that every project has a customer side that specifies the desired results and one or more supplier interests that provide the skills and resources required to create them. In a simple internal project, these interests may exist inside one organisation. In a commercial project, they may sit across contractual boundaries and operate under different management systems, cultures, business cases and delivery approaches.

The commissioning authority may be corporate management, programme management or the customer. This level can issue the project mandate, set project tolerances, govern the project at the highest level and continue ownership of benefits-management activity after project closure. The project board and project manager therefore need a clear interface upward and outward rather than assuming that all authority resides inside the temporary project organisation.

The integrated environment

The supplied material presents four connected elements: seven principles, seven themes, seven processes and the project environment. The principles are the mandatory guiding obligations that characterise the method. The themes describe management aspects that need continual attention. The processes describe progression from pre-project work through initiation, delivery, stage boundaries and closure. The project environment determines how all of these are adopted and tailored.

The source makes an important point about conformance: a project that claims to use the method must apply all seven principles, meet the minimum requirements of the seven themes and satisfy the purpose and objectives of the seven processes. Tailoring is therefore not permission to remove the management logic. It is permission to adapt the formality, terminology, documentation and specific practices so they remain useful in the real environment.

Commercial and multi-party environments

In customer-supplier settings, there may be more than one business case, different governance structures and different delivery methods. The customer may be judging value and outcome while the supplier also needs a viable commercial case for performing the work. Contractual milestones may coexist with management stages. A supplier team may use a different specialist delivery method while still providing the information required by the project manager.

This makes interface design a practical project-management task. Work packages, product descriptions, acceptance criteria, quality methods, reporting frequencies and escalation routes need to be understandable across organisational boundaries. The method does not require every party to use identical internal processes; it requires the project to have a reliable interface through which authorised work is agreed, progress is reported, products are accepted and exceptions are escalated.

Governance and benefits across boundaries

Benefits often sit outside the temporary project boundary. The project creates products, but business change, operational adoption and performance measurement may continue after closure. This is why the source places benefits ownership and post-project benefit reviews in the wider corporate or programme context. The temporary project team cannot remain accountable indefinitely after it has been disbanded.

The same boundary logic applies to governance. Project-level decisions should remain with the project board when they fall inside delegated project tolerances. If the project is forecast to exceed project-level tolerance, the matter moves to the commissioning authority. This escalation path preserves both autonomy and accountability: the project is not micromanaged, but higher management still retains control over commitments beyond the authority it delegated.

Context assessment before tailoring

Before deciding how formal the project should be, assess the environment that the source identifies as relevant: size and complexity, organisational standards, commercial arrangements, team structure, project risk, delivery approach and existing programme or portfolio controls. Tailoring should make management easier and more effective, not merely produce fewer documents.

• Identify whether the project sits inside a programme or portfolio and what reporting or governance it inherits.
• Identify the commissioning authority and the point at which project-level tolerance is exceeded.
• Separate customer/user interests from supplier interests even when the same organisation contains both.
• Map external suppliers and determine whether work packages, contracts or both will control the interface.
• Identify who will own benefit reviews after project closure.
• List organisational policies, controls, terminology and delivery methods that the project must integrate with.
• Tailor documents and roles to the context without removing the underlying principles, theme requirements or process purposes.

Choosing the right management context

Before applying project controls, determine the environment in which the project sits. If it is one component of a programme, identify which outcomes, dependencies, standards and benefit decisions are managed above the project. If it is part of a portfolio, identify the strategic investment constraints and prioritisation decisions that may affect it. If it operates as a stand-alone commercial project, clarify the customer–supplier governance and where contractual authority intersects with project authority.

This contextual mapping prevents duplication and gaps. A programme may already maintain a benefit framework or shared risk process that the project can adopt. Conversely, a project may still need a specific Stage Plan and Work Package controls even when a programme supplies the overall roadmap. The source’s tailoring logic supports reuse of existing governance while preserving the required project-management purposes.

Record the important external interfaces in the project definition and management approaches. Include commissioning authority, supplier relationships, operational owners, shared resources, external approvals and related projects. Revisit the map when organisational relationships change. Context is not background information: it determines where decisions are made, what can be delegated and which dependencies can threaten the project’s products or justification.

Practical verification checklist

• Record the project’s relationship to any programme, portfolio or wider change initiative.
• Confirm who issues or owns the project mandate and who sets project-level tolerances.
• Identify the customer/user and supplier interests represented in governance.
• Define the interface between the project and any external supplier management system or contract.
• Confirm who will own benefits management after the project closes.
• Identify programme, portfolio or corporate standards the project must inherit or tailor.
• Check that tailoring still applies all principles, meets theme minimum requirements and satisfies process purposes.
• Ensure escalation paths reach the correct higher management level when project tolerance is forecast to be exceeded.

Common mistakes to avoid

• Treating the project as an isolated delivery team with no link to strategy, programme controls or operational benefit ownership.
• Assuming the project manager owns every decision simply because they manage day-to-day delivery.
• Forcing external suppliers to adopt identical internal procedures instead of defining a clear project-supplier interface.
• Confusing programme or portfolio governance with project-stage control.
• Using tailoring as a reason to remove core management controls rather than adapting them to the environment.

Related KEVOS handbook pages