What is project risk management?
Project risk management is the systematic process of identifying, assessing, prioritising, and responding to potential threats and opportunities that could affect a project's objectives. A well-run risk management process doesn't eliminate uncertainty — no process can. It ensures that the project team is never surprised by something they could have anticipated, and never unprepared for something they did anticipate.
Traditional risk management frameworks — PMI's PMBOK, PRINCE2, ISO 31000 — provide rigorous methodologies for cataloguing, scoring, and responding to risk. They are structured around identifying what might go wrong, assessing the probability and impact of each risk, and planning specific responses. This is necessary, useful work.
But as Henning Christiansen argues in Project Management: The Red Pill, it covers only the hard risks — the technical, logistical, and financial threats that appear in risk registers and Gantt charts. There is a second category of risk that most frameworks barely acknowledge: the soft risks that come from human nature, political dynamics, and the social games that run beneath the surface of every project.
Bugs, issues, and risks: why the distinction matters
Not all problems are the same kind of problem, and treating them the same way is one of the most common sources of wasted effort in project management. Christiansen draws a sharp distinction between three categories that too many teams conflate:
The distinction is not semantic. A bug needs a fix. An issue needs immediate resolution and transparent communication. A risk needs a documented response plan — before it becomes an issue. Mixing these categories leads to wasted effort on the wrong type of response and, critically, to the delays and political chaos that occur when problems are escalated with the wrong framing.
Hard risks and soft risks: the two dimensions of project risk
Christiansen's most important contribution to risk management thinking is his insistence that problem-solving must operate on two tracks simultaneously — what he calls hardcore problem-solving and softcore stakeholder management. Both are equally important. Neglecting either one creates a different kind of failure.
Hard risks — the technical dimension
Hard risks are the ones that live in risk registers: schedule slippage, budget overrun, technical dependencies, vendor failures, resource unavailability, regulatory changes, infrastructure failures. These are managed through structured, process-driven approaches — risk identification workshops, probability/impact matrices, response planning, contingency budgets, and regular review cycles.
Soft risks — the human dimension
Soft risks are the ones most frameworks barely mention. They include political maneuvering, blame-shifting, hidden agendas, stakeholder resistance, and the deliberate exploitation of problems by individuals looking to advance their personal interests. Christiansen is explicit: when problems arise, Chameleons and Roosters find favourable conditions to engage in Monkey Poker. Problems become opportunities for individuals to shift blame, gain visibility, or undermine others for personal gain.
"Bugs, issues, and risks are opportunities for Chameleons and Roosters to play Monkey Poker. The project manager is not just solving technical or logistical problems. The manager must also be alert to soft risks like political manoeuvring, blame-shifting, and hidden agendas."
— Henning Christiansen, Project Management: The Red Pill
When Chameleons or Roosters want to force a change they know won't pass formal review, they artificially escalate urgency — creating a false sense of crisis that pressures the team into acceptance. "We're going to lose the client." "This violates industry standards." The project manager's defence is clear: validate the claim with facts. If the platform isn't actually burning, demonstrating that stability destroys the move and damages the attacker's credibility.
Step 1 — Risk identification
Risk identification is the foundation of the entire risk management process. A risk that isn't identified can't be managed. The goal is to surface every plausible threat — technical, financial, organisational, external, and human — before the project starts.
Step 2 — Risk assessment: the probability/impact matrix
Once risks are identified, they need to be assessed: how likely is each risk to occur, and how severe would the impact be? The standard tool for this is the probability/impact matrix — a 5×5 or simplified 3×3 grid that scores each risk and determines its priority level.
| Probability ↓ / Impact → | Low impact | Medium impact | High impact | Critical impact |
|---|---|---|---|---|
| High probability | Medium | High | Critical | Critical |
| Medium probability | Low | Medium | High | Critical |
| Low probability | Low | Low | Medium | High |
The matrix gives you a triage system: Critical and High risks need active response plans and regular review. Medium risks need monitoring and contingency thinking. Low risks are documented and watched but don't require dedicated response planning unless their status changes.
Political and stakeholder risks are real risks and should be scored on the same matrix. A Chameleon in a senior position who has already shown signs of using the project as a career vehicle is a high-probability, potentially high-impact risk. Leaving it off the register doesn't make it less real — it just leaves you unprepared when it materialises.
The risk register: your single source of truth
A risk register is the living document that captures every identified risk, its assessment, its owner, and the planned response. It is not a one-time output — it is updated throughout the project lifecycle as new risks emerge, existing risks change in probability or impact, and planned responses are executed or revised.
| # | Risk description | Category | Probability | Impact | Priority | Owner | Response |
|---|---|---|---|---|---|---|---|
| R-01 | Key vendor delivers API integration 3+ weeks late | Technical | Medium | High | High | PM | Parallel track with fallback vendor identified |
| R-02 | Senior stakeholder (Chameleon profile) pushes scope additions during delivery phase | Political | High | Medium | High | PM | MoSCoW scope locked; change request process enforced; credit-sharing strategy active |
| R-03 | Lead developer leaves before feature completion | Resource | Low | Critical | High | Tech Lead | Knowledge documented; pair programming on critical modules |
| R-04 | Regulatory approval takes longer than 6 weeks | External | Medium | Medium | Medium | PM | Submit 8 weeks early; identify parallel workstreams not blocked by approval |
| R-05 | Infrastructure costs 20% above estimate due to scaling needs | Financial | Low | Medium | Low | Finance lead | Contingency reserved; reviewed at phase gate |
Every risk in the register should have a clearly assigned owner — the person responsible for monitoring the risk and executing the response if it materialises. The project manager owns the register itself and the overall risk management process. Individual risks are owned by the person best positioned to detect early warning signs and execute the response.
FMEA and analytical risk tools
For projects with complex technical components, structured analytical methods add rigour to risk identification and assessment. FMEA (Failure Modes and Effects Analysis) is one of the most widely used.
Other useful analytical methods include Fault Tree Analysis (working backwards from a failure to its root causes), the 5 Whys (iterative root cause analysis), the Fishbone Diagram (cause-and-effect mapping), and DRBFM (Design Review Based on Failure Mode — useful when a change introduces new risk into a previously stable system).
Step 3 — Risk response strategies
Identifying and assessing a risk without planning a response is administrative theatre. Every risk above the "monitor" threshold needs an explicit, documented response strategy. There are four standard approaches:
Case study: Heathrow Terminal 5 — when the hard risk succeeds and the soft risk is ignored
Heathrow Terminal 5 opening day (2008)
Heathrow Terminal 5 is one of the most instructive risk management cases in modern project history — precisely because it succeeded on the hard metrics and failed catastrophically on the soft ones.
The terminal was delivered on time and within budget. The construction was flawless. Every hard metric was hit. But the project team severely underestimated the complexity of getting the terminal operational — particularly staff readiness and the integration testing of the automated baggage handling system.
On opening day, the system failed almost immediately. Staff were unfamiliar with the layout. The baggage system experienced glitches that caused over 42,000 bags to go missing and hundreds of flights to be cancelled in the first days. The damage to British Airways' reputation cost far more than any construction overrun could have.
The lesson Christiansen draws: flawless construction means little if operational systems and end-user readiness are not treated as risks. The soft risks — human readiness, process integration, real-world testing — were not in the risk register, so no one responded to them.
- Operational readiness was treated as an implementation task, not a risk domain
- Staff training was not tested under realistic load conditions before go-live
- The baggage system had never been run at full scale before opening day
- No hard risk framework can catch what it hasn't been asked to look for
Step 4 — Ongoing monitoring and control
Risk management is not a planning-phase activity. It is a continuous discipline that runs for the entire project lifecycle. Risks that were low probability at the start may become high probability as the project progresses. New risks emerge as scope evolves, team dynamics shift, or the external environment changes.
The project manager's monitoring responsibilities include: reviewing the risk register at every milestone and phase gate, updating probability and impact scores as information changes, tracking early warning indicators for high-priority risks, and escalating promptly when a risk materialises or its status changes significantly.
Christiansen's priority framework is clear: external stakeholder noise creates more disruption than internal uncertainty. When problems arise, the project manager's first priority is to stabilise the external environment — managing stakeholder expectations, client concerns, and visible outputs. Internal challenges can usually be addressed more effectively once external pressures are contained.
Early warning indicators
For each high-priority risk, document specific observable indicators that would signal the risk is becoming more likely. These might include: a vendor missing an intermediate milestone, a stakeholder becoming unresponsive to update requests, a technical test producing unexpected results, or a budget line trending above its threshold. Monitoring indicators is far more effective than waiting for a risk to fully materialise before responding.
Managing soft risks: the political dimension
When a problem materialises — whether a bug, an issue, or a risk event — it creates conditions that political actors within the project will immediately try to exploit. The project manager's response must operate on two tracks simultaneously.
Track 1: Hardcore problem-solving
Identify which parts of the project model are affected. Assess the scope of the problem — what is it, what are the effects, how can it be resolved. Communicate the status and scope clearly to the team. Focus technical resources on resolution without external interference.
- Determine the affected models and sub-models immediately
- Use FMEA, 5 Whys, or Fault Tree Analysis to understand root cause
- Define the resolution clearly before communicating externally
- Give the team space to solve the problem without stakeholder pressure
Track 2: Softcore stakeholder management
If the problem can be resolved without impacting external stakeholders, manage it internally and say nothing externally. If it cannot, communicate proactively before stakeholders receive information through informal channels. Transparency before they hear it elsewhere builds trust; being informed second destroys it.
- Identify which stakeholders have a vested interest in the affected components
- Communicate proactively to affected stakeholders before the rumour mill does
- Address Chameleon and Rooster escalation tactics with facts, not defensiveness
- Keep the Monkey King informed and framing aligned with their interests
- Maintain scope freeze during problem-solving — no new requirements until the current problem is resolved
Risk and scope creep: the connection most frameworks miss
Scope creep — the gradual, uncontrolled expansion of project requirements — is itself a risk, and one that compounds every other risk on the register. But it has a specific mechanism that Christiansen identifies clearly: it intensifies precisely when projects are under stress.
When a risk materialises and creates pressure — schedule slippage, budget variance, a client concern — Chameleons use the distraction to push additional features through under the banner of "client satisfaction". Roosters use the disruption as cover to work on technically interesting enhancements that have nothing to do with the core issue. The formal change control process is bypassed because "this is an emergency" and there's no time for paperwork.
Maintain strict control over project scope during problem-solving phases. Resist any new features or requirements until the current problem is fully resolved. Every addition during a crisis increases the number of variables in an already unstable system — and dramatically reduces the likelihood of a clean resolution.
Risk management in Proglar
Proglar's project management system supports the two-track risk management discipline described throughout this article. The project model structure makes risk cascade analysis immediate: when any component is flagged, the system shows which dependent tasks and models are potentially affected. The risk register is integrated with the project model, so every risk is connected to the specific tasks and milestones it threatens.
Time tracking data feeds risk monitoring: when actual hours on a task consistently exceed estimates, the system surfaces that as an early warning indicator. Change requests are managed within a formal process that maintains scope integrity — preventing the bypass tactics that Chameleons and Roosters favour under pressure.
Risk management built into every project
Proglar connects your risk register to your project model, your time tracking, and your change request process — so every risk is monitored in context, not in isolation. Try free for 30 days.