Feasibility & Cost-Benefit Analysis

Risk Assessment

18 min Lesson 7 of 10

Risk Assessment

No project is risk-free. A clinic deploying a new booking system faces the risk that staff will resist the change. An online store migrating to a new payment gateway faces the risk of transaction failures during cutover. A logistics firm building a real-time tracking platform faces the risk that the third-party carrier API they depend on will be unreliable. The question is never whether risks exist — it is whether the project team has identified, scored, and planned responses for them before those risks become expensive problems.

Risk assessment is the structured process of surfacing what could go wrong, quantifying how likely and how harmful each risk is, and designing specific responses so the project remains on track. In feasibility analysis, risk assessment belongs in every study before a funding decision is made — a project sponsor deserves to know not just what the system will cost, but what unexpected costs they might face.

Step 1 — Risk Identification

Risk identification is a creative and systematic activity. The goal is to produce a comprehensive risk register — a living document that catalogues every known risk. Useful identification techniques include:

Brainstorming sessions with the project team and key stakeholders. Ask "What could go wrong?" across scope, schedule, budget, technology, people, and external factors.
Checklists and templates from previous similar projects. Most organisations that have delivered two or three IT projects accumulate a recurring set of risks worth tracking from day one.
Expert interviews — a data-migration risk that seems abstract to a business analyst may be obvious to a database administrator who has done twelve migrations.
Assumption analysis — every assumption the project plan makes is a potential risk. If the plan assumes that vendor X will deliver the API by March, the risk is that they do not.
SWOT analysis cross-reference — Threats from a SWOT exercise are directly reusable as project risks.

For the clinic booking system, a brainstorm might surface: staff resistance to change, data migration from the legacy paper register, integration delays with the laboratory information system, scope creep from clinicians requesting extra features, and the lead developer leaving mid-project.

Step 2 — Scoring Risks: Probability and Impact

Identifying fifty risks is only useful if you know which ones deserve the most attention. Scoring uses two dimensions:

Probability (Likelihood) — How likely is it that this risk materialises? Scored 1 (rare) to 5 (near-certain), or using percentage bands: <10 %, 10–30 %, 30–60 %, 60–80 %, >80 %.
Impact (Consequence) — If the risk materialises, how severe is the damage? Scored 1 (negligible) to 5 (critical), measured in cost overrun, schedule delay, or reputational harm.

Multiplying the two scores gives a Risk Score (also called the Risk Exposure or Priority Number). A risk with Probability 4 and Impact 5 scores 20 — a red-zone risk demanding immediate planning. A risk with Probability 1 and Impact 2 scores 2 — acceptable to monitor without active intervention.

Key idea — Risk Score = Probability × Impact. This single number lets you rank risks objectively and allocate mitigation effort proportionally. Scores 1–4 are low (green), 5–9 are medium (amber), 10–25 are high (red). These bands are conventions — adapt the thresholds to your organisation's risk appetite.

The Probability/Impact Matrix

The most widely used visual tool in risk management is the probability/impact matrix (also called a risk heat map). Risks are plotted on a grid: the horizontal axis represents probability; the vertical axis represents impact. The resulting colour zones — green, amber, red — tell the project team at a glance where to focus energy.

Probability/impact matrix for the clinic booking project. R1 (staff resistance) and R2 (data migration) are red-zone priorities; R3 (scope creep) and R4 (key developer leaving) are amber; R5 (API delays) is green.

Step 3 — Risk Responses

Plotting risks on the matrix is not the end — it is the beginning of planning. For each risk, the team must agree on a response strategy. There are four standard strategies:

Avoid — eliminate the risk entirely by changing the plan. If integrating a third-party API creates high delivery risk, consider building the integration in a later release so the core system can go live without it.
Mitigate (Reduce) — take actions to lower the probability, the impact, or both. To mitigate staff resistance, run a series of workshops and appoint a clinic champion who trains colleagues and advocates for the system.
Transfer — shift the financial consequences to another party. Contracts with fixed penalties for late delivery transfer delay risk to the vendor. Cyber-insurance transfers some of the financial impact of a data breach.
Accept — acknowledge the risk and prepare a contingency plan, but take no proactive action. Appropriate for low-scoring risks where the cost of mitigation exceeds the expected loss.

Best practice — assign a Risk Owner. Every risk in the register should have one named person responsible for monitoring it and triggering the response plan if it materialises. Without ownership, risks are reviewed in meetings and then forgotten.

The Risk Register in Practice

The risk register is the central artefact. A minimal register for the clinic booking system might look like this:

R1 — Staff resistance to system change | Probability: 4 | Impact: 4 | Score: 16 | Response: Mitigate — run four half-day training workshops; appoint a clinic champion in each department. Owner: Operations Manager.
R2 — Data migration corruption or loss | Probability: 3 | Impact: 5 | Score: 15 | Response: Mitigate — perform three parallel migration dry-runs in staging; maintain the paper register as a fallback for the first 30 days. Owner: Lead Developer.
R3 — Scope creep from clinician feature requests | Probability: 4 | Impact: 3 | Score: 12 | Response: Avoid — institute a formal change-control board; any new feature request requires written approval from the steering committee. Owner: Project Manager.
R4 — Key developer departing mid-project | Probability: 2 | Impact: 4 | Score: 8 | Response: Mitigate — enforce pair programming and weekly knowledge-sharing sessions so no single developer holds critical knowledge. Owner: IT Director.
R5 — Integration API delayed by third-party vendor | Probability: 2 | Impact: 2 | Score: 4 | Response: Accept — monitor the vendor's roadmap; if delay exceeds two weeks, escalate to the steering committee. Owner: Business Analyst.

Residual and Secondary Risks

After a mitigation plan is in place, the residual risk is the risk that remains. If the migration dry-runs reduce the probability of data corruption from 3 to 1, the residual score falls from 15 to 5. This post-mitigation score should also be recorded, because it tells stakeholders what level of risk they are actually accepting when they approve the project.

Responses can also generate secondary risks — new risks created by the mitigation itself. Pair programming reduces key-person risk, but it increases team capacity by roughly 20 %, which could affect the schedule. Record secondary risks in the register as their own entries.

Risk Assessment in the Feasibility Report

The feasibility report (lesson 9) includes a dedicated risk section. Reviewers expect to see three things: the prioritised risk register, the post-mitigation residual scores, and a clear statement of the overall risk profile — typically expressed as High / Medium / Low for the project as a whole. A project with two red-zone risks that cannot be mitigated below amber should be accompanied by an honest recommendation: either delay until conditions improve, reduce scope, or increase the contingency budget.

The risk response cycle — identification, scoring, response planning, ownership, and ongoing monitoring — repeats throughout the project.

Common pitfall — treating the risk register as a one-time deliverable. The register is only useful if it is reviewed at every project status meeting and updated whenever circumstances change. A risk that was amber in month one can become red in month three if an assumption turns out to be wrong. Static risk registers give false confidence.

Summary

Risk identification uses brainstorming, checklists, expert interviews, and assumption analysis to populate a risk register.
Risk scoring multiplies Probability (1–5) by Impact (1–5) to produce a priority number; the probability/impact matrix visualises the risk profile.
Risk responses fall into four strategies: Avoid, Mitigate, Transfer, Accept. Every risk must have a named owner.
Residual and secondary risks must be documented after responses are planned.
The feasibility report presents the post-mitigation risk profile so decision-makers can approve the project with open eyes.