Start by separating risks from problems
A risk is something that might happen and affect a project’s scope, schedule, cost or quality. A problem, often called an issue, has already happened. “The client may not approve the draft in time for the launch” is a risk. “The approval deadline passed without a response” is an issue. The distinction matters because a risk gives the team time to prepare; an issue calls for an immediate decision about what to do next.
Small projects do not need a complex risk process. They do need a shared way to notice uncertainty before it quietly becomes a missed deadline. At the start of a project, look at the work plan and ask: What are we assuming will go smoothly? Which tasks depend on someone outside the team? Where would a delay or mistake be expensive to correct? The answers provide a first list of risks, not a prediction that everything on the list will happen.
Look for risks at handoffs and decision points
Risks often sit between tasks rather than inside them. A designer may finish a page on time, but development cannot begin until the client approves it. A freelancer may be ready to deliver a report, but the source data may arrive in an unusable format. Walk through the project from request to final delivery and mark each handoff, approval, dependency and task that only one person can perform.
Invite the people doing the work to add concerns. Ask specific questions: What information is still missing? Which estimate has the least supporting detail? What would force us to redo work? Is there a supplier, tool or decision-maker we cannot control? Specific questions tend to produce more useful answers than asking whether anyone sees “any risks.”
Write each risk as a possible event and its consequence: “If product details arrive after the agreed date, the team may have less time to check the final pages.” This is more actionable than a label such as “client delay.” Keep the list focused on events that could change a decision or require preparation. Ordinary uncertainty does not need its own entry unless the team can monitor or respond to it.
Use a simple register to make risks visible
A risk register can be a shared spreadsheet or a short table in the project plan. For each entry, record the risk, its potential effect, an owner, a warning sign, a planned response and a review date. The owner is responsible for checking and raising the risk, not necessarily for solving it alone. If no one owns an entry, it is easy for the team to assume someone else is watching.
Prioritize without pretending to know exact probabilities. A simple low, medium or high rating for likelihood and impact is often enough. Discuss what the ratings mean for this project: a one-day delay may be minor for an internal draft but significant for a fixed delivery window. Put the most consequential risks near the top, especially those that need action well before their effects appear.
For example, a small team preparing a customer workshop might log: “If participant requirements are not confirmed by the planning deadline, the exercises may not fit the group.” The owner could be the workshop lead. The warning sign might be missing responses to a short intake form, and the response might be to follow up with the client and prepare an adaptable exercise. The entry tells the team what to watch and what it can do.
Decide what will trigger action
A response is most useful when it is agreed before the team feels rushed. For each important risk, choose whether to reduce its likelihood, reduce its impact, accept it with a contingency, or change the plan to avoid it. You might reduce a review-delay risk by booking approval time early. You might reduce its impact by leaving room in the schedule for one revision. If neither step is practical, agree on what the team will do if approval arrives late.
Turn vague concerns into observable warning signs. “The client seems busy” is hard to track; “the client has not named an approver by the agreed planning date” is clearer. Where possible, define when the owner should raise the concern and who can make the next decision. This helps prevent a team from noticing a warning sign but waiting too long to discuss it.
Responses should match the size of the risk. It rarely makes sense to spend hours designing a backup plan for a minor inconvenience. It may make sense to test a critical file format early, confirm access to a necessary tool, or identify a backup reviewer. The aim is not to remove all uncertainty; it is to avoid being surprised by uncertainty the team could reasonably have noticed.
Review, update and close the loop
Check the register alongside normal project updates rather than creating a separate process that no one maintains. For a short project, a brief review at each milestone may be sufficient. Ask what has changed, whether warning signs have appeared, whether a response is still practical and whether new risks have emerged. Remove or archive risks that are no longer relevant so the active list stays useful.
When a risk happens, move it to the issue list or mark it as an active problem. Record the decision, the person responsible and any effect on the project plan. Let affected clients or partners know about a material change with a clear explanation of the options, rather than presenting an outdated plan as if nothing has changed.
At the end of the project, note which warning signs were useful and which risks the team missed. A few concrete lessons can improve the next project’s checklist. Risk tracking works best as a habit of noticing, discussing and deciding early—not as a document created once and forgotten.
