Risk, issue, assumption or dependency?

Ask a team for "the risks" and you get four different things mixed together. Telling them apart is the first step.

• A risk is a possible future event: it may happen or not. A vetted tutor may leave in January for a school job.
• An issue is already happening. Booking by subject shows the physics tutors under math today.
• An assumption is something the plan relies on but nobody has checked: each tutor will take about 15 learners.
• A dependency is something you wait for from someone else: the demo lessons can't start before Vira finishes the program.

The test is simple. Is it true already? Issue. Is it a belief the plan stands on? Assumption. Is it work you're waiting for? Dependency. Is it an event that may or may not happen, with a consequence? Only then is it a risk.

The label matters because 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 for a meeting that may be weeks away.

Danylo's line "Leo hasn't approved the physics package prices yet" sits in the risk list as "likely". But the approval is already missing: it's an issue. Move it to the issues, name an owner and an action with a date, such as getting Leo's decision by Wednesday.

The tempting alternatives keep the problem alive. Raising the probability to "certain" leaves it in the wrong list. Waiting for the next monthly review wastes weeks before opening. Declaring it "marketing's job" ignores that physics package prices are part of the launch, so the project owns the problem.

The other two kinds need their own actions too. An assumption needs a check with a date: the plan's 15 learners per tutor is checked by confirmed weekly slots from each tutor by 10 January. A dependency needs a named supplier and a date in the plan: ads wait for the landing page with prices, so that hand-over goes into the schedule. A risk needs a probability, an impact, an owner and a response, which the next lesson covers.

Labels change as the project moves. If on 10 January the slots cover only 10 learners per tutor, the assumption's check has failed and the line becomes an issue: an owner and an action this week, such as recruiting more tutors or adjusting the target. A risk that happens becomes an issue too; a dependency that slips may create a risk downstream.

That's why sorting is a weekly habit, not a one-off at the start.

"Something may go wrong with the platform" is a worry, not a risk anyone can act on. Write every risk in three parts:

• the cause you can see today, which tells you where to look;
• the event that may happen, which tells you what to watch for;
• the consequence for the project, which tells the sponsor why to care.

Vira's version: "Because I also teach the January intensive (cause), my final review may slip past 15 December (event), so tutors would prepare demo lessons on draft material (consequence)." Danylo rewrites Leo's worry the same way: because the checkout is new code from a contractor with other clients, his release may come late, so the provider's review and the team's tests get squeezed.

The form forces precision. If you can't name a cause, you don't yet know what to watch; if there is no consequence, it may not be worth a line.

With the three-part form, a risk list is easy to check line by line. A well-written risk has a visible cause, a possible event, ideally with a date, and a consequence for the project.

Four lines from Klasna's list show the difference. "Because the illustrator works for other clients, the diagrams may arrive after 20 January, so practice sets would go out without figures": cause, event with a date, consequence. That one passes.

"Tutors are a problem" names nothing to watch and nothing to do. "The landing page loses waiting-list entries sent from phones" is written as a fact: it's already broken, so it's an issue. "Risk: high. Impact: high." gives scores to an event nobody described; you can't score what you haven't stated.

A useful habit when reviewing a list: underline the cause, the event and the consequence in each line. Whatever has no event isn't a risk yet.

Some risks never make the list because they feel like normal life. For a project of live evening lessons, that is exactly where the danger sits.

At Klasna, strong tutor candidates teach at schools, so they are free only in the evenings and at weekends. That part is a known limit you plan around, not a risk. 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.

Winter evenings add another: power outages and air-raid alerts. That they happen is known; whether they cut this project's lessons in February is uncertain, and the consequence is real. A lesson cut in the middle twice in a row, and a family gives up.

Write these down like any other risk: cause, event, consequence. Treating them as background means nobody plans the response, such as rescheduling rules or a backup connection.

A real list mixes all four kinds, and practising the sort on single lines makes the big list manageable.

From Klasna's list: "The diagnostic test may place learners at the wrong level, so families would ask to switch tutors in February" is a risk: a future event with a consequence. So is "Ad prices may rise in the January exam season, so reaching 120 learners would cost more than planned."

The rest only look like risks. "Danylo is on sick leave this week" and "the illustrator invoice is unpaid and the drawings are on hold" are issues: they're happening now. "Ads wait for the landing page with prices" is a dependency: it belongs in the schedule. "Physics tutors accept the standard payout of 430 UAH per lesson" is an assumption: it needs a check, such as Roman's offers to the first candidates.

The giveaway words help: "may" plus a consequence suggests a risk; present tense suggests an issue; "wait for" a dependency; a plan figure nobody confirmed an assumption.

By Friday Klasna's shared list has 40 lines, and nobody's name is next to any of them. A list like that looks thorough and protects nothing: most lines are issues and wishes, the real risks drown, and some are missing altogether.

Sort before you score anything. Issues go to an issue list, each with an owner and a fix this week. Assumptions go back into the brief with a check date. Dependencies go into the schedule with a supplier and a date. What stays are risks: rewrite each as cause, event and consequence, and add the ones nobody wrote, such as evening slots filling up or outages and alerts cutting live lessons.

Scoring all 40 first, or forwarding them to Leo as they are, spends attention on the wrong things.

How it fits together: telling risks from issues, assumptions and dependencies, and writing each risk as cause, event and consequence, gives you a clean list. The next lesson turns it into a short register: how likely, how much it costs in days or money, and who watches each risk.