Implementing Risk Responses and Conducting Procurement

The Register That Gets Filed Away

Risk management has a well-documented failure mode. Teams spend real time in planning identifying risks, scoring them, assigning owners, and writing response strategies. The register looks thorough. Then execution begins, and the register is saved to a folder and never opened again. Weeks pass. When a risk materializes into an actual problem, the team responds reactively — often discovering that the response they planned is no longer feasible because no one started working on it when they should have. Implementing risk responses exists precisely to prevent this. Its purpose is not to plan responses but to make sure the ones already planned are actually executed.

Responses Happen Before the Risk Event

This is the part that is most commonly misunderstood. Implementing a risk response does not mean responding after the risk occurs. It means taking the actions planned — before the risk event — to reduce the probability it happens, reduce the impact if it does, or transfer the consequence to someone better positioned to absorb it. A pre-qualification questionnaire sent in week five is a response in action. A vendor contacted before a delay materializes is a response in action. Waiting until the risk hits turns a planned response into emergency management, and emergency management is dramatically more expensive in time, cost, and relationship damage than the proactive version would have been.

The Register Is a Living Document

After a response is implemented, the status of the risk should change to reflect what has actually happened. A risk moves from Open or Pending to Monitor once a response is in place and the team is watching for effectiveness. A risk whose triggering condition no longer exists gets closed, with a note explaining why. These status changes are not housekeeping. A register full of Open risks with no status progression looks identical to a register where nothing has been actioned. The status is how the team knows what has been worked, what needs attention, and what has been put to rest. Keep it current or it stops being a management tool and becomes an archive of planning intentions.

Risk Reviews Belong on the Agenda

The risk register is most useful when it is reviewed on a regular cadence, not updated passively between status meetings and never discussed. A standing risk review item on the project status meeting agenda does not require reviewing every entry every time. The highest-scoring active risks should be visible at every meeting. The team member who owns each response should be able to give a brief status. A register entry with a score of 16 marked Open should not survive three consecutive meetings without a check-in from the response owner. Risk management is a running habit, not a planning milestone, and building it into the weekly cadence is the only thing that keeps responses from getting buried under more immediately visible work.

When Scope Becomes a Contract

The procurement strategy built during planning defined what the project would buy and from what type of source. Conducting procurement is where that strategy becomes a binding agreement with a vendor. The transition from internal document to external contract is where projects win or lose meaningful amounts of scope, schedule, and cost. A procurement process done well produces a contract that is clear, protects the project, and gives the vendor exactly what they need to deliver. A procurement process rushed or skipped produces a contract that is vague, generates disputes, and costs the project far more to resolve than the procurement would have cost to run properly.

Matching the Process to the Purchase

Not every purchase requires the same level of process, and applying the wrong level in either direction wastes time or creates risk. At one end of the spectrum: direct purchase. The item is simple, the cost is small, the vendor is established — no formal procurement needed. At the other end: a formal competitive process for a complex service where the solution itself is not yet defined. The level of process applied should match the complexity, cost, and risk of what is being bought. One useful pattern: as specification certainty decreases, the procurement vehicle shifts from price-focused to solution-focused.

The RFx Family

Four formal procurement vehicles are used in most project environments, each suited to a different level of specification clarity. An Invitation for Bid applies when scope is completely defined and the only variable is price — vendors bid against a fixed specification and award typically goes to the lowest responsive and compliant bid from a qualified vendor, subject to the organization's rules. A Request for Quote is similar but lighter: requirements are clear, selection focuses on price, and less administrative formality is required. A Request for Proposal opens the technical solution: the scope is defined but the vendor proposes how they would meet it and at what cost. A Request for Information sits at the far end, issued when you do not know enough yet to specify what you want. You are asking the market to educate you before designing the procurement. Understanding which tool fits which situation is one of the more practically useful things a PM can have ready before entering an execution phase with vendors to procure.

Two additional situations are common in practice. Pre-procurement means your organization already has a vendor agreement in place — a standing contract, a preferred vendor list, or a framework agreement — and your purchase falls within it. Quotation-based procurement means you contact several known vendors, share specifications, and ask for pricing without running a full RFx process. This works well for straightforward purchases where requirements are clear and competitive pricing is the goal. One caution worth noting: if an individual purchase seems small but the project will make it repeatedly, calculate the total before deciding the purchase is too minor for proper process.

Government Procurement Is Different by Design

Government procurement is usually regulated by law. Private procurement is typically governed by internal policy, contract law, audit expectations, and sometimes industry or funding-source rules. The reason is accountability: government spending is public money, and citizens have an interest in it being spent fairly and transparently. The regulations exist to prevent favoritism — contracts awarded on relationships or informal payments rather than merit. PMs working in government environments need to know the rules before the procurement begins: thresholds, approval layers, and timing requirements are not guidelines that can be waived when the project is behind schedule. They are legal requirements, and bypassing them creates organizational and personal exposure that no schedule pressure justifies.

Procurement Protects the Triple Constraint

Every element of a well-run procurement process connects back to the three things a PM is responsible for protecting. Scope is protected by a well-specified contract that defines exactly what is being purchased, closing the ambiguity that vendors otherwise interpret in their favor. Milestones and delivery dates in the contract protect the schedule. A competitive selection process produces a price that reflects the market rather than a number accepted under time pressure. Procurement is not a bureaucratic step before the real work starts. It is one of the most consequential decisions made during execution, and it deserves the care required to do it right. Once the vendor is selected, that result becomes a live project dependency: contract obligations, delivery milestones, reporting expectations, acceptance criteria, invoice rules, and change process all need to be visible in the project schedule and control routines from day one of the engagement.

What's Next

The next chapter, Managing Stakeholder Engagement in Execution, covers the ongoing work of keeping stakeholders appropriately engaged, routing their input through the right channels, and handling the situations that arise when that routing breaks down.

Reflect

• Think of a risk on a recent project that had a planned response. At what point was the response actually executed? Was it before the risk could materialize, or after it already had?
• How does your current project review risk register status? Is it a standing agenda item, or does the register only get opened when something goes wrong?
• For your most recent external procurement, which RFx vehicle was used and why? Was the choice deliberate, or was it the default process without considering whether it fit the purchase?
• If you work in or with government organizations, how well do you know the procurement thresholds and approval requirements? Where is that knowledge documented so it does not depend on any one person's memory?