How PRINCE2 Manages Scope Creep
PRINCE2 scope creep is managed by defining agreed project products, assessing proposed changes through the Issues Practice, setting decision-making authority, and using tolerances to identify when escalation is needed. PRINCE2 does not prohibit changes. Instead, it helps project teams distinguish authorised improvements from uncontrolled additions that increase workloads, costs, delays, and complexity.
How Does PRINCE2 Manage Scope Creep?
PRINCE2 manages scope creep by establishing what the project is expected to deliver, controlling changes to agreed products, and making sure decisions are taken by someone with the appropriate authority.
The method brings several controls together:
- Focus on Products: Clarifies what needs to be delivered and the quality expectations.
- Plans Practice: Establishes how the agreed products will be delivered.
- Issues Practice: Provides a structured approach to assessing and responding to proposed changes.
- Management by Exception: Uses tolerances to determine when decisions must be escalated.
- Business Case Practice: Helps ensure changes remain justified by the expected value of the project.
These controls work together rather than functioning as a separate scope-management procedure.
Explore how the seven PRINCE2 Practices support project control.
What Is Scope Creep?
Scope creep is the uncontrolled expansion of what a project is expected to deliver. It happens when additional requirements, products, or work become part of the project without being properly assessed and authorised.
It can appear in seemingly harmless ways. A client might ask for one additional report. A development team might introduce functionality that was never requested. A stakeholder might gradually expand acceptance expectations without considering the impact on time or cost.
Individually, these additions may seem minor. Together, they can consume resources, introduce risks, and make the original project commitments increasingly difficult to meet.
PRINCE2 recognises uncontrolled change as scope creep and emphasises agreement on what products the project will deliver.
What Is the Difference Between Scope Creep and an Approved Scope Change?
Scope creep is uncontrolled expansion, whereas an approved scope change has been assessed and authorised through the project’s agreed controls.
The difference is not necessarily the size of the change. A relatively small addition can represent scope creep if it bypasses the agreed decision-making arrangements. A substantial change, meanwhile, can be legitimate if the appropriate authority approves it and its consequences are managed.
| Consideration | Scope creep | Controlled change |
|---|---|---|
| Visibility | Additional work may be introduced informally | Proposal is recognised and considered |
| Assessment | Consequences may not be understood | Relevant impacts are assessed |
| Approval | Required approval is absent or unclear | Decision follows agreed authority |
| Products | Agreed product expectations may drift | Affected products are identified |
| Plans | Work can expand without corresponding updates | Relevant plans are updated when needed |
| Business Case | Justification may be weakened without review | Continued justification is considered |
For example, adding a new customer analytics dashboard without approval may be scope creep. Approving that dashboard after assessing its value, impacts, and funding represents controlled change.
Does PRINCE2 Try to Prevent Scope Changes?
No. PRINCE2 aims to control changes, not eliminate them.
Projects operate in changing environments. Customer expectations, legislation, technologies, and business priorities can change while work is underway.
Sometimes changing scope is the most sensible decision. A new requirement might improve the expected benefits, address an emerging business need, or help preserve the project’s justification.
The important question is not simply whether something has changed. It is whether the proposed change is understood, justified, authorised, and managed.
A useful scope change is not automatically scope creep.
How Does PRINCE2 Define and Control Project Scope?
PRINCE2 defines scope through agreement on what the project will deliver. The project’s defined products, quality expectations, plans, and approved management information provide the reference points used to control that scope.
The Project Initiation Documentation also includes a project definition covering scope inclusions and exclusions, alongside objectives, assumptions, and constraints.
PRINCE2 therefore does not rely on a single standalone scope statement as its only method of scope control.
How Does the Focus on Products Principle Help?
The PRINCE2 Focus on Products principle emphasises defining the required products before concentrating on the activities needed to produce them.
This helps because products provide a clearer way of recognising whether a request is already part of the project.
Imagine a project to introduce an employee self-service portal. The agreed product includes the ability to update personal details, view payslips, and request annual leave.
If somebody later asks for an employee expense-claiming feature, the team can compare that request with the agreed products rather than simply adding it to the development schedule.
The feature might be valuable, but its value does not automatically make it part of the agreed scope.
Read more about the PRINCE2 principles.
How Do Product Descriptions and the Project Product Description Help?
Product Descriptions explain the products to be created and the quality expectations against which they will be assessed.
They help project teams understand what constitutes an acceptable product, reducing disagreements about whether additional work is required.
A Product Description can establish information such as the product’s purpose, composition, quality criteria, and quality arrangements. The precise information and level of detail are tailored to the project.
The Project Product Description takes the broader view by defining the project’s overall output and its acceptance expectations.
For a customer service portal, the overall project product might be a functioning self-service portal ready for operational use. Individual Product Descriptions could address components such as account management or customer support functionality.
This creates a useful distinction between the agreed overall outcome and the individual products required to achieve it.
Find out more about PRINCE2 management products.
How Does Product-Based Planning Help Control Scope?
Product-based planning helps control scope by identifying the products that must be delivered before developing the detailed activities, resources, and schedules.
PRINCE2’s planning technique establishes the required products and their relationships, making it easier to understand how changing one product may affect others.
For example, adding a reporting module to a portal may also require changes to data integration, permissions, and testing.
Product-based planning makes these dependencies more visible, helping teams avoid treating extra functionality as an isolated task.
Our guide to creating a project plan using PRINCE2 explains the planning approach in more detail.
Why Are Baselines Important?
In PRINCE2, the project baseline consists of the current approved versions of the management products and project products subject to change control. These baselines provide agreed reference points against which proposed changes can be assessed.
Without an agreed version of a product or plan, project teams may struggle to establish whether requirements have changed and who authorised those changes.
PRINCE2 uses controls for product versions and changes so that decisions can be traced and the project’s current approved position remains clear.
Not every working document needs elaborate version-control arrangements. The level of control should be appropriate to the project and the importance of its products.
How Does the PRINCE2 Issues Practice Manage Scope Changes?
The PRINCE2 Issues Practice provides a structured way of recognising, assessing, deciding on, and managing issues that could affect the project’s objectives, products, or plans.
PRINCE2 7 recommends a five-step issue management technique:
- Capturing issues: Recognise the issue, determine its type and priority, and record it appropriately.
- Assessing issues: Consider how the issue affects the project, including its Business Case, plans, risks, and relevant tolerances.
- Recommending changes: Identify possible responses, evaluate the consequences, and recommend an option to the appropriate authority.
- Deciding on changes: The authorised decision-maker determines how the issue will be addressed, including whether escalation or further information is necessary.
- Implementing changes: Carry out authorised actions and update the relevant records and approved management information.
The manual permits an appropriately tailored alternative procedure, provided the project’s arrangements are established.
Importantly, not every issue requires a detailed change proposal. Smaller operational matters can be handled more simply, while proposals to change a baseline require the appropriate change-control arrangements.
What Is a Request for Change?
In PRINCE2, a request for change is a proposal to change an approved baseline.
For example, suppose a client asks for an analytics dashboard that was not included in the agreed customer portal.
The request should identify what approved information would need to change and why the change is justified. If there is an additional cost, its proposed funding source must also be identified.
Submitting a request does not mean it has been approved.
The request needs to be assessed and decided on through the project’s agreed controls.
What Is an Off-Specification?
An off-specification occurs when a product will not meet its agreed quality specifications.
Suppose the agreed portal must support a particular accessibility requirement, but testing identifies that the delivered product will not meet it.
That represents an off-specification rather than an example of additional functionality being informally introduced.
If the appropriate authority accepts the off-specification without corrective action, it becomes a concession, and the affected baseline must be updated.
What Other Types of Issues Can Arise?
PRINCE2 7 also identifies problems or concerns, events external to the project, and business opportunities.
A supplier outage might be an immediate problem. A new regulation could represent an external event. A newly available technology could create a business opportunity.
These issues do not automatically constitute scope creep, but they may lead to proposed changes.
It’s also important to distinguish an issue from a risk. A risk involves uncertainty about what may happen, whereas an issue concerns something that needs attention now.
Who Can Approve Scope Changes in PRINCE2?
Scope changes must be decided on by someone with the authority to make that decision under the project’s agreed governance arrangements.
The Project Board retains responsibility for establishing appropriate change-control authority but can delegate certain decisions.
This prevents every minor change from requiring a senior management decision.
What Is Change Authority?
In PRINCE2, the Project Board is the ultimate authority for approving requests for change and off-specifications. However, it can delegate certain change decisions to appropriate individuals or roles within agreed limits.
Depending on the project’s scale, complexity, and expected volume of changes, the Project Board may establish a separate Change Authority or delegate decisions within the project management team. These arrangements are defined in the issue management approach and should align with the project’s tolerances.
The aim is to make decisions at the appropriate level without unnecessary escalation.
Can the Project Manager Approve Scope Changes?
Yes, where the Project Manager has the necessary delegated authority and the decision remains within the agreed controls.
However, managing a stage within tolerance and having authority to approve a particular baseline change are related but not identical considerations.
The Project Manager should check the issue management approach, relevant responsibilities, and any limits on delegated change approval.
A senior stakeholder’s request does not automatically override these arrangements.
For more information, explore PRINCE2 roles and responsibilities.
What Is Scope Tolerance in PRINCE2?
Scope tolerance is the permissible variation in the products specified by a plan before a deviation must be escalated to the next management level.
It forms part of PRINCE2’s Manage by Exception principle.
For example, a project could distinguish between mandatory functionality and lower-priority functionality that may be adjusted within agreed boundaries.
Let’s say a portal project must deliver three mandatory service modules but may vary the number of optional enhancements within a specifically agreed range. The actual permitted variation and decision-making rights must be established for that project.
Scope tolerance is only one of seven tolerance types. PRINCE2 also manages benefits, cost, time, quality, sustainability, and risk.
Does Scope Tolerance Mean Extra Features Are Automatically Allowed?
No. Scope tolerance does not provide unlimited permission to add or remove features.
Tolerance establishes boundaries for delegated management. Proposed changes must still comply with the relevant authority, issue management arrangements, and other project controls.
A change can remain within a numerical tolerance and still require formal approval if it changes an agreed baseline.
Read more about PRINCE2 tolerances.
How Does Management by Exception Control Scope Creep?
Management by Exception establishes clear performance boundaries and allows authorised managers to make decisions within their delegated responsibilities.
The next management level becomes involved when a tolerance is forecast to be exceeded.
For example, if a proposed scope change would cause the current stage to exceed its time or cost tolerance, the Project Manager must escalate the forecast exception instead of simply accepting the additional work.
The important word is forecast. Escalation should not be postponed until a tolerance has already been exceeded.
This is how PRINCE2 balances flexibility with governance.
Read our explanation of Management by Exception in PRINCE2.
What Should Be Assessed Before Approving a Scope Change?
A proposed scope change should be assessed in relation to the project’s approved performance targets and tolerances, its Business Case, and any other affected products or work packages.
A useful assessment considers the seven PRINCE2 performance areas:
| Area | Questions to consider |
|---|---|
| Benefits | Will the change create or reduce expected value? |
| Cost | What additional expenditure or savings could result? |
| Time | Will delivery dates or dependencies change? |
| Quality | Will quality criteria or acceptance expectations change? |
| Scope | Which products or requirements would be added, removed, or altered? |
| Sustainability | Could sustainability targets or impacts change? |
| Risk | Does the proposal introduce or alter threats and opportunities? |
Consider a request for just one additional report in a software project.
Producing the report may involve new data integrations, access permissions, testing, documentation, and user training.
What initially sounds like a minor addition can therefore affect multiple performance targets.
How Can Scope Changes Affect the Business Case?
Scope changes can strengthen or weaken a project’s Business Case.
Additional functionality might create benefits that justify the additional investment. Alternatively, the extra expenditure, delays, uncertainty, or operating implications may outweigh the expected value.
PRINCE2 emphasises continued business justification, meaning the project must remain worthwhile as circumstances change.
A scope change should therefore be assessed against the project’s justification rather than judged solely on whether the additional functionality would be useful.
How Can Scope Changes Introduce Risk?
Additional scope can create new uncertainties.
A new feature might introduce supplier dependencies, require unfamiliar technology, consume scarce specialist resources, or affect delivery confidence.
These uncertainties should be considered through the Risk Practice alongside the proposed change.
The distinction matters: the change request is an issue requiring a decision, while uncertain future events arising from it may need to be managed as risks.
Explore PRINCE2 Risk Management.
What Happens After a Scope Change Is Approved?
An authorised change must be reflected in the information used to manage the project.
Depending on the change, this might involve updating the relevant Product Descriptions, plans, Work Package Descriptions, Business Case, or other affected management products.
The decision and implementation should also be recorded appropriately, with controlled versions retained where required.
Approval alone does not make a change properly managed. The people delivering the work must understand what has been authorised and what the revised expectations are.
Can a Scope Change Require an Exception Plan?
Yes, but not every scope change requires an Exception Plan.
If a proposed change causes an existing plan to be forecast outside its agreed tolerance, PRINCE2’s exception arrangements apply.
An Exception Report provides information about the forecast exception, and the appropriate authority decides how the situation should be addressed.
One possible response is to request an Exception Plan.
A change approved within the relevant authority and tolerances may not require this additional step.
PRINCE2 Scope Creep Example: Can We Add Live Chat?
Imagine a fictional project to develop a customer self-service portal.
The approved portal includes three capabilities:
- Customers can view their account information.
- Customers can update their contact details.
- Customers can submit support requests.
During development, a stakeholder makes a suggestion:
“Could we just add live chat as well?”
The suggestion sounds reasonable. Live chat could improve the customer experience, but it introduces new considerations.
Step 1: Capture the request
The Project Manager establishes whether live chat is already covered by the agreed products. If it is genuinely additional functionality affecting the baseline, it is handled as a request for change.
Step 2: Assess the impact
The team examines the consequences. Live chat could require additional software integration, staffing arrangements, security considerations, testing, training, and funding.
Step 3: Recommend a response
The Project Manager considers possible responses and their implications. These could include introducing live chat within the current project, proposing changes to other requirements, or recommending that the request should not proceed.
Step 4: Obtain an authorised decision
The proposal goes to the appropriate person or group under the issue management approach.
If it can be authorised within the agreed delegation, the project does not need to escalate it unnecessarily. If it threatens agreed tolerances or exceeds delegated authority, escalation is required.
Step 5: Implement the authorised decision
If approved, the team updates the relevant management information and delivers the change under the revised controls.
Two possible outcomes
Outcome A: Change authorised within delegated authority
The change is justified, the appropriate authority approves it, and affected plans and product information are updated.
Outcome B: Escalation required
The proposed change would exceed a relevant tolerance or delegated decision limit. It is referred to the appropriate higher authority before implementation.
Neither outcome means the stakeholder was wrong to ask. The important point is that the extra feature must not become part of the project just because somebody requested it.
How Should Stakeholder Requests Be Managed?
Stakeholder requests should be considered constructively rather than dismissed as unwanted interference.
Stakeholders may identify genuine gaps in requirements, emerging needs, or improvements that increase the value of the project’s products.
The Project Manager should ensure that requests are understood, assessed, and directed through the agreed controls where necessary.
Involving the relevant business, user, and supplier interests helps the project understand the consequences of a proposal.
However, influence or seniority alone does not establish change approval authority.
How Does PRINCE2 Manage Scope in Agile or Hybrid Projects?
PRINCE2 can manage scope in linear, iterative, and hybrid delivery environments.
Agile delivery does not mean unlimited scope. It often allows detailed requirements to evolve while working towards an agreed outcome within established boundaries.
For example, an iterative project may keep time and cost relatively fixed while allowing more flexibility in lower-priority functionality.
The manual explicitly recognises that iterative-incremental projects may use tighter time and cost tolerances and more flexible scope tolerances.
PRINCE2’s governance arrangements can also be tailored to work with delivery techniques such as sprints, user stories, and product backlogs.
The important distinction is between planned flexibility and uncontrolled changes that exceed agreed authority or project boundaries.
For further context, read PRINCE2 vs Agile or PRINCE2 vs Scrum.
How Should Scope Control Be Tailored?
Scope control should be proportionate to the complexity, importance, risk, delivery method, and requirements of the project.
A smaller, simpler project may need straightforward issue records, limited documentation, and clearly established decision-making responsibilities.
A more complex project might need stronger version control, detailed impact assessments, multiple delegated approval arrangements, and closer monitoring.
PRINCE2 allows the method’s application and documentation to be tailored. However, tailoring must preserve effective control and remain consistent with the PRINCE2 principles.
Explore how to tailor PRINCE2.
What Are the Warning Signs and Common Mistakes?
The following are practical warning signs of possible scope creep, rather than an official PRINCE2 checklist:
- Extra functionality is repeatedly accepted without considering approved products.
- Work is added without the necessary change decision.
- Product expectations expand informally.
- Acceptance expectations change without corresponding agreement.
- Teams deliver additional features because they believe the features would be useful.
- Changes are assessed for cost but not for risk, quality, benefits, or sustainability.
- Decisions are escalated too late, after tolerances have already been exceeded.
- Approved changes are not reflected in relevant plans and product information.
One common mistake is treating every proposed change as harmful.
Another is assuming that a small addition does not need proper consideration.
In practice, the goal should be to retain enough control to protect the project while allowing useful changes to be assessed efficiently.
PRINCE2 Scope Change Checklist
Before accepting an additional requirement or feature, consider the following questions.
PRINCE2 Scope Change Checklist
Before accepting an additional requirement or feature, work through these questions to understand its implications for your project.
Being within scope tolerance does not automatically mean a change is authorised. Proposed changes must be considered under the project’s agreed decision-making arrangements. If a tolerance is forecast to be exceeded, escalation may be required.
Frequently Asked Questions
Is Every Scope Change Bad?
No. An authorised change may improve the project’s value, address changing requirements, or protect continued business justification. The concern is uncontrolled change, not change itself.
Does Every Scope Change Go to the Project Board?
No. The Project Board can delegate change authority within agreed limits. Decisions requiring higher authority must be escalated appropriately.
Can the Project Manager Reject a Change?
A Project Manager can make change decisions within their delegated authority. Whether they can formally reject a particular baseline change depends on the project’s issue management arrangements and decision limits.
Is Scope Creep Always Caused by Stakeholders?
No. Project teams can also introduce uncontrolled scope by adding unnecessary functionality or expanding work beyond agreed products. This is sometimes called gold plating in wider Project Management terminology.
Can Scope Creep Occur in Agile Projects?
Yes. Agile teams can still experience uncontrolled additions. Evolving requirements are not automatically scope creep, provided changes remain within the agreed delivery approach, approval authority, and project controls.
Build Stronger Project-Control Skills with PRINCE2
Managing scope effectively requires more than saying yes or no to new requests. It involves understanding the agreed products, assessing the consequences of change, and making decisions within clearly defined authority.
PRINCE2 provides a structured approach to these responsibilities through its principles, practices, processes, people, and project context.
If you’d like to develop your knowledge of the method, our PRINCE2 Foundation and Practitioner training covers the principles and practical application of managing projects using PRINCE2.
Want to build stronger practical project-control skills with PRINCE2?
