Exam objective 1.8 asks you to explain risk, procurement, and stakeholder management——three processes that keep a project from derailing. Without them, you are effectively driving a car with no brakes, no fuel, and no map. Understanding these processes is what separates a project manager who just talks about deadlines from one who actually delivers.
Jump to a section
A simple way to picture Risk, Procurement, and Stakeholder Management
Would you start knocking down walls in your house without first checking which ones are load-bearing, finding a reliable builder, and making sure your family isn't going to revolt?
That's exactly what a project manager would be doing by jumping into a project without managing risk, procurement, and stakeholders. In a house renovation, risk management is like inspecting the property for asbestos, checking the roof for leaks, and planning for the possibility that your 'two-week' electrical job takes six because the wiring is from the 1950s. You identify what could go wrong, assess how bad it would be, and decide whether to fix the roof now or just patch it.
Procurement is your shopping list for the project. It's not just buying a new bathtub; it's writing a clear spec for a 'white, freestanding, 170cm cast-iron tub', getting quotes from three suppliers, checking their reviews and insurance, signing a contract that says they deliver by June 1st, and making sure they actually deliver the right tub. You don't buy the first one you see on Facebook Marketplace.
Stakeholder management is dealing with your partner, your neighbour, and the local council. Your partner wants an open-plan kitchen; your neighbour hates your new extension's shadow; the council says you need planning permission. A project manager would systematically map out these people, understand what they care about (your partner wants space, the neighbour wants light), and figure out how to keep them happy enough that the project doesn't get blocked. Ignore the neighbour, and you get complaints to the council. Ignore the partner, and you're sleeping on the sofa.
This analogy maps precisely because every risk, every purchase, and every person in a project needs the same structure and careful planning as a house renovation. Ignore any one of them, and your project——like your dream kitchen——can collapse.
Let's break down each of these three pillars that the CAPM exam expects you to know inside out. They are not separate topics; they are three legs of the same stool.
Risk Management
A risk is any uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives. Notice the 'positive' part——risks can be good (an opportunity) or bad (a threat). The goal of risk management is not to eliminate all risk; that is impossible. The goal is to understand the risks and then decide proactively what to do about them.
The formal process has several steps. First, you plan risk management——you decide how you will approach the whole activity, including who will be involved and what templates you will use. Next, you identify risks——you brainstorm with the team, review documents, and ask 'what could go wrong?' and 'what could go better?'. You then capture each risk in something called a risk register, which is basically a spreadsheet or log that lists every risk, its description, its likelihood, and its potential impact.
After identification comes qualitative risk analysis. This is a quick, subjective assessment where you rank risks by probability and impact using a simple scale like High, Medium, and Low. It lets you focus on the most urgent risks first. If a risk is High probability and High impact, it gets immediate attention. Next is quantitative risk analysis, which is a more numerical approach. You might use data to model what happens to the project budget if a key supplier goes bankrupt, or use a technique called Monte Carlo simulation (a fancy name for running the project schedule thousands of times with different random inputs to see the range of possible completion dates).
Once you have analysed the risks, you plan risk responses. This is where you decide exactly what you will do. The main response strategies for threats are:
Avoid: Change the project plan to eliminate the risk entirely (e.g., use a different, more reliable technology).
Transfer: Shift the risk to someone else (e.g., buy insurance or use a fixed-price contract so the vendor carries the cost of overruns).
Mitigate: Reduce the probability or impact of the risk (e.g., add more testing to reduce the chance of a software bug).
Accept: Acknowledge the risk and take no proactive action, often because the cost of handling it is higher than the potential damage.
Finally, you implement risk responses and monitor risks throughout the project. You check if the responses are working and watch for new risks.
Procurement Management
Procurement is the process of acquiring products or services from outside the project team. Your company might build its own software, but it will still buy servers, cloud services, or legal advice. The formal name is Project Procurement Management.
It starts with planning procurement. You decide what you need to buy, when, and under what type of contract. The two main contract types relevant to the CAPM are fixed-price contracts, where the price is agreed upfront and the seller bears the cost risk, and cost-reimbursable contracts, where the buyer pays the seller's actual costs plus a fee, so the buyer bears the cost risk. There is also time and materials contracts, a hybrid used when the scope is not fully defined.
Next comes conducting procurement. This is the process of getting seller responses, evaluating them, and awarding a contract. You send out a document like an RFP (Request for Proposal) or RFQ (Request for Quote). You then receive bids, evaluate them against pre-defined criteria (cost, experience, past performance), and negotiate a contract with the chosen vendor.
After the contract is signed, you move to controlling procurement. This is the 'managing the relationship' phase. You monitor the vendor's performance, approve invoices, and manage any changes to the contract. If the vendor is late, you use the contract's terms to enforce delivery or apply penalties.
The final step is closing procurement. You verify that all the work was done correctly, settle any outstanding claims, and formally close the contract. You also update the project's lessons learned documentation so future projects know which vendors were good and which were not.
Stakeholder Management
A stakeholder is any individual, group, or organisation that can affect, be affected by, or perceive itself to be affected by the project. That includes your project sponsor, the customer, the end users, the development team, the legal department, the government regulator, and even the janitor who will need to clean the new equipment. Project Stakeholder Management is the process of identifying these people, understanding their expectations, and keeping them engaged.
The process begins with identifying stakeholders——you list every possible person or organisation with an interest in the project. You capture their names, roles, power, and interest in a stakeholder register. Tools like power/interest grids (a simple 2x2 matrix) help you classify them. High-power, high-interest stakeholders you manage closely; low-power, low-interest ones you just monitor.
Next is planning stakeholder engagement. You decide how you will interact with each stakeholder or group. The main engagement levels are:
Unaware: Stakeholder does not know about the project or its potential impact.
Resistant: Stakeholder knows about the project but is opposed to it.
Neutral: Stakeholder knows but does not care either way.
Supportive: Stakeholder knows and supports the project.
Leading: Stakeholder actively engages to help the project succeed.
Your goal is to move stakeholders from the left (unaware, resistant) towards the right (supportive, leading). You plan specific communication actions, like monthly meetings for a disgruntled department head or a monthly newsletter for the wider organisation.
Then you manage stakeholder engagement——you actually communicate, negotiate, and address concerns. When a key stakeholder is unhappy, you meet with them, listen, and try to resolve the issue before it becomes a crisis. Finally, you monitor stakeholder engagement by tracking whether your actions are working. Are stakeholders becoming more supportive? Are new stakeholders emerging? You adjust your plan as the project evolves.
Identify Risks
You brainstorm with the team and review project documents to find all potential uncertain events that could affect the project. Each risk is written into a risk register with a description, cause, and potential effect.
Perform Qualitative Risk Analysis
You assess each risk's probability and impact using a simple scale (High, Medium, Low) to prioritise them. The most urgent risks (High probability, High impact) get immediate attention for further analysis or response planning.
Plan Risk Responses
For each high-priority risk, you decide on a strategy: avoid (change the plan), transfer (buy insurance or use a fixed-price contract), mitigate (reduce the probability or impact), or accept (do nothing proactively). You document this in the risk register.
Plan Procurement
You decide what to buy, when, and under what contract type. You write a procurement statement of work (SOW) that describes the product or service in enough detail for sellers to bid. You also choose between fixed-price, cost-reimbursable, or time and materials contracts.
Conduct Procurement
You send an RFP (Request for Proposal) to potential sellers, receive bids, evaluate them against pre-defined criteria, and award a contract to the best seller. This step includes negotiation and signing the legal agreement.
Monitor and Control Stakeholder Engagement
You track whether your communication and engagement actions are working by comparing actual stakeholder attitudes against the desired levels using the stakeholder engagement assessment matrix. If a stakeholder is still resistant, you adjust your approach.
Let's take a real scenario: a mid-sized company, 'GreenLeaf Energy', decides to build a new mobile app that lets customers see their solar panel energy production in real time. The project has a budget of £150,000 and a timeline of six months. The project manager, Priya, has to deliver this without any prior experience with mobile apps.
Risk Management in practice
Priya starts by holding a risk workshop with her team. They identify a major risk: the company's existing data system for solar panels is old and may not integrate well with the new app. The probability is assessed as High (70% chance) and the impact as High (it could delay the project by two months and blow the budget). Priya calls this Risk ID-001 and puts it in the risk register. She decides on a mitigate response: the team will build a mock integration early in the project to test the data flow, and if it fails, they will allocate £20,000 to buy a middleware tool that bridges the gap. They also identify an opportunity: if the integration works well, the company could sell the data stream to other solar installers. They label this as a positive risk and plan to pursue it by documenting the integration method and approaching a partner company.
By week three, a new risk emerges: the contractor designing the app's user interface leaves the company. Priya had identified a secondary risk that they might lose key personnel, so she already had a contract clause that requires the contractor to provide a qualified replacement within five working days. The risk response works; the new designer starts promptly.
Procurement Management in practice
Priya needs to buy a cloud service to host the app's backend. She writes a statement of work (SOW) specifying the required computing power, storage, and uptime guarantee of 99.9%. She sends an RFP to three cloud providers: AWS, Azure, and a smaller local provider. She evaluates the responses on price, experience with energy apps, and support hours. The local provider is cheaper but has little experience; AWS is more expensive but offers a dedicated account manager and proven uptime. Priya chooses AWS using a fixed-price contract where the total cost for the six-month project is agreed upfront. She also negotiates a penalty clause: if uptime falls below 99.9%, AWS must credit the company 10% of the monthly fee.
During the project, the development team asks to buy a third-party analytics library for £500 to speed up the app's reporting features. This is a small procurement, but Priya still follows the process: she checks the budget, gets three quotes from different analytics providers, and issues a purchase order. She tracks the delivery in her procurement tracking spreadsheet.
At the project end, Priya formally closes the AWS contract. She verifies that the final usage matches the invoice, ensures no outstanding payments, and files the contract and final invoice in the project archive. She also writes a note in the lessons learned: 'Avoid the local provider for future cloud projects—their support team was slow to respond during the RFP.'
Stakeholder Management in practice
Priya identifies the key stakeholders at the start. The CEO, Sarah, is a high-power, high-interest stakeholder because the app is part of the company's new green strategy. Sarah wants regular fortnightly 15-minute updates. The head of customer support, Mark, is also critical because his team will eventually field calls from users about the app. However, Mark is initially resistant because he thinks the app will increase his team's workload without any training budget.
Priya plans to manage Mark: she schedules weekly 20-minute chats to listen to his concerns. She then negotiates with the CEO to allocate £3,000 for training the support team on the new app. Mark becomes supportive after the training is confirmed. There is also a stakeholder group that is often forgotten: the company's data privacy officer, Emma. Emma is neutral but needs detailed information about how user data is stored. Priya sets up a monthly email update specifically for Emma, including a technical appendix on data encryption. By keeping Emma informed, Priya avoids a last-minute compliance audit that could halt the launch.
When the project is three months in, a new stakeholder appears: the marketing director, who has just joined the company and wants to delay the launch to coordinate with a press campaign. Priya adds her to the stakeholder register, assesses her influence as medium, and negotiates to have the launch date moved by only one week to align with marketing's plans without jeopardising the overall timeline.
The CAPM exam, based on the PMBOK Guide Sixth Edition, will test your recall of process names, inputs, tools and techniques, and outputs (ITTOs) for these three knowledge areas. But it also tests your ability to apply concepts in a scenario.
Question types you will see
Definition questions: 'What is a risk?'. Answer: 'An uncertain event that, if it occurs, has a positive or negative effect on a project objective.' The trap here is that some answers say 'a problem' or 'a negative event'——but risk includes positive opportunities.
Process order questions: 'Which process comes after Identify Risks?'. The correct sequence is: Plan Risk Management -> Identify Risks -> Perform Qualitative Risk Analysis -> Perform Quantitative Risk Analysis -> Plan Risk Responses -> Implement Risk Responses -> Monitor Risks. The exam loves to jumble the steps or insert a fake step like 'Evaluate Risks'.
Contract type scenarios: 'You need to buy a standard, well-defined software license. Which contract type is best?'. Answer: Fixed-price contract. The trap: they might describe a situation where scope is unclear (use cost-reimbursable) or the work is small and urgent (use time and materials).
Stakeholder classification: You will be given a stakeholder's power and interest (e.g., high power, low interest) and asked which engagement level or management approach is appropriate. High power/low interest stakeholders should be 'kept satisfied'——you communicate enough to keep them happy but not so much that you waste their time.
'What should you do next?' scenario questions: A vendor is late on delivery. What do you do? The correct answer is to consult the contract and follow the agreed remedy or penalty clause——not to immediately fire the vendor or call the CEO.
Common traps the exam sets
Confusing risk register with issue log: A risk is a future uncertain event; an issue is a problem that has already occurred. If the question says 'the server has crashed', that is an issue, not a risk. The register used for issues is the issue log.
Mixing up qualitative and quantitative risk analysis: Qualitative uses subjective ratings (High/Medium/Low); quantitative uses numbers and data (Monte Carlo simulation, sensitivity analysis). The exam will describe a technique and ask you to identify the process.
Stakeholder vs. team member: Not everyone involved in a project is a stakeholder. A stakeholder is anyone affected by the project. The development team is both a team member and a stakeholder, but a supplier's CFO is only a stakeholder.
Assuming 'avoid' means ignoring: Avoid is an active risk response——you change the project plan to eliminate the risk. It is not the same as 'accept'.
Key definitions to memorise
Risk appetite: The degree of uncertainty an organisation is willing to accept in pursuit of its goals.
Risk threshold: The level of risk exposure above which the organisation will not go.
Procurement statement of work (SOW): A description of the procurement item detailed enough to allow prospective sellers to determine if they can meet the requirements.
Bidder conference: A meeting with all prospective sellers held before the proposal due date to ensure a clear understanding of the procurement requirements.
Stakeholder engagement assessment matrix: A tool that compares the current engagement level of stakeholders against the desired engagement level.
What the exam does not test heavily
The exam does not ask you to memorise all ITTOs by heart, but they test your understanding of key outputs like the risk register, risk report, stakeholder register, and procurement documents.
It does not test finance or legal detail beyond contract types and basic negotiation.
Study strategy
Create a simple table for each knowledge area: list the process names in order, the key input (e.g., risk management plan), the key tool (e.g., root cause analysis for risk identification), and the key output (e.g., risk register). Quiz yourself daily. For scenario questions, always think: 'What is the formal process for this situation?' The exam rewards following the defined process, not what seems like common sense.
A risk is any uncertain event that could help or hurt the project; it is not the same as an issue, which has already happened.
The risk register captures identified risks, their probability, impact, and planned responses, and must be updated throughout the project.
Qualitative risk analysis uses subjective ratings (High, Medium, Low) to prioritise risks quickly, while quantitative risk analysis uses numbers and models.
Fixed-price contracts transfer cost risk to the seller; cost-reimbursable contracts leave cost risk with the buyer but offer flexibility for changing scope.
Stakeholder engagement aims to move individuals from being unaware or resistant towards being supportive or leading the project.
The power/interest grid is a key tool for classifying stakeholders: manage high-power/high-interest closely, keep high-power/low-interest satisfied, and keep low-power/high-interest informed.
Procurement does not end with a signed contract; controlling procurement includes monitoring vendor performance, managing changes, and closing the contract properly.
Risk responses for threats are avoid, transfer, mitigate, and accept; for opportunities they are exploit, share, enhance, and accept.
These come up on the exam all the time. Here's how to tell them apart.
Qualitative Risk Analysis
Uses subjective ratings (High, Medium, Low) for probability and impact
Fast and inexpensive to perform on all projects
Outputs a list of prioritised risks
Quantitative Risk Analysis
Uses numerical data and models (Monte Carlo simulation, sensitivity analysis)
Time-consuming and resource-intensive, typically used on large projects
Outputs probabilistic estimates of schedule and cost
Fixed-Price Contract
Price is agreed upon upfront and does not change
Seller bears the risk of cost overruns
Best for well-defined scope with clear requirements
Cost-Reimbursable Contract
Buyer pays actual costs plus a fee
Buyer bears the risk of cost overruns
Best for poorly defined scope or research projects
Risk Register
Captures uncertain future events that may or may not occur
Includes probability, impact, and planned responses
Updated prospectively as new risks emerge
Issue Log
Captures problems that have already occurred
Includes ownership, resolution date, and corrective actions
Updated to track resolution progress
Keep Satisfied (Stakeholder)
Stakeholder has high power but low interest
Communicate enough to avoid surprises but not more than necessary
Focus on one-way updates (reports, briefings)
Manage Closely (Stakeholder)
Stakeholder has high power and high interest
Engage actively and frequently (meetings, workshops)
Focus on two-way communication and joint decision-making
Mistake
Risk management is only about avoiding bad things.
Correct
Risk management also covers positive risks (opportunities), which you should pursue or enhance, not avoid.
The word 'risk' has a negative connotation in everyday language, so beginners naturally assume it only means threats, not opportunities.
Mistake
Procurement is just buying things; it ends when the contract is signed.
Correct
Procurement includes planning, conducting, controlling, and closing the contract——signing is just one step. Much of the work happens after to make sure the vendor delivers.
People focus on the dramatic 'awarding a contract' part and forget the tedious but vital monitoring and closing steps.
Mistake
Stakeholder management means keeping everyone happy all the time.
Correct
Stakeholder management is about understanding and managing expectations, not necessarily pleasing everyone. You may have to make unpopular decisions as long as you communicate and justify them.
The word 'management' sounds like a customer service role. In reality, it involves negotiation, conflict resolution, and sometimes saying no.
Mistake
If you identify all risks at the start of the project, you are done with risk management.
Correct
Risk management is an ongoing process that continues throughout the project. New risks will emerge, and old risks may change in probability or impact.
People treat risk management like a checklist they can complete in one meeting, but it is a continuous activity because the project environment evolves.
Mistake
A fixed-price contract is always the best choice because it transfers all risk to the seller.
Correct
A fixed-price contract transfers cost risk to the seller, but it can lead to higher prices because sellers add contingency. It is only best when the scope is well-defined. For unclear scope, cost-reimbursable is safer despite the buyer bearing cost risk.
Beginners see 'fixed price' and think 'certainty', but they do not consider that sellers price in their own risk assessment, often making it more expensive.
Mistake
The project manager should handle all stakeholder communication personally.
Correct
The project manager plans and directs stakeholder communication, but much of the actual communication is delegated to team members, sponsors, or specific subject matter experts.
Beginners think the PM must be the single point of contact, which is unrealistic in large projects. The PM is the manager of the communication, not the sole communicator.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A risk is an uncertain event that may happen in the future; an issue is a problem that has already occurred. Risks are logged in a risk register; issues go into an issue log.
No. Qualitative analysis is performed on all projects as a quick prioritisation step. Quantitative analysis is used only on large, complex projects where the data and time allow for numerical modelling, or when the risk warrants deeper analysis.
You refer to the contract's terms, which should specify remedies such as penalty clauses, the right to terminate, or required notification periods. You then follow that agreed process——not an emotional reaction.
Use a power/interest grid. Stakeholders with high power and high interest you manage closely. Those with high power but low interest you keep satisfied. Those with low power but high interest you keep informed. The rest you just monitor.
No. The project manager plans and directs the communication strategy, but actual communication may be delegated to team members, the sponsor, or other subject matter experts depending on the message and audience.
A bidder conference is a meeting held with all prospective sellers before proposals are due. Its purpose is to ensure everyone has a consistent understanding of the procurement requirements and to answer any questions publicly.
You've finished Risk, Procurement, and Stakeholder Management. Continue through the CAPM study guide to build a complete picture of the exam.
Done with this chapter?