Risk Analysis for a Project

AA risk is an uncertain event that would affect what the project is trying to achieve. Projects rarely fail because of one risk that was never considered. They fail because a few foreseeable risks were left unmanaged until they arrived together. A short, structured analysis at the start, reviewed at each milestone, catches most of them while they are still cheap to handle.cheap to handle now, expensive later

This page sets out a simple process for risk analysis, a register that records it, and some common risks for student projects. It draws on the standard for risk management and on an early account of software risk management, both listed in the references.

The Process

TheThe international standard ISO 31000 describes risk management as a cycle of identifying, analysing, evaluating, treating, monitoring, and communicating risks^[1]. The standard is written for organisations, but the cycle applies to a project of any size. It is useful to think of it in three stages:

1. Identify and analyse. List what could go wrong, estimate how likely it is, and how much it would matter if it happened.
2. Plan responses. Decide what you will do about each risk that matters: reduce it, avoid it, accept it, or prepare a fallback for it.
3. Monitor. Check the risks at every milestone and update the register.

An early account of software risk management describes the same structure as two steps: risk assessment, which identifies, analyses, and prioritises risks, and risk control, which plans, resolves, and monitors them^[2]. The emphasis on prioritising is the important part. A long list of risks treated equally is not a plan.prioritise by impact, not just likelihood

The Risk Register

AA risk register is a table with one row per risk. It needs a small number of columns, and each one should be filled in:

ID	Risk	Likelihood (1–5)	Impact (1–5)	Priority	Response	Trigger to check	Owner
R-01	Dataset access is delayed beyond week 4	3	5	15	Request access now; prepare a public dataset as a fallback	No written confirmation by week 3	Student
R-02	Core library is abandoned or breaks on a new version	2	4	8	Pin the version; record a tested alternative	Failing build after dependency update	Student
R-03	Evaluation phase is underestimated	4	3	12	Estimate from a pilot run; add two weeks of slack	Pilot takes more than twice the estimate	Student

Priority is likelihood multiplied by impact. It is a rough ordering rather than a measurement, and its purpose is to decide which risks get attention first. The register in Risk Register Template follows this structure and can be adapted directly.

The trigger column is the one most often left blank, and it is the most useful. A trigger is an observable sign that a risk is becoming real. Once it is defined, you know when to act, and the risk stops being a worry and becomes a checkable event.it is not a probability. it is a signal.

Responses

ThereThere are four common responses to a risk:

• Reduce. Take action that lowers the likelihood or the impact. Requesting data early reduces the chance it arrives late.
• Avoid. Change the plan so the risk no longer applies. Choosing a dataset you already have avoids the access risk altogether.
• Accept. Decide the risk is tolerable and record that decision. This is reasonable for low-priority risks, provided the decision is written down.
• Prepare a fallback. Decide in advance what you will do if the risk happens. This is the response for risks that cannot be reduced, such as a supervisor being unavailable for a period.

A response that is only "keep an eye on it" is not a response. It is a note that the risk exists.

Common Risks in Student Projects

MostMost student projects meet a similar set of risks. The list below is a checklist to adapt, not a complete inventory:

• Data or access arrives later than planned, or in a different form than expected.
• Tools, libraries, or platforms change or stop working during the project.
• An evaluation takes longer than the build, because it needs participants, careful measurement, or repeated runs.
• Assessment deadlines in other modules coincide with the critical path.
• The question turns out to have been answered already, which changes the contribution.
• A dependency on a single person, such as a supervisor, client, or participant group, with no alternative.
• Illness or other personal circumstances removing a large block of time.

The last item deserves a fallback in the plan, not an apology after the fact. Most universities have a route for extenuating circumstances, and knowing how it works before you need it is part of the risk response.

Ethical and data-protection risks also belong on the register, particularly where the project involves people or personal data. They are covered in Ethics, Security, Sustainability, and Professional Conduct.GDPR isn't just legalese; it's design.

Reviewing the Register

ReviewReview the register at each milestone. Check whether any trigger has fired, whether any likelihood or impact has changed, and whether a new risk has appeared. The most useful question is "what has changed since last time?" rather than "what are the risks?" A short review each time is more likely to happen than a long one at the end.

The register is also evidence. A project that records a risk, the response, and the outcome shows that its decisions were made deliberately. That record belongs in the evaluation, as part of the account of how the project was run. The discovery log described in Project Navigation and the Art of Triangulation is a good place to record each decision as it is made.

Related Topics

• Planning, Milestones, and Time — the schedule the risks threaten.
• Scope, Feasibility, and Defining Success — the feasibility check that should reveal the first risks.
• Risk Management — risk in software engineering more broadly.
• Risk Burn-down Chart Template — tracking risk exposure over time.
• Risk Management: Lessons from Testing Real Systems — a worked example of a risk that became real.

References

1. ISO. (2018). ISO 31000:2018 Risk management: Guidelines. International Organization for Standardization. https://www.iso.org/standard/65694.html
2. Boehm, B. W. (1991). Software risk management: Principles and practices. IEEE Software, 8(1), 32–41.