9.3 Change Authority, Change Budget & Baseline Control

Change Authority, Change Budget & Baseline Control in PRINCE2 7

Practitioner Core Mandate: Project governance often faces a critical dilemma: maintain rigorous, centralized Project Board control over every modification and risk bureaucratic paralysis, or grant total freedom to delivery teams and suffer catastrophic scope creep. PRINCE2 7 resolves this tension through three integrated mechanisms: the Change Authority (delegated decision-making), the Change Budget (ring-fenced financial control), and baseline control recorded in the project log: product register (version integrity). Mastering how these mechanisms operate individually and interact under agile tailoring is essential for Practitioner success.

---

1. The Change Authority: Delegation & Governance Limits

In the PRINCE2 organizational hierarchy, the Project Board is ultimately accountable for the project, including the authorization of all changes to baselines and the granting of concessions.

Why Delegate Change Decisions?

In large, complex, or fast-paced projects, routing every minor change request to the Project Board creates serious operational friction:

• Decision Latency: Project Board members are senior executives; convening the board to review small technical alterations delays delivery teams.
• Governance Fatigue: Project Boards become overwhelmed by operational minutiae rather than focusing on strategic business justification.
• Cost of Governance: The administrative overhead of board-level reviews often exceeds the financial value of the requested change.

To prevent bottlenecks, the Project Board may establish a Change Authority—an individual, role, or group to whom the Board delegates the authority to approve Requests for Change (RFCs) and concessions within defined boundaries.

                          CHANGE AUTHORITY DELEGATION MODEL

   ┌─────────────────────────────────────────────────────────────────────────┐
   │                             PROJECT BOARD                               │
   │ • Ultimate accountability for project deliverables & Business Case      │
   │ • Retains authority for major RFCs, project tolerances, & concessions   │
   └────────────────────────────────────┬────────────────────────────────────┘
                                        │ Sets delegated limits & budget
                                        ▼
   ┌─────────────────────────────────────────────────────────────────────────┐
   │                            CHANGE AUTHORITY                             │
   │ • Evaluates and decides routine RFCs and minor concessions              │
   │ • Operates within strict financial, schedule, & sustainability limits   │
   │ • Manages allocated Change Budget                                       │
   └─────────────────────────────────────────────────────────────────────────┘

Structuring the Change Authority

Depending on project scale, risk profile, and commercial context, the Project Board can configure the Change Authority in several ways:

1. The Project Manager: For small, low-risk projects, the Board may designate the Project Manager as the Change Authority for changes under a modest threshold (e.g., under $2,500 and zero schedule impact).
2. A Dedicated Role or Group (Change Control Board - CCB): On major engineering or corporate programs, the Board establishes a CCB comprising key stakeholders—such as the Senior User, Senior Supplier representative, technical architects, and commercial managers.
3. Domain-Specific Authorities: On multi-disciplinary projects, authority may be divided into specialized streams—an IT Change Authority for software infrastructure and an Engineering Change Authority for physical civil works.

Defining the Boundaries and Limits of Authority

A Change Authority does not possess unchecked power. The Project Board must define explicit limits of authority in the Issue Management Approach during project initiation:

• Monetary Ceiling: A maximum financial cost per single change (e.g., maximum $10,000 per RFC) and a cumulative cap per management stage.
• Schedule Boundary: Zero allowable delay to stage completion milestones or external delivery dates.
• Scope & Quality Constraints: The Change Authority cannot alter key acceptance criteria defined in the Project Product Description.
• Sustainability Ceiling: The change cannot cause stage carbon emissions or waste metrics to exceed agreed sustainability tolerances.
• Mandatory Escalation Rule: If a proposed change exceeds any of these delegated boundaries—or causes a stage tolerance to be breached—the Change Authority cannot approve it. It must be escalated to the Project Board via an Issue Report and Exception Report.

---

2. The Change Budget: Purpose, Rules & Financial Discipline

Every project requires financial discipline. When stakeholders request enhancements, funding those changes from the general delivery budget quietly cannibalizes project funds, creating unexpected cost overruns.

What is a Change Budget?

A Change Budget is a dedicated, ring-fenced financial allocation agreed during project initiation (and baselined in the Project Initiation Documentation) specifically to fund approved Requests for Change and concessions.

Ownership and Management

• Ownership: The Change Budget belongs to the Project Board.
• Management: The Project Board may allocate all or a defined portion of the Change Budget to the Change Authority to finance delegated change approvals.
• Optional Status: A Change Budget is optional. PRINCE2 does not mandate a Change Budget; if the business environment is highly predictive and scope is rigidly fixed by contract, the Project Board may choose not to allocate one. In that case, any approved RFC requires an explicit budget injection or reallocation from the business layer.

The Three Project Financial Pots: Never Conflate Them!

A classic Practitioner exam trap tests whether candidates understand the fundamental differences between the Change Budget, the Risk Budget, and Project / Stage Tolerances (Contingency):

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE THREE DISTINCT PROJECT FINANCIAL POTS               │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. CHANGE BUDGET                                                            │
│ • Purpose: Pays for NEW, MODIFIED, or EXPANDED SCOPE (RFCs and concessions) │
│ • Trigger: A stakeholder proposes a desirable enhancement or requirement    │
│ • Custodian: Project Board (often delegated to Change Authority)            │
│ • Rule: CANNOT be used to fix bad estimates or cover realized risks         │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. RISK BUDGET                                                              │
│ • Purpose: Pays for PLANNED RESPONSES TO IDENTIFIED RISKS                   │
│ • Trigger: Implementing a proactive risk mitigation or opportunity exploit  │
│ • Custodian: Project Board (managed by Project Manager under Risk Strategy) │
│ • Rule: CANNOT be raided to buy extra features requested by users           │
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. STAGE / PROJECT TOLERANCES (CONTINGENCY)                                 │
│ • Purpose: Absorbs ESTIMATION UNCERTAINTY & OPERATIONAL FRICTION            │
│ • Trigger: Planned baseline activities cost slightly more or take longer    │
│ • Custodian: Project Manager (within agreed stage tolerance boundaries)     │
│ • Rule: CANNOT be used to fund out-of-scope functional enhancements         │
└─────────────────────────────────────────────────────────────────────────────┘

Comparative Financial Matrix

---

3. Baseline Control: How PRINCE2 7 Keeps Versions Trustworthy

Even the most rigorous change authority and change budget are useless if the project team loses track of which deliverables are being built, modified, or delivered. PRINCE2 7 handles this inside the issues practice rather than as a separate configuration management discipline, and the manual is explicit that a prerequisite to effective issue management and change control is a way of creating baselines of products that allow changes to be analysed and controlled.

The Version 7 definitions you must be able to quote

• Change: a modification to any of the approved products that constitute the project baseline.
• Project baseline: the current approved versions of the management products and project products that are subject to change control.
• The controlling rule: changes are not incorporated into the project baseline until they have been approved by the individual or role delegated with the appropriate authority, and a new version of the product is created each time a change is approved and implemented.

What the project management team must determine

Regardless of size, scale, and complexity, PRINCE2 7 requires the team to settle:

1. The appropriate level at which products need to be baselined. Baseline a whole platform and every trivial fix becomes a change request; baseline every file and the team drowns in administration.
2. Where products are held and how they are protected, so that only authorized versions can be issued.
3. Who may approve a change at each level, which is where the change authority and change budget from sections 1 and 2 above plug in.

Because the issue management approach is driven by the nature of the products (the 'what') and the planned delivery activities (the 'how'), PRINCE2 7 notes that it is usually prepared after the product descriptions and work package descriptions — a sequencing point that scenario questions like to invert.

┌─────────────────────────────────────────────────────────────────────────────┐
│                   BASELINE CONTROL IN PRINCE2 7                             │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. DECIDE THE BASELINE LEVEL                                                │
│ • Documented in the ISSUE MANAGEMENT APPROACH during initiating a project   │
│ • Driven by the product descriptions and work package descriptions          │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. IDENTIFY AND RECORD EACH PRODUCT                                         │
│ • PRODUCT REGISTER: product identifier, dates of product description        │
│   approval and product acceptance, status, current version, and a link to   │
│   the associated product description                                        │
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. PROTECT THE APPROVED VERSIONS                                            │
│ • Once approved, a product is subject to change control and can only be     │
│   altered through the issue management technique                            │
├─────────────────────────────────────────────────────────────────────────────┤
│ 4. VERSION ON APPROVAL                                                      │
│ • A NEW VERSION is created each time a change is approved and implemented   │
│ • The product register status and version number are updated                │
├─────────────────────────────────────────────────────────────────────────────┤
│ 5. TRACE THE DECISION                                                       │
│ • Change control enables everyone to identify when changes were made and    │
│   trace each one to a decision by the appropriate authority                 │
└─────────────────────────────────────────────────────────────────────────────┘

---

4. The Product Register: The Single Version-Status Record

PRINCE2 7 removed the 6th Edition's configuration item records and product status account from Appendix A altogether. Their job is now done by the product register, one of the six components of the project log (A13), alongside the daily log, issue register, lessons log, quality register, and risk register.

What the product register holds

Its stated purpose is simply "to make a list of all products required for a plan and the status of those products". That is deliberately lean. If an exam option describes a register carrying custodians, repositories, dependency trees, and cross-references to every issue report, it is describing a 6th Edition configuration item record, not a PRINCE2 7 product register.

Where the product register is used

• Controlling a stage: when receiving a completed work package (16.4.3), the project manager checks that the product's quality activities are recorded and updates the project log — product status and version move forward here.
• Managing a stage boundary: in evaluate the stage (18.4.5) the project manager reviews the project log to confirm that the stage's products reached the expected status, which is the evidence behind the end stage report.
• Closing a project: in confirm project acceptance (19.4.3) the acceptance dates in the product register show which products were accepted, and at which version, before ownership transfers.
• Any release or deployment: the version number in the register is what tells the team which approved version should actually ship.

[!EXAM WATCHPOINT: RETIRED PRODUCTS] Do not select an option that has the project manager "requesting a product status account" or "updating the configuration item record". Neither exists in PRINCE2 7. The correct Version 7 wording is that the project log: product register is updated, and the equivalent of a status snapshot is simply a read of that register.

What did not change

Version control discipline itself is unchanged in substance, and the underlying governance rules still apply:

• A product that has been approved is under change control; it cannot be altered informally.
• Approving a change and implementing it produces a new version, not an edit in place.
• Whoever holds the delegated authority for that class of change — project manager within tolerance, change authority within its delegated limits, or the project board — is the only person who can authorize the new version.
• Concessions are recorded too: accepting a product that does not meet its quality specifications still updates the product register with the version that was actually accepted.

---

5. Tailoring Issue & Change Management for Agile Environments

A critical objective in the PRINCE2 7 syllabus is understanding how to tailor change control in agile and hybrid delivery environments.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     PREDICTIVE VS. AGILE CHANGE PHILOSOPHY                  │
├─────────────────────────────────────────────────────────────────────────────┤
│ PREDICTIVE WATERFALL CONTEXT:                                               │
│ • Change is viewed as a variance from an approved, fixed baseline           │
│ • Strict, formal change control required to prevent scope expansion         │
│ • Detailed Product Descriptions and formal RFC workflows govern every edit  │
├─────────────────────────────────────────────────────────────────────────────┤
│ AGILE / HYBRID CONTEXT:                                                     │
│ • Change is actively welcomed to maximize user value and empirical learning │
│ • Time, financial budget, and quality standards are strictly FIXED          │
│ • Scope and fidelity are FLEXED dynamically within timeboxes (MoSCoW)       │
│ • Routine requirement changes are handled via BACKLOG REPRIORITIZATION      │
└─────────────────────────────────────────────────────────────────────────────┘

The Agile "Trading" Mechanism (Backlog Reprioritization)

In an agile delivery stage (e.g., Scrum or Kanban execution):

1. User Stories in a Prioritized Backlog: Requirements are captured as user stories in a dynamic backlog rather than exhaustive upfront Product Descriptions.
2. Trading Scope within Timeboxes: When a stakeholder requests a new feature or modification during a sprint or stage, the team does not generate a bureaucratic 10-page Issue Report. Instead, the Product Owner (acting as Senior User representative) evaluates the request against the product backlog.
3. Equal-Effort Swapping: If the new feature is deemed higher priority than planned work, it is traded into the backlog by deprioritizing and removing existing stories of equivalent effort (story points).
4. Protecting Fixed Baselines: Because new scope is traded against existing scope, the stage delivery deadline, financial budget, and quality standards remain completely protected. This requires zero formal Project Board escalation.

Where Formal Change Control Still Applies in Agile

Agile does not mean the absence of governance. Formal PRINCE2 change control is still strictly mandatory in agile projects when:

• Project Product Description is Altered: A proposed change impacts the overall project purpose, major acceptance criteria, or key business case benefits.
• Stage or Project Tolerances are Threatened: Velocity drops so severely that even flexing 'Could Have' and 'Should Have' requirements cannot protect the stage completion date or financial cap.
• Architectural or Statutory Boundaries are Breached: A change breaches fundamental security, safety, legal compliance, or corporate sustainability policies.

---

6. Practical Scenario Evaluations

Scenario A: Depleted Change Budget & The Risk Budget Raid

During Stage 3 of a hospital IT implementation, the Change Budget of $50,000 has been completely exhausted by approved user change requests. A clinical director submits a vital RFC costing $15,000 to integrate mobile barcode scanners for medication administration. The Project Manager notices that $30,000 remains unspent in the project Risk Budget because several anticipated data migration risks did not occur. The PM reallocates $15,000 from the Risk Budget to fund the barcode scanner RFC, arguing that both funds belong to the project contingency reserve.

Practitioner Evaluation:

• Governance Flaw: The Project Manager has committed a severe financial governance breach by conflating the Change Budget with the Risk Budget.
• Impact: The Risk Budget is legally and procedurally ring-fenced to finance specific planned risk responses to threats and opportunities. It is never a discretionary slush fund to purchase additional user functionality.
• Correct PRINCE2 Action: The PM must reject the unauthorized budget transfer. The PM must inform the clinical director and Project Board that the Change Budget is exhausted. The Project Board must formally convene to decide whether to: 1. Request an additional capital injection from the business layer; 2. Descope other planned deliverables of equal value; 3. Reject the RFC; or 4. Defer the barcode scanners to post-project operational maintenance.

Scenario B: Version Chaos on the Manufacturing Line

A precision engineering firm is fabricating 50 automated drone chassis under a fixed-price contract. During testing, an engineer modifies the carbon-fiber arm thickness by 2mm to reduce vibration, updating the local computer-aided design (CAD) drawing on their desktop. The engineer does not update the project log: product register or notify Project Support. Two weeks later, the assembly plant manufactures 40 additional chassis using the master CAD file stored on the central server, which still contained the old baseline. All 40 chassis crack during vibration testing, destroying $80,000 in materials.

Practitioner Evaluation:

• Governance Flaw: Total failure of baseline control and of the product register discipline that protects approved versions.
• Impact: Modifying a deliverable locally without raising an RFC, without updating the product register, and without controlling which version was issued created version divergence, resulting in catastrophic rework and financial waste.
• Correct PRINCE2 Action: Once a deliverable is baselined, it is placed under strict configuration lock. Modifying the CAD file requires an approved RFC. When approved, Project Support updates the project log: product register with the new version (e.g., from v1.0 to v2.0), archives the obsolete version, and formally releases the new CAD baseline to the assembly plant via a verified the product register.

Scenario C: Agile Feature Swapping vs. Acceptance Criteria Breach

On a retail banking mobile application project developed using 2-week sprints, a marketing manager asks the team during Sprint 4 to replace the standard graphical login banner with a personalized video greeting. The Product Owner determines the video greeting requires 12 story points. The team trades out two low-priority 'Could Have' notification settings worth 12 points, keeping the sprint within its fixed timebox and cost. However, in Sprint 6, the marketing manager demands that the two-factor authentication requirement be eliminated to speed up user registration. The Product Owner agrees and removes two-factor authentication from the sprint backlog.

Practitioner Evaluation:

• Evaluation of Sprint 4 Action: Compliant. Swapping equal-effort user stories within the agreed product backlog to flex scope while protecting fixed time and cost tolerances is the correct agile tailoring mechanism under PRINCE2 7.
• Evaluation of Sprint 6 Action: Severe Governance Breach. Two-factor authentication is a fundamental security requirement and acceptance criterion baselined in the Project Product Description. A Product Owner has zero authority to remove mandatory project-level acceptance criteria or compromise regulatory compliance. That change requires an RFC escalated to the Project Board.

---

7. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Treating the Change Budget as a General Slush Fund: The Change Budget exists solely to fund approved RFCs and concessions. It cannot be used to pay for cost overruns caused by poor estimation, unexpected inflation, or realized risks.
• Trap 2: Assuming the Project Manager is Automatically the Change Authority: The Project Board is the default change authority. The Project Manager only has change authority powers if the Project Board explicitly delegates them in writing within the Issue Management Approach.
• Trap 3: Believing Delegation Relieves the Project Board of Accountability: Even when a Change Authority or Change Control Board is appointed, ultimate accountability for project success, deliverable integrity, and business justification remains strictly with the Project Board.
• Trap 4: Reaching for retired 6th Edition records: the configuration item record and the product status account no longer exist in PRINCE2 7. A single product (its passport). A the product register is a summary status report covering many (or all) configuration items at a specific moment in time.
• Trap 5: Believing Agile Projects Have No Formal Change Control: Agile delivery teams can dynamically trade scope within their agreed Work Packages and sprint backlogs. However, any change that impacts the Project Product Description, stage tolerances, or business case objectives requires formal PRINCE2 change authorization.