project risk
Also called: risk statement, cause, event, consequence
An uncertain event that, if it happens, changes the project's date, cost or result. Written as cause, event and consequence ("because…, … may happen, which would…"), it becomes specific enough to own and act on.
A project risk is something that may or may not happen and would change the project's date, cost or result if it did. The word that matters is may: a risk lives in the future and has a probability below 100 %. That is what separates it from three neighbours it is often mixed up with on a team's list. An issue is already happening and needs an owner and a fix now. An assumption is something the plan relies on but nobody has checked yet. A dependency is work you are waiting for from someone else.
The label decides the action. An issue that sits on a risk list with a probability attached waits politely for the next review while it does damage. An assumption needs a check with a date; when the check fails, it becomes an issue. A dependency needs a named supplier and a date in the schedule. Only real risks need the full treatment: probability, impact, an owner and a response.
To be useful, a risk has to be specific enough to watch. A reliable form is cause → event → consequence: "Because [something you can see today], [an event] may happen, so [what it does to the date, cost or result]." The cause tells you where to look, the event tells you what to watch for, and the consequence tells the sponsor why it matters. "Something may go wrong with the platform" fails all three tests; it is a worry, not a risk.
Risks are not only bad news. An uncertain event that would help the project (an opportunity) belongs in the same list and gets the same thinking. And everyday conditions are not exempt: if the project depends on live evening sessions, power outages or internet cuts in the evening are ordinary planning inputs, not background noise.
Example
In early December the team of Klasna's physics launch (opening on 1 February 2027) is asked for "the risks" and returns a list of 40 lines. Sorted by kind:
So only 9 of 40 lines (9 ÷ 40 = 22.5 %) are risks, and one of those, "Something may go wrong with the platform", is too vague to act on. "Booking by subject shows the physics tutors under math" is already true, so it is an issue; "each tutor can take about 15 new learners" is an assumption; "demo lessons wait for the final curriculum" is a dependency.
A well-formed risk from the same list: "Because Vira also teaches the January intensive, her final curriculum review may slip past 15 December, so tutors would prepare demo lessons on draft material." Two real risks were missing entirely: evening outages and air-raid alerts cutting live lessons, and tutors who are free only in the evenings (they teach at school by day) just when families want evening slots.
Common mistakes
- Logging issues as risks. If it is already true, it needs an owner and a fix this week, not a probability.
- Writing worries instead of risks. "The platform may be a problem" names no cause, no event and no consequence, so nobody can watch it.
- Leaving out everyday conditions. Outages, connectivity, holidays and people's other jobs feel like normal life, and that is exactly why they go unwritten.
- Sorting once. Labels change as the project moves: a failed assumption becomes an issue, a passed date closes a risk. Re-sort weekly.
- Ignoring opportunities. Uncertain events that would help deserve owners and actions too.
Learn it in the course
- Risk, issue, assumption or dependency? · Tell a risk from a problem that is already happening, an unchecked assumption and work you are waiting for, and write each risk as cause, event and consequence.
- Case: the launch risk register · Take the team's raw forty-line list, sort out the issues, assumptions and dependencies, score the real risks in days or money, add the missing ones, and send Leo the top five with owners, responses and triggers.