9.3 Change Control, Configuration & Priority/Effort Assessment

Issues Handling vs Change Control

It is worth re-stating the boundary: issues handling is the broad practice of capturing, assessing, and acting on anything that could affect the project. Change control is the subset of that practice that deals specifically with requests for change and off-specifications — the two categories that impact an agreed baseline. Problems/concerns, external events, and business opportunities may be handled with lighter touch; change control is invoked the moment a baseline is in play.

This is why v7 renamed the practice "Issues" rather than "Change": the project needs the wider lens, but change control remains the rigorous core for baseline-impacting items.

Tracking Product Status in v7

Change control still depends on knowing which version of which product is currently approved — you cannot sensibly approve a change to a product if you do not know what is in use and what depends on it. But be careful here, because this is one of the most common places where v6 revision notes mislead v7 candidates: PRINCE2 7 withdrew the configuration-management products. The Configuration Item Record and the Product Status Account are no longer specified, and the v6 Change Control Approach was replaced by the Issue Management Approach.

What v7 uses instead:

• Product Register — a record inside the Project Log that lists every product required by a plan and tracks its status from definition, through development, to acceptance. This is the v7 replacement for both the configuration item record and the product status account.
• Product Descriptions — define what each product is, its purpose, composition, quality criteria, and tolerances; these are the reference point against which off-specifications are judged.
• Issue Register — also a record inside the Project Log; provides the audit trail from concern, to decision, to altered baseline.
• Issue Management Approach — the baseline management product that defines how issues are captured, assessed, and decided, and how changes to baselines are controlled. It also documents the use and composition of any Change Authority.

Day-to-day maintenance of these records is typically provided by Project Support.

Exam trap: an option naming a Configuration Item Record, a Product Status Account, or a Change Control Approach is quoting PRINCE2 6. In a v7 scenario the correct artefact is the Product Register (status), the Issue Register (audit trail), or the Issue Management Approach (the rules).

Priority and Effort Assessment

Before a change is decided, it should be assessed for both priority and effort.

Priority reflects the change's impact across the usual dimensions:

• Impact on benefits
• Impact on scope
• Impact on risk
• Impact on quality
• Impact on time
• Impact on cost

A change that materially improves benefits at modest cost and risk is high priority; a change that marginally improves benefits but significantly increases cost or risk is low priority and may be rejected.

Effort is the work required to implement the change — analysis, design, build, test, and any rework of dependent products. A high-priority change that needs only modest effort is an easy "yes"; a high-priority change that demands enormous effort may need staging or deferral.

Priority and effort together give the decision authority a rational basis for approving, rejecting, or deferring. They are inputs to the recommend step of the 5-step technique.

Change Authority and Decision Limits

The Project Board is the default authority for changes that affect the project baseline or breach tolerance. Because the board may not want to decide on every small change, it can delegate a defined level of authority to a Change Authority — a person or group empowered to approve changes within agreed limits.

A change budget is an amount set aside to fund agreed changes. Its existence is one of the common reasons to appoint a Change Authority: the authority approves changes that draw on the change budget up to a defined ceiling, leaving only larger changes to the full board.

Tailoring for a Simple Project

v7 is explicit that the issues practice should be tailored to the project's complexity. For a simple project:

• Keep a single lightweight log rather than separate registers.
• Use short Product Descriptions and simple version control — a shared folder with dated filenames may suffice for low-risk products.
• Apply the 5-step technique but with minimal documentation — a quick conversation can be the assess and recommend steps, with the decision recorded in a single line.
• Resist the temptation to over-control. The guiding principle, communicate before control, matters most when the project is small: heavy procedures discourage early reporting, which is the very behavior the practice is designed to encourage.

Even on a simple project, two things must not be lost: keeping the business case valid (every change is checked against it) and maintaining a visible audit trail of decisions taken.

Exam application

Practitioner scenarios in this area typically test:

• Who has authority to decide on a described change (PM, Change Authority, or Project Board).
• Which record holds product status — in v7 that is the Product Register inside the Project Log, not a Configuration Item Record or a Product Status Account.
• How a change is prioritised — using the benefits/scope/risk/quality/time/cost lens.
• Tailoring — recognizing that a simple project should use lighter change control rather than the full enterprise machinery.