A risk is something that may affect the outcome
Project risk involves uncertainty: an event or condition may change how work proceeds. If the problem has already occurred, you need actions addressing the facts, as well as a record of the possibility.
An illustrative team is preparing a webinar. The speaker may deliver materials late, the platform may be unavailable, and the invitation may attract fewer participants than expected. These situations have different early warnings, consequences and responses.
A risk register preserves these distinctions. It does not protect the project by itself, and need not list every imaginable problem. Start with a few uncertainties that could genuinely change an important outcome.
- Risk
Materials may arrive too late for review.
- Problem
The handover deadline has passed and materials are missing. Act on the current facts.
Example risk register
| Risk | Early warning | Prepared action |
|---|---|---|
| Late materials | No agreed presentation outline by the checkpoint | Clarify readiness and reduce scope in advance |
| Platform problem | The main participant journey fails testing | Fix it or agree a fallback format |
| Unclear invitation | People ask whom the webinar is for | Check the promise and clarify the audience |
| Organiser overload | Preparation overlaps with external commitments | Reallocate or remove optional work |
For a real project, add someone who monitors the signal and a review time to every row. “The team monitors it” often means nobody considers it their task. The risk owner need not personally solve everything, but should know when to raise the issue.
Likelihood and consequences can be assessed qualitatively when data is scarce. Explain what “high” means to your team. Do not turn a subjective impression into a precise percentage merely to look analytical.
How to phrase a risk clearly
A useful working statement connects a cause, possible event and impact. For example: “One busy expert prepares the materials; if handover is delayed, the editor will have no time for review.” You can now see what to clarify and influence.
- Cause
Preparation depends on one participant with other commitments.
- Event
Material arrives after the agreed checkpoint.
- Consequence
Review time shrinks or the promised format changes.
“Everything might fall apart” is too general. “The expert is unreliable” substitutes a personal judgement for analysis. A useful record describes the situation and consequences without unnecessary personalisation.
Choose a response proportionate to consequences
Sometimes a change of approach avoids a risk: dropping a complex demonstration that is not ready. Sometimes an early check reduces likelihood. Sometimes a fallback format reduces consequences. Some risks must be accepted when action costs more than possible damage, provided this is a conscious decision.
- Name the outcome you are protecting.
- Choose an action that actually changes likelihood or consequences.
- Check who can carry it out and what it costs.
- Define the trigger for the response.
- Agree which remaining uncertainties you accept.
A fallback also needs testing. A link to another platform is not a ready backup if nobody knows how participants will reach it. The more important the scenario, the more useful it is to test before the event.
Record risks so people can act on them
Instead of “speaker risk”, write the chain: if the programme is not agreed by Wednesday, the invitation cannot promise a specific benefit, so publication will move or content must be reduced. Separate the cause, uncertain event and impact. An existing delay is a problem to manage now; a risk describes what might still happen.
Assign an owner for monitoring and action to every risk. In the illustrative webinar, Anna checks programme readiness on Tuesday. Preventive action means agreeing a short outline before the full text. The contingency is a previously discussed shorter format. These are different actions: the first reduces likelihood, the second limits consequences.
Likelihood and impact can be qualitative, but definitions need to be shared. For example, “high impact” threatens the promised date or main outcome; “medium” means local rework without changing the promise. Do not convert words into percentages without data. An invented numerical score does not make a decision more accurate.
First consider risks threatening the goal and requiring early action. A rare event with severe consequences should not automatically be dismissed for its low likelihood. Involve a competent responsible person for legal, financial, technical and other specialist risks: this editorial example does not replace professional assessment.
What happens at the checkpoint
On Tuesday Anna sees only a topic list without a sequence. The early warning has triggered. She clarifies remaining work and presents a choice: help assemble the programme, narrow the promise or postpone publication. Record the decision and next checkpoint in the register. Writing “high risk” without changing any action achieves nothing.
Agreeing a shorter version does not necessarily close the risk. Check whether the invitation communicates the revised benefit and the platform is ready. Record residual risk after the action. If the event has already occurred, link the record to a problem-resolution task so it is not endlessly discussed as a hypothesis.
Update the register while the outcome can still change: before publishing the invitation, before rehearsal and before launch. After the event, review which signals helped and which risks were mere generalities. A good register is short enough to use, without hiding significant threats for brevity.
Turn a risk response into the next task
Start with one task: “Check the main webinar participant journey”. In the description, record the expected output: joining, material access and speaker contact tested; significant problems recorded with next actions. You do not have to transfer the entire article into the service: keep what you will need while doing the work.
Choose a checking day that leaves time to fix problems. For awaited materials, set a separate checkpoint before final preparation.
- Create a task with a concrete action in its title.
- Add readiness conditions and the necessary context to the description.
- Choose a day and check that the work fits alongside other commitments.
Sinqly registration is free. You can also complete the article's example in an ordinary document; the service helps you return to your chosen actions.
How to keep the register useful
Revisit it when conditions change and at important project transitions. Close rows that are no longer relevant. Turn realised problems into concrete actions. Add new risks based on facts rather than to grow the document.
After the project, check which warnings helped, which came too late and which measures were unnecessary. This informs the next launch. The absence of a problem alone does not prove a measure prevented it: that conclusion needs additional evidence.
The register aims to help you notice earlier and respond thoughtfully. Uncertainty cannot be eliminated completely from a project.
More questions to clarify
How many risks should we record?
Start with those capable of significantly affecting the result. A long list without owners or responses is less useful than a few well-developed rows.
Must likelihood be a percentage?
Only if there is a suitable basis and it helps the decision. When data is insufficient, a qualitative assessment with an explanation is more honest.
Who is responsible for a risk?
Assign someone to track the signal and initiate a response. The decision and execution may require other participants.
Was this helpful?
Rate the article and tell us what was missing. Your feedback goes to the Sinqly team and will not be published on the site.
Sources and notes
- Atlassian: project risk register
- The suggested process reflects editorial practice; it does not promise identical results for everyone.
Project stakeholders: who influences the outcome and how to work with them
How to identify project stakeholders, understand their expectations and choose a communication approach. Includes an influence map and a small launch example.
SWOT analysis: a small project example and practical next steps
How to fill a SWOT matrix with facts, distinguish internal constraints from external threats, and choose actions after analysis. Detailed case study of a small service.
RACI matrix: how to assign project responsibilities
Explore the four RACI roles through a website launch: who does the work, who accepts the result and who really needs to participate. With a completed example and error checks.