# 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. - Course: [Project Management Without the Bureaucracy: Run One Project from Brief to Closure](https://productovi.com/courses/project-management-without-bureaucracy.md) - Module: Risk and quality - Lesson 21/32, ~23 min - Source: https://productovi.com/courses/project-management-without-bureaucracy/what-is-a-risk ## Where we are **Alex Tutor:** Let's step back to early December at Klasna, three weeks before the status and the sponsor's new ideas from the last module. The brief is signed, the deliverables and the schedule to 1 February are set, and Leo gets your written status every Wednesday. **Alex Tutor:** This module is about what could still break the opening, and how to build quality into the work instead of hoping for it. **Leo:** Before the holidays I want to know what could stop us on 1 February. Collect everyone's risks and send me the list. **Danylo:** Mine is easy: booking by subject shows the physics tutors under math. And Leo still hasn't approved the package prices. **Sofia:** Wait, both of those are already true. Are they risks? **Alex Tutor:** No. A **project risk** is a possible future event: it may happen or not. An **issue** is already happening. Danylo has sent two issues. **Alex Tutor:** Two more kinds hide in such lists. An **assumption** is something the plan relies on but nobody has checked. A **dependency** is something you wait for from someone else. > **Exercise:** Match each line from the team's list to what it really is. ## Why the label matters **Vira:** Does the label matter? If it's on the list, someone will see it. **Alex Tutor:** Each kind needs a different action. An issue needs an owner and a fix this week. Give it a probability and it waits politely among the risks. **Alex Tutor:** An assumption needs a check with a date. A dependency needs a named supplier and a date in the plan. A risk needs a probability, an impact, an owner and a response. **Danylo:** So my wrong listing goes to me, today, not to a risk meeting in two weeks. **Alex Tutor:** Exactly. And when an assumption's check fails, it becomes an issue. Labels change as the project moves; sorting is a weekly habit, not a one-off. > **Exercise:** Danylo's line "Leo hasn't approved the physics package prices yet" sits in the risk list with probability "likely". What should you do with it? **Alex Tutor:** Labels don't stay put. Try this one. > **Exercise:** The plan assumes about 15 learners per tutor, checked by confirmed weekly slots from each tutor by 10 January. On 10 January the slots cover only 10 learners per tutor. What is this line now? ## Cause, event, consequence **Leo:** Here's mine for the list: "Something may go wrong with the platform." **Alex Tutor:** That's a worry, not a risk anyone can act on. Write a risk in three parts: the **cause** you can see today, the **event** that may happen, the **consequence** for the project. **Vira:** Try mine: "Because I also teach the January intensive, my final review may slip past 15 December, so tutors would prepare demo lessons on draft material." **Alex Tutor:** Good. The cause tells you where to look, the event is what to watch for, and the consequence says why Leo should care. **Danylo:** Then Leo's one becomes: "Because the checkout is new code from a contractor with other clients, his release may come late, so the provider's review and our tests get squeezed." **Alex Tutor:** Put the three parts of Vira's risk in order. > **Exercise:** Put the parts of Vira's risk statement in the order of cause, event, consequence. > **Exercise:** Which line is a well-written risk? ## The risks nobody writes down **Sofia:** Roman told us strong candidates teach at school, so they're free only evenings and weekends. Is that a risk? **Alex Tutor:** That part is a known limit you plan around. The risk is what may follow: in February most families also want evening slots, so the evening hours may fill up and learners wait or leave. **Vira:** And winter evenings mean power outages and air-raid alerts. A lesson cut in the middle twice in a row, and a family gives up. **Alex Tutor:** People skip those because they feel like normal life. For a project of live evening lessons they are ordinary planning inputs: write them down like any other risk. > **Exercise:** **True or false:** outages and air-raid alerts happen every winter, so they don't belong in the physics launch's risk list. ## Forty items, mostly problems **Danylo:** By Friday the shared list has forty lines. Nobody's name is next to any of them. **Alex Tutor:** A list like that looks thorough and protects nothing. Most lines are issues and wishes; the real risks drown, and some are missing. **Alex Tutor:** Sort first. Issues go to an issue list with an owner each. Assumptions go back into the brief with a check date. Dependencies go into the schedule. What stays are risks. **Sofia:** And then I rewrite each risk as cause, event, consequence, and add the ones nobody wrote. > **Exercise:** Which of these lines from the list are **risks**? Select all that apply. **Alex Tutor:** Last: forty lines, no owners. Where do you start? > **Exercise:** By Friday the shared list has 40 lines and no owner next to any of them. What do you do first? ## Your turn: one risk, written properly **Leo:** Roman's line in the list just says "Tutors might be a problem." Fix it so I know what to worry about. **Alex Tutor:** Use what you know: candidates teach at school by day, families want evening slots, winter evenings bring outages and alerts. **Sofia:** Cause I can see today, event with a date, consequence for the opening or the 120 learners. **Vira:** One risk, done well, is worth more than five vague ones. > **Exercise:** Rewrite Roman's line "Tutors might be a problem" as **one risk** in the form cause, event, consequence. Roman runs tutor operations. What you know: strong candidates teach at school by day, so they are free only in the evenings and at weekends; in February most families also want evening slots; winter evenings bring power outages and air-raid alerts. The project aims to open on 1 February and reach 120 learners. > **Key points** > > - A **risk** is a possible future event; an **issue** is already happening; an **assumption** is relied on but unchecked; a **dependency** is work you wait for from someone else. > - Each kind needs a different action: an issue gets an owner and a fix this week, an assumption a check with a date, a dependency a date in the plan, a risk a probability, impact, owner and response. > - Write a risk as **cause → event → consequence**. > - Outages, alerts and evening-only tutors are ordinary planning inputs: write them down. > - A long list of mostly problems hides the real risks. Sort it before you score anything. **Alex Tutor:** Next: the short register. How likely, how much it costs in days or money, and who watches each risk. - Previous lesson: [Case: the sponsor changes priorities every week](https://productovi.com/courses/project-management-without-bureaucracy/sponsor-changes-priorities-case.md) - Next lesson: [A short risk register people actually use](https://productovi.com/courses/project-management-without-bureaucracy/a-short-register.md) --- Productovi Learning. Free, no sign-up needed to read.