Change control and the product register

Change is normal on projects. Users learn what they need by seeing early products, regulations change, suppliers find better methods, and defects appear. Change control does not try to stop change. It makes sure that every change to an agreed baseline is assessed, decided by someone with the authority to decide it, and reflected in the plans and records, so that the project never drifts away from what was approved without anyone choosing to let it. This lesson covers baselines, the change authority and change budget, how requests for change and off-specifications are assessed and decided, and how the product register keeps track of every product's status.

Baselines

A baseline is a reference level against which something is monitored and controlled. In PRINCE2, management products such as the business case, project plan, stage plans and product descriptions are baselined once approved, and specialist products are baselined once they have passed their quality checks and been approved. After that, they can be changed only through change control. This is what gives progress reports their meaning: the board can compare actual progress with a plan that has not been quietly rewritten.

Change authority and the change budget

PRIN-130 showed how the board can delegate decisions on changes to a change authority within agreed limits, and set aside a change budget to fund approved changes. The board remains responsible for change, but it does not want to decide every small request, and the project manager should not be able to approve large changes without the board's knowledge. Limits are usually set per change and per stage, and the change authority reports its decisions and the remaining change budget in each highlight report.

The change budget is separate from the cost tolerance and from the risk budget, which lesson 4 described. Keeping them separate lets the board see how much change the users are asking for. If the change budget is used up halfway through a stage, that is useful information: either the requirements were less stable than expected, or the change authority is approving too freely.

Assessing a request for change

A request for change is assessed in the assess and recommend steps of the issue management procedure. The project manager, often with team managers and the relevant assurance roles, estimates the impact of making the change on each of the performance targets and on the business case, and the impact of not making it. The assessment should also consider the change's priority, using the scale in the issue management approach, and any new risks it creates.

Decisions on requests for change and off-specifications

The decision-maker for a request for change may approve it, reject it, defer it to a later stage or ask for more information. For an off-specification, the options are to require the product to be corrected, to grant a concession and accept it as it is, or to defer. If neither the project manager nor the delegated change authority can decide within their limits, or if the change would breach stage tolerance, the decision goes to the board, normally through an exception report. Once decided, the project manager updates the affected plans, product descriptions and registers, and tells the originator.

The code below applies Ridgeline Water's routing rules to a batch of requests in the pilot stage, tracks the project manager's change budget as approvals are made, and shows where each request must go. It assumes each request has been assessed and that the project manager would approve those within his or her authority.

pm_limit, joint_limit = 10, 60     # thousand per change
pm_budget = 50                       # thousand per stage at PM level
time_tol_left = 2.0                  # weeks of stage time tolerance unused
requests = [  # id, description, cost (thousand), schedule effect (weeks)
    ("RFC-1", "Monthly bills in pilot district", 6, 0.0),
    ("RFC-2", "Alerts in two more languages", 8, 1.0),
    ("RFC-3", "Zero-use welfare alert", 14, 0.5),
    ("RFC-4", "Relocate 40 meters from flooded pits", 9, 0.0),
    ("RFC-5", "Add second pilot district", 310, 6.0),
    ("RFC-6", "Update portal logo to new brand", 4, 0.0),
]
for rid, text, cost, weeks in requests:
    within_time = weeks <= time_tol_left
    if cost <= pm_limit and cost <= pm_budget and within_time:
        route = "project manager approves"
        pm_budget -= cost; time_tol_left -= weeks
    elif cost <= joint_limit and within_time:
        route = "senior user and senior supplier"
    else:
        route = "project board (exception report)"
    print(f"{rid} {text:38} {cost:4}k {weeks:3.1f}w -> {route}")
print(f"PM change budget left {pm_budget}k; time tolerance left {time_tol_left:.1f} weeks")

RFC-1 Monthly bills in pilot district           6k 0.0w -> project manager approves
RFC-2 Alerts in two more languages              8k 1.0w -> project manager approves
RFC-3 Zero-use welfare alert                   14k 0.5w -> senior user and senior supplier
RFC-4 Relocate 40 meters from flooded pits      9k 0.0w -> project manager approves
RFC-5 Add second pilot district               310k 6.0w -> project board (exception report)
RFC-6 Update portal logo to new brand           4k 0.0w -> project manager approves
PM change budget left 23k; time tolerance left 1.0 weeks

The project manager approves four requests costing 27 thousand, leaving 23 thousand of the change budget, and the language change alone has used one week of the two-week time tolerance. The welfare alert, at 14 thousand, exceeds the project manager's limit and goes to the senior user and senior supplier. Adding a second pilot district, at 310 thousand and six weeks, is far beyond any delegated limit and would breach stage tolerance, so it goes to the board. The model also shows a subtle point: approving small changes one at a time can consume tolerance that the board might have wanted to keep for risks, which is why change approvals and remaining tolerance are both reported in highlight reports.

Change control in PRINCE2 and in IT service management

Students who know ITIL sometimes confuse PRINCE2 change control with ITIL change enablement. They address different baselines. PRINCE2 change control protects the project's baselines: its plans, business case and product descriptions. ITIL change enablement, covered in ITIL-140, protects live services and infrastructure from harmful changes, assessing risk and scheduling deployments. A project that delivers into live IT services must use both: the project board approves a change to the scope of the billing interface, and the utility's change authority for IT services approves the date and method of deploying the interface into the live billing system.

Configuration management and the product register

Change control depends on knowing exactly which version of each product is current and what state it is in. This is configuration management: identifying products, controlling their versions, recording their status and verifying that records match reality. Earlier editions of PRINCE2 used configuration item records and a product status account for this. PRINCE2 7 simplifies the records into a product register, held in the project log, which tracks each product's status from identification through development, quality checking and approval to handover and acceptance.

The product register is useful well beyond change control. Before a stage boundary, the project manager can list every product planned for the stage and its status, which shows at a glance what is approved, what is late and what has open issues. At closure it supports confirmation that every product has been handed over and accepted. The code below produces that kind of summary for the pilot stage products.

order = ["identified", "in development", "in quality check", "approved", "handed over"]
products = [
    # id, title, status, planned approval week, forecast week, open issues
    ("P-03", "Pilot radio network", "approved", 12, 12, 1),
    ("P-04", "Meters installed", "in development", 20, 22, 2),
    ("P-05", "Head-end configured", "approved", 11, 13, 0),
    ("P-07", "Billing interface", "in quality check", 21, 24, 1),
    ("P-08", "Alert design", "in development", 19, 23, 1),
    ("P-09", "Customer communications", "approved", 18, 18, 0),
    ("P-10", "Pilot measurement report", "identified", 29, 29, 0),
]
for pid, title, status, plan, fc, iss in sorted(products, key=lambda x: order.index(x[2])):
    late = fc - plan
    print(f"{pid} {title:26} {status:17} {'+' + str(late) + 'w' if late else 'on time':8} open issues {iss}")
approved = sum(1 for p in products if p[2] in ("approved", "handed over"))
print(f"approved {approved} of {len(products)}; late {sum(1 for p in products if p[4] > p[3])}")

P-10 Pilot measurement report   identified        on time  open issues 0
P-04 Meters installed           in development    +2w      open issues 2
P-08 Alert design               in development    +4w      open issues 1
P-07 Billing interface          in quality check  +3w      open issues 1
P-03 Pilot radio network        approved          on time  open issues 1
P-05 Head-end configured        approved          +2w      open issues 0
P-09 Customer communications    approved          on time  open issues 0
approved 3 of 7; late 4

Three of seven products are approved; four are late against their planned approval dates, with the billing interface forecast three weeks late and alert design four weeks late. The radio network is approved but still has an open issue, the coverage off-specification from lesson 5, which shows that approval and closure of issues are separate: the network may have been approved with a concession pending, and the register makes that visible.