Monitor Risks and Control Procurements

The Register That Was Built and Never Opened

Open the risk register for a project that is six months into execution. Twenty-three risks identified at the start, scores assigned, response strategies written, owners named. Check in with the team. Two responses were completed in month one and never closed on the register. Three others were never started: the owners got pulled onto competing work, and no one followed up. A risk that materialized last week, a vendor delivery delay now threatening the critical path, is not in the register at all. This is what happens when risk identification is treated as a planning milestone rather than an ongoing discipline. The register that emerged from planning was a genuine effort. The register that exists today is a record of what someone was worried about six months ago.

A Living Document, Not a Planning Output

The risk register is not a deliverable you produce during risk management planning and file away. It is a project management tool that needs to reflect the current state of the project's risk landscape throughout the full project lifecycle. Monitoring risks means regularly doing several things that are easy to skip when execution is consuming the team's attention. It means updating the status of existing risks: which responses are in progress, which have been completed, which risks have passed their trigger window and can be closed. It means confirming that response actions are actually being executed by the people assigned to them. It means identifying new risks that have emerged as the project has encountered real conditions that planning could only estimate. And it means closing out risks that no longer apply rather than letting the register accumulate entries that have no bearing on the current project.

Risk statuses should mean the same thing to every team member. Vague labels like "open" or "in progress" generate exactly the ambiguity that lets a register go stale. A shared vocabulary makes status reviews faster and more accurate:

• Identified. Risk is in the register and has been assessed; response not yet planned.
• Response planned. Response action defined, owner assigned, due date set.
• Response in progress. Response action underway; owner providing updates.
• Trigger reached. The condition that activates the contingency plan has occurred.
• Materialized as issue. The risk has occurred; transferred to the issue log for resolution.
• Closed. Trigger window passed without materializing, or response fully completed with no further exposure.
• Escalated. Risk severity exceeds PM authority; transferred to sponsor or steering committee.

A register full of stale statuses and outdated ownership information is not a risk management tool. It is an artifact. It creates the appearance of discipline without the substance. The PM who pulls it out in a steering committee meeting to demonstrate that risk management is in place, but hasn't looked at it in two months, knows exactly the gap between what is shown and what is real. That gap has a cost, and it usually becomes visible at the least convenient moment.

The Landscape Shifts During Execution

The risk landscape changes as a project moves forward, sometimes substantially. Risks that seemed likely during planning never materialize and can be closed. Others that seemed low probability become more relevant as the project encounters real conditions: a vendor announces a merger, a key team member leaves, a dependent project falls behind schedule and creates a new constraint. These new risks need to be identified, assessed, scored, and added to the register with responses assigned. The PM who only monitors the original list is managing half the picture at best. Risk monitoring means watching for what wasn't anticipated, not only verifying what was.

One of the most useful habits in risk monitoring is the simple question asked at every project status meeting: what has changed in the last two weeks that could affect the project's risk exposure? Not "are there any new risks" in a formal sense, but a direct open question about whether anything new has emerged that deserves a place in the register. Team members often carry awareness of developing risks that don't make it into the register because there is no regular moment that invites them to surface it. The standing question creates that moment.

Escalation Triggers

Part of monitoring risks is watching for escalation triggers, conditions that mean a risk needs to move to a higher level of attention or authority. A risk that has grown significantly in probability or impact, a response that has failed to contain the threat it was designed to address, a new risk that carries major consequences for the critical path, these warrant raising to the sponsor or steering committee rather than managing within the PM's authority. Escalation is not a failure of the PM's capability. Escalating a risk before it becomes a crisis is exactly what good risk monitoring looks like. The PM who surfaces a developing threat in month three with enough time to respond is delivering value. The PM who waits until the threat has become an issue and there are no good options is delivering a problem.

Building the Cadence

Risk monitoring works best when it is built into the project's existing rhythm rather than maintained as a separate track of activity that competes with everything else for attention. The highest-scoring active risks deserve visible attention at every project status review. Not a deep analysis every time, but a standing question: what has changed for the risks we are watching most closely? Which response actions were due this period and what was the outcome? Are there new risks from the last two weeks that belong in the register? A fifteen-minute risk review embedded in a standing meeting takes almost no additional time. The risk register gets updated between sessions by the response owners as part of the commitment they made when the action was assigned. The meeting then confirms that the updates happened and that the picture is current.

A repeatable agenda keeps the review focused and consistently productive:

1. Review top active risks: are scores, probabilities, and impacts still accurate given recent events?
2. Confirm response actions due this period: what was completed, what is overdue, and who owns the gap?
3. Identify new risks from recent changes, new vendor information, or emerging project conditions.
4. Close risks whose trigger window has passed or whose response is fully complete with no remaining exposure.
5. Escalate risks that have grown beyond PM authority or where the assigned response has failed.
6. Update the register before the next review: owners, due dates, scores, and statuses.

Controlling Procurements: The Contract as Baseline

The risk register and the project contract have something important in common: both are carefully constructed documents that tend to receive less active attention during execution than they received during planning. Controlling procurements means managing the relationship with vendors and contractors in a way that is documented, formal, and grounded in the contract terms rather than in the working relationship that develops alongside it. The contract is the baseline. Control procurements is the process of measuring actual vendor performance against that baseline, the same way schedule performance is measured against the schedule baseline.

Procurement control extends beyond checking whether the final deliverable arrived. These indicators reflect vendor performance across the full relationship: delivery timeliness against the schedule, defect and rework rates, response time to issues and queries, frequency of change order requests, invoice accuracy, documentation completeness, and compliance with the agreed reporting cadence. A vendor who delivers on time but with high rework rates is performing differently from one whose rate is clean but slow. Watching the pattern across indicators, not just the final delivery, gives the PM a more complete picture of vendor risk and relationship health.

The contract, combined with its statement of work, specifies what the vendor is expected to deliver, by when, and to what quality standard. When vendor delivery deviates from those specifications, the deviation needs to be captured and formally addressed. Either a change request is raised to modify what was agreed, or the vendor is held to the original specification with documented notice that the current delivery does not conform. The worst outcome is allowing a vendor to quietly deliver something different from what was contracted without formal acknowledgment on either side. That ambiguity is nearly impossible to resolve cleanly when a dispute arises later, because neither party can establish what was actually agreed at the moment the deviation occurred.

Procurement Change Orders

Changes happen in vendor relationships, and they need to go through the same formal change control process as any other project change. A procurement change order documents a modification to the contract: a change in scope, a revised delivery date, an adjustment to cost. Both parties sign. The change log is updated. The project management plan reflects the new commitment. This protects the project from scope creep on the vendor side, the gradual expansion of what is being delivered without a corresponding adjustment to the contract or budget. Verbal agreements about scope changes in vendor relationships are not change orders. They are the beginning of a dispute about what was actually agreed. Whatever is discussed needs to get into writing, with both parties' signatures, before work under the changed terms begins.

Inspect Before You Pay

No vendor invoice should be approved until the work it covers has been inspected and accepted against the acceptance criteria in the statement of work. This sounds straightforward. In practice it is regularly skipped when teams are busy, the vendor relationship is collaborative, and the invoice is for work that everyone believes was done well. The problem is that approving an invoice before the deliverable is confirmed as conforming removes the PM's primary tool for holding the vendor accountable to what was specified. Once payment is released, the leverage shifts completely. The vendor has been paid for work that may turn out to require rework. Recovering that cost after the fact, or holding the vendor to additional effort without contractual leverage, is a very difficult position to be in.

For partial payments, inspect the milestone or percentage of work the invoice claims, not the final deliverable. Many contracts structure billing around defined checkpoints. The same rigor applies at each: confirm the checkpoint is reached before releasing the payment for it.

A consistent checklist for each invoice cycle keeps the process disciplined:

• Review the deliverable or milestone against the statement of work and acceptance criteria.
• Confirm acceptance or document specific deficiencies in writing.
• Process any deficiencies: rework request, formal vendor notice, or change order as warranted.
• Verify the invoice amount matches the accepted scope, not the submitted scope.
• Update the schedule and cost forecast to reflect the confirmed delivery status.
• Maintain a vendor communication record including all acceptance decisions and formal notices.

That order, every time, is what keeps procurement control meaningful rather than a review process that happens after the leverage is already gone.

Documentation Protects Everyone

The reason procurement control documentation matters becomes clear at the moment of a dispute. If a vendor misses a delivery and the project suffers a schedule impact, the question of accountability hinges on what was committed, what was communicated, and what was formally acknowledged. A PM who has a documented trail, written delivery commitments, status communications, emails confirming missed milestones, formal notices of deficiency, is in a completely different position than one who handled the same relationship informally. The documentation is not adversarial. It is a shared record that protects the project when things go wrong, protects the vendor from demands that exceed what was agreed, and protects the PM from disputes about what actually happened. Create the record when the relationship is going well. You may never need it. But you cannot create it retroactively when you do.

What's Next

The next chapter, Monitor Stakeholder Engagement, addresses the final monitoring process in this section: tracking whether the stakeholders who were engaged at project launch are still engaged in the ways the project needs, and what to do when the engagement picture has shifted in ways that create risk.

Reflect

• When did you last review the risk register for a project you are managing and close out risks that had passed their trigger window or been fully resolved? What was in the register that no longer reflected the current state of the project?
• Think about the risk review meeting structure on your current or most recent project. Were owners confirming the status of their response actions before the meeting, or were updates happening verbally during it? What changed when the structure required written updates first?
• On your most recent vendor engagement, was the sequence of inspect-then-approve followed consistently for each invoice? Where it wasn't, what pressure led to approving before accepting, and what could have been different?
• Have you had a verbal agreement with a vendor about a scope or timeline change that was never documented? How did that affect the conversation when the change's terms became disputed later?