Integrating quality, risk, issues and progress across the project

Lessons 1 to 9 studied the four control practices one at a time. On a real project they are never separate. A failed quality check creates an off-specification; the off-specification may realize a risk that was already in the register; deciding it may need a change, funded from the change budget; and the change consumes tolerance that the progress practice monitors. This lesson looks at how information flows between the four practices, how they are set up during initiation, how they appear in the processes, and how the project log ties their records together. It ends with a worked trace of a single event through all four practices.

How the practices pass information

Two flows deserve particular attention. First, the link from risk to issue: when a risk occurs, it should be closed in the risk register and raised in the issue register, with a reference between them, so that the board can see whether the planned response worked. Second, the link from issues to progress: every approved change alters a baseline and may use tolerance, and if the progress practice does not see the change, forecasts will be compared with plans that no longer exist.

Setting up the practices in initiation

All four practices are set up during initiating a project, when the project manager prepares the management approaches that become part of the project initiation documentation. PRINCE2 7 also introduced further management approaches that relate closely to the control practices, including a digital and data management approach, which describes how the project will use data and digital tools, and a commercial management approach. Lesson 11 returns to the digital and data approach. The approaches should be prepared together, because they share scales, roles and reporting.

Consistency matters more than length. If the risk management approach scores impact in thousands while the issue management approach rates severity on a different scale, the same event may be treated as minor in one register and severe in the other. A single page that defines common scales, a shared escalation threshold and one reporting rhythm for all four practices is often more useful than four separate documents.

The practices across the processes

The processes, which PRIN-140 and PRIN-141 study in detail, are where the practices are carried out. The table below shows, in outline, where each control practice is most active. The pattern is regular: approaches and baselines are set up in initiation, monitored during each stage, reviewed at stage boundaries and closed at the end.

The project log as the shared record

In PRINCE2 7 the project log brings the records of all four practices together: the daily log, issue register, risk register, quality register, lessons log and product register. Linking records is what makes integration visible. An off-specification in the issue register should refer to the quality register entry that found it and the product register entry for the product. A risk that occurs should refer to the issue it became. A change approved by the change authority should refer to the plan versions it altered. Most project tools support these links directly; on a small project a simple identifier convention does the job.

Tracing one event through all four practices

The code below traces a single event, the factory shutdown announced in week 15 of the pilot, through the four practices as linked records. It shows how one event creates or updates entries in several registers, each referring to the others, and ends with the effect on tolerance used. The structure is a teaching model of what a project tool would hold.

log = {"risk": {}, "issue": {}, "quality": {}, "product": {}, "change": {}}
log["risk"]["R1"] = {"text": "Pilot meters delivered late", "status": "open", "ev_k": 31.5}
log["product"]["P-04"] = {"title": "Meters installed", "planned_week": 20, "forecast_week": 20}
time_tol, time_used = 2.0, 0.0

# week 15: the supplier announces a two-week factory shutdown -> the risk occurs
log["risk"]["R1"]["status"] = "occurred -> I-03"
log["issue"]["I-03"] = {"type": "problem or concern", "from_risk": "R1", "status": "assessing"}
# assessment: meters 2 weeks late; installation has 1 week of float -> 1 week stage delay
log["product"]["P-04"]["forecast_week"] = 22
time_used += 1.0
# response: supplier ships part of the batch by air at its own cost (contract transfer clause)
log["change"]["C-02"] = {"for_issue": "I-03", "effect": "resequence installation", "cost_k": 0}
log["issue"]["I-03"]["status"] = "decided: resequence; supplier pays air freight"
# quality: the air-shipped meters need the same factory sample test
log["quality"]["Q-018"] = {"product": "P-04", "method": "factory sample of 50", "planned_week": 18}

for reg, entries in log.items():
    for k, v in entries.items():
        print(f"{reg:8} {k:6} {v}")
print(f"time tolerance used {time_used} of {time_tol} weeks ({time_used / time_tol:.0%})")

risk     R1     {'text': 'Pilot meters delivered late', 'status': 'occurred -> I-03', 'ev_k': 31.5}
issue    I-03   {'type': 'problem or concern', 'from_risk': 'R1', 'status': 'decided: resequence; supplier pays air freight'}
quality  Q-018  {'product': 'P-04', 'method': 'factory sample of 50', 'planned_week': 18}
product  P-04   {'title': 'Meters installed', 'planned_week': 20, 'forecast_week': 22}
change   C-02   {'for_issue': 'I-03', 'effect': 'resequence installation', 'cost_k': 0}
time tolerance used 1.0 of 2.0 weeks (50%)

One event produced or changed five records: the risk was closed as occurred with a pointer to the issue; the issue was assessed and decided; the product's forecast date moved two weeks; a change was recorded to resequence installation; and a quality activity was added for the air-shipped meters. The net effect on progress is one week of the two-week stage time tolerance, half of it, because installation had one week of float. Without the links, the board would see a closed risk, a decided issue and a late product as three unrelated facts.

Signs that the practices are not integrated

Assurance reviews often find that each register looks tidy on its own while the project as a whole is drifting. The symptoms are recognizable, and each points to a broken link between two practices. The table below lists the most common ones and the link to repair.

None of these failures requires more documentation to fix. Each needs one habit: when something changes in one register, ask which other registers and plans must change too. Project support can build this habit into the weekly register review by working through a short checklist of cross-references, and project assurance can test it at stage boundaries by picking one recent event and tracing it through every record it should have touched, just as the code above did.