Why risk registers go zombie—owners, alerts, and closure evidence must enter the project cadence

The table from Monday's regular meeting

During the middle of the PMO regular meeting, the project manager of the red-light project said, 'We have already identified the risks.' A project initiation Excel file popped up on the screen, with the last column's update date still three months ago. A stakeholder next to him flipped through their notebook: 'I have another one here, updated just last week.' The meeting room fell silent for two seconds—everyone realized that while the registry exists, the rhythm does not.

Manufacturing delivery projects are particularly vulnerable: payment is tied to contractual milestones, and on-site daily conditions are reported. If delays, resource overloads, or scope changes are not visible in the same ledger, they will suddenly 'explode' during review meetings. Long spreadsheets that are never updated are more dangerous than having no spreadsheet at all—they give the illusion that 'risks are being managed,' and management continues to throw more people into the pit based on this.

There is also a more hidden way of dying: writing 'risk is controllable' in the weekly report, but not having any item marked with the next review date. Something that is verbally controllable cannot be randomly checked, and things that cannot be randomly checked will inevitably drift during the execution period.

The register of living people only recognizes four things

Stop arguing about 'whether to add another column for probability × impact.' The matrix can have it, but first solidify these four things, and the table will come to life:

On-the-spot judgment: randomly pick three risks and see if you can state the owner, the next review date, and the basis for closure within two minutes. If you can't answer, this registry is a zombie.

Opportunities also need to be recorded. Submit early delivery windows and reusable solutions, and leave proof when closing: whether it has been converted into a change or scope adjustment. If only threats are recorded, the team will interpret risk management as fault-finding, and the identification phase will be handled perfunctorily.

Stakeholder layering (governance / management / execution) must also be applied to risk: who decides to accept residual risk, who coordinates resources, who implements the response. Everyone participates, no one is responsible, is the organizational version of zombification.

Record deviations immediately, don't wait for review to make up for them.

The second most common cause of zombification: progress, acceptance, and changes each go their own way, and the registry is only filled in when someone remembers. The rule should be the other way around — major deviations should generate or link to risk items based on thresholds, rather than waiting until completion to write lessons.

Recommended automatic/semi-automatic entry to be frozen:

1. Milestone delayExceeding the threshold (such as threatening payment nodes) generates risk, linking the original milestone with the responsible roles.
2. Acceptance overdueLegacy items with conditional closures overdue and not cleared are entered into the register and escalated.
3. Scope Change: When the risk level in the impact assessment reaches the threshold, it automatically links to the registry entry.
4. Key role overload: If resource board conflicts persist beyond the agreed window, a risk source entry can be generated.

Once thresholds are written into the system, don’t change them every week. Small fluctuations can just go into the issue list; issues and risks should be managed separately, but both need an owner and closure criteria — the issue list only grows and never shrinks, which is the same kind of problem as zombie risks.

Changing silent pass (saying 'we'll discuss later' in emails, doing it first on-site and filling in later) almost inevitably comes with zombie risks: no impact assessment is done, so of course there is nothing in the registry to match. The WBS baseline and change approval are the upstream gates; the registry is downstream operation. If there is leakage upstream, no matter how diligently you fill downstream, it will never be full.

Alert the person, shutting down requires evidence

If early warnings only appear at the end of the weekly report, it is equivalent to no warning. The responsible person must receive overdue/upcoming deadline reminders in the message center or task pool; if no one responds, the escalation path is followed (Project Manager → Program/Stakeholder Governance Level). After escalation, someone must take charge; 'escalated but unclaimed' is prohibited.

Closure cannot just change the status. At least one type of evidence should be left:

• The response action has been completed, and the trigger condition has disappeared; or
• Residual risks are accepted in writing (including the accepter and the date); or
• It has been converted into a problem/change and a new document number has been assigned.

Closing without evidence will lead to the same risk emerging in the next project—the risk checklists in the knowledge base will also become emptier and emptier. PMO assessments should not only count 'how many items were identified,' but should look at the overdue rate, the completeness rate of closure evidence, the response time for automatically generated items, and whether recurring issues are linked to old entries.

Outsourced teams can report on response progress, but the confirmation of closure and escalation path are still subject to trimming by the project organization. If the right to close is completely handed over to external parties, the register will become their progress sheet rather than the client's risk ledger.

What should the system catch (align with PMS)

JEDP-PMS executes and monitors the coverage of issue lists and deviation/risk management: rules, responsible persons, and alerts; major delays can generate risk items and push them to the message center; the project portfolio view can summarize overdue risks and communication records. Sampling suggestions include: responsible persons and closure evidence for random risks/issues; whether major deviations from the baseline plan trigger risk alerts; whether tasks—reporting—costs—documents can, when drilled down by the same project ID, have the risk items associated with milestones or change orders.

When implementing, there’s no need to apply the entire group template all at once. Start with the red-light projects: template fields enforce owner and review date → milestone delay rules activated → meetings should switch to viewing the 'expired queue and closing evidence' instead of table length. The risk checklists in the knowledge base and solution library can assist in project initiation, but once published to the project register, the project manager still confirms the owner and response—the checklist cannot replace the schedule.

The scenarios where it is not suitable to enforce this are also clear: extremely short and fast, no PMO, purely operational without a project system—do not create a registry just for the sake of creating one. Only projects with contractual milestones and cross-departmental deliveries are worth embedding the registry into the weekly rhythm. Projects without WBS discipline and only milestone PPTs should first be task-ized before discussing risk alerts; otherwise, the alerts will only become another nice-looking light.

How should the rhythm of regular meetings change to be considered part of operations?

Change the regular meeting materials from 'Project Introduction Progress Percentage' to just three pages:

1. Expired queueRisk of no progress updates after the review date has passed.
2. New Arrivals This Week: Entries newly generated or newly associated by delay/change/overload rules.
3. Planned to close: Provide evidence links or attachments, and confirm or reject on the spot.

The color board can be retained, but colors must not replace the queue. Program managers look at the summary of overdue and duplicate risk themes, which is more suitable for governance than each project’s individual Excel sheet. On the cost side, if there is an EAC deterioration, it should be possible to trace whether there is an existing corresponding risk item—the budget impact and risk operations should be visible to each other.

Three types of zombies, different approaches for each

In practice, the register 'seems to exist but is not used,' usually falling into three forms, with different governance approaches:

The first relies on rhythm; the second relies on master data discipline; the third relies on an evidence gate. When mixed together, a common ineffective remedy is 'retraining on risk identification methods'—identifying is not the bottleneck, operations are.

At the program level, there is a fourth risk to guard against: each project may be healthy on its own, but from a portfolio perspective, repeated themes are not visible (the same supplier, the same key role, the same interface repeatedly at risk). The value of a consolidated view is not in having one more heat map, but in allowing the governance level to see that 'the same type of risk recurs across multiple projects.' Recurrences that are not linked to previous entries make even the thickest knowledge base just a collection of bookmarks.

Costs and risks should also point to each other. When budget items deteriorate and the EAC rises, if the registry shows all green lights, it's not that risks are well managed, but that the two sets of accounts haven't aligned. Conversely, if the risk entry says 'possible overspending' but the cost calculations show no changes, it indicates that the response actions may never have entered procurement or labor hours—the registry has again become just a formality.

Do these three steps next week

Don't open another 'Risk Management Training.' Open the hottest project currently:

1. Export the registry, mark the entries that are ownerless, expired and not updated, or closed without evidence, and read them out at the beginning of the meeting.
2. Compare the last two milestone delays with one scope change: whether a risk item was generated or linked; if not, draft the rule on the spot (threshold escalation path responsible role).
3. The next regular meeting will only discuss the evidence for expired queues and items proposed for closure, and will not discuss 'how long the table is'; two weeks later, review whether the number of expired items has decreased.

If the expired queue does not decrease within two weeks, do not expand the project set templates yet — expanding will only copy zombies. When the rules are triggered but no one responds, first check whether the upgrade path is actually being monitored, then check if the fields are being 'required but ignored,' rendering them ineffective. Only when you can point out the storage location of evidence for each expired risk on the spot can the process be considered established; otherwise, first update the owner and review date before discussing the project set dashboard.

• PMS project solution
• WBS change control
• Acceptance Milestone
• Resource overload