PRINCE2 2017 Change Theme: Issue and Change Control

Executive summary

Purpose and the meaning of an issue

The Change theme provides a controlled way to identify, assess and manage issues that may affect approved project baselines. The supplied material uses issue broadly for a relevant event that has happened, was not planned and requires management action. This makes issue management different from risk management: risk deals with uncertainty about future events, while an issue deals with something that is already known or has occurred.

Change control is not intended to stop change. Projects discover new information, customers refine needs, products fail tests and external circumstances shift. The objective is to ensure that these events are examined consistently and that authorised people decide whether and how the baselines should change.

The source expects the project to define its issue/change-control approach, maintain an Issue Register or equivalent, establish authority and ensure issues are captured, examined, managed and reviewed throughout the lifecycle. It also links the theme to lessons and to continued business justification: a proposed change can be attractive locally yet damage the overall investment case.

Three issue types

Correct classification helps because decision options differ. A request for change starts from a desire to alter an approved baseline. An off-specification starts from a failure or forecast failure to meet what was already agreed. A problem or concern may be operational, contractual, organisational or technical and can later lead to a request for change or a risk response.

Classification should not become bureaucracy. The purpose is to give management enough information to apply the right control path. Low-severity matters may be handled informally if the project’s approach permits it; material issues should be recorded formally.

Change Control Approach, Issue Register and baselines

The project’s Change Control Approach explains how issues are identified and managed, how impacts on business justification are assessed, how product status and baselines are controlled, what change authority exists and what severity/priority scales are used. The source also requires clear roles and responsibilities.

The Issue Register records formal issues and the decisions made about them. A well-maintained register should support traceability: what was identified, when, by whom, how it was classified, its assessed impact, options considered, authority, decision, actions and closure status. Informal matters can be held in the Daily Log until escalation or formal management is justified.

Baseline control is important because an approved product or plan should not be silently changed. Configuration information, product status and version control support this. A decision to approve a change should create a new controlled baseline or authorised action, not an undocumented instruction that leaves different teams working to different versions.

Change authority and change budget

Not every change needs to reach the Project Board. The source allows the board to delegate authority to a change authority, which might be the Project Manager, Project Assurance or another defined role/group. Delegation should specify the kinds or value of changes that can be approved and the limits within which that authority operates.

A change budget may also be established to fund approved changes. This allows predictable change activity to be managed without repeatedly reopening the overall project budget. The commissioning authority or Project Board determines the authority and budget arrangements appropriate to the project.

Delegation works only when escalation rules remain clear. A change authority should not approve an apparently small change that causes the stage or project to exceed its tolerances, undermines the Business Case or exceeds the authority’s defined limits. Such matters move to the appropriate higher level.

Step 1 — Capture

Capture begins when an issue is identified. The Project Manager performs an initial analysis and decides whether it can be dealt with informally or needs formal recording and an Issue Report. This is a triage decision: recording every minor conversation as a formal issue can overload control, while failing to formalise significant matters destroys traceability.

Capture should establish enough facts to understand the issue: description, type, source, date, affected product or baseline, urgency and apparent severity. If the matter is an off-specification, describe the actual or forecast deviation objectively. If it is a request for change, state what baseline is proposed to change and why.

Do not decide the solution during capture. Prematurely committing to one action can bias the later impact assessment. The aim is to create a clear problem statement and route it through the agreed process.

Step 2 — Assess and Step 3 — Propose

Assessment examines the issue’s impact. The source indicates that impacts can extend across project objectives and management baselines. Consider products, scope, quality, time, cost, benefits, risks, Business Case viability, plans and tolerances. Also consider consequences for other products and external interfaces; a local change may create a larger integration problem.

After impact is understood, the Project Manager develops possible responses and recommends a course of action. Options can include doing nothing, correcting an off-specification, changing a baseline, accepting a concession, changing the delivery approach or escalating because the project cannot absorb the impact within tolerance.

Recommendations should show trade-offs rather than only present a preferred answer. Decision-makers need enough information to compare cost, timing, risk, benefit and product impacts. For material change, the analysis should explicitly state whether continued business justification is affected.

Step 4 — Decide and Step 5 — Implement

The decision is made by the level of authority defined in the project. For a request for change, the authorised decision-maker may approve, reject, defer, request more information or escalate. Off-specifications may be corrected, accepted with concession where authorised, or handled through another action. Problems and concerns may be resolved through corrective action without changing a baseline, or they may create a formal change.

Implementation converts the decision into controlled action. Update the Issue Register and affected plans, Product Descriptions, configuration information, Work Packages, budgets or risk records as required. Communicate the decision to everyone working from the affected baseline. If the decision creates new risks, record them. If it changes benefit assumptions or project viability, update the Business Case and related management products.

Finally, confirm that implementation actually resolved the issue. A register entry marked “approved” is not the same as a completed change. Closure should be based on evidence that the new baseline or corrective action is in force and that affected products and teams are aligned.

Integrating change, risk and exception control

Issue control and risk control interact but remain distinct. A materialised risk can create an issue. An issue assessment can identify new risks. A proposed change can reduce one risk while introducing another. Keep the registers linked where useful without treating them as interchangeable.

Exception control is also separate. If a change or issue can be handled within the Project Manager’s stage tolerance and delegated change authority, it may not require escalation. If the forecast effect means stage tolerance will be exceeded, the Project Manager raises an Exception Report to the Project Board. The board may then request an Exception Plan. The trigger for escalation is forecast loss of tolerance, not simply the existence of a change.

This integrated view avoids two extremes: escalating every minor change to the board, or allowing “routine change” to gradually consume tolerance and destroy the authorised stage baseline.

Practical verification checklist

• Define how issues will be captured, classified, assessed, decided and recorded.
• Maintain an Issue Register for formal issues and decisions.
• Use the three issue types consistently: request for change, off-specification, problem/concern.
• Define change authority and its limits before significant change activity begins.
• Define any change budget and rules for its use.
• Assess material issues against products, plans, objectives, risk, tolerance and Business Case.
• Present options and consequences before seeking an approval.
• Update controlled baselines and configuration information after approved changes.
• Escalate when the forecast impact exceeds delegated tolerance or authority.
• Verify that approved action was implemented before closing the issue.

Common mistakes to avoid

• Treating every issue as a risk even after the event has occurred.
• Making informal scope changes without updating a controlled baseline.
• Escalating every small change to the Project Board despite delegated authority.
• Approving changes based only on technical desirability without considering Business Case impact.
• Confusing change authority with unlimited authority to change tolerances.
• Marking an issue closed when the decision was made rather than when implementation was verified.

Related KEVOS handbook pages