Start with what could interrupt the work
Project risks are uncertain events or conditions that could affect your scope, schedule, quality or ability to deliver. A risk is not the same as an issue: a risk might happen, while an issue is already happening. That distinction helps you plan ahead without treating every possibility as an emergency.
Begin with the project brief. Look at the intended outcome, deadline, deliverables, dependencies and approval process. For each, ask: What must go right for this to work, and what might prevent it? A student producing a short video might depend on access to a quiet recording space. A freelancer designing a website might depend on receiving approved copy. A small team launching a campaign might depend on several people reviewing the same files on time.
Include risks within your control, such as underestimating editing time, and risks outside it, such as delayed feedback. Do not try to predict everything. The goal is a short list of plausible disruptions that would change what you do next.
Make risks specific enough to act on
Vague entries such as “communication problems” are hard to manage. Describe what could happen and its likely effect: “If the client’s reviewer is unavailable during the approval window, final revisions may miss the handoff date.” This gives you something concrete to monitor and a reason to prepare an alternative.
Walk through the project from kickoff to delivery and look for points where work waits on a person, file, decision or tool. Check whether the brief defines what is included, whether assets are available, whether collaborators understand their responsibilities and whether the delivery format is agreed. Earlier projects can also prompt useful questions, but avoid assuming the same setback will happen again.
Ask collaborators what they see as fragile. Someone editing the files may notice a technical dependency that the project lead missed; someone presenting the work may spot an unclear approval step. A shared document with one sentence per risk is enough to capture these observations.
Decide which risks deserve a backup plan
You do not need an elaborate response for every item on your list. Consider two questions: How likely does this seem, and how disruptive would it be if it happened? Simple labels such as low, medium and high are usually sufficient. Give the most attention to risks that seem both plausible and consequential.
Also consider how much warning you would have. Missing source files may be obvious at kickoff; a reviewer’s delayed response may only become clear near the deadline. A disruption with little warning may deserve a backup even if it seems less likely. Keep your assessments as judgments, not precise predictions, and update them as the work progresses.
For a website project, missing final copy may be a priority if it blocks page layout and review. A minor visual preference that can be changed after an initial draft may need only a note. This distinction keeps planning effort focused on decisions that protect the project’s outcome.
Write a trigger, an action and an owner
A simple contingency plan says when to use it, what to do and who will decide. For example: “If approved copy has not arrived by the layout start date, the designer will build the agreed page structure with clearly marked placeholder text and tell the client which review steps may move.” The trigger removes guesswork; the action keeps work moving; the owner makes the decision visible.
Choose actions that fit the project. You might reserve a small amount of time for revisions, identify a second person who can review work, agree on a simpler deliverable if a critical asset is unavailable, or keep an export format that another tool can open. Check that a backup is realistic: a substitute reviewer cannot help if they have no access to the files or context.
Record any trade-off. A shorter video, fewer page variations or a later review may protect a deadline, but it may also change the result. State who needs to approve that change. A contingency plan gives you a prepared option; it does not automatically authorize a change to the brief.
Keep the plan visible and review it briefly
Put the risk list where the project team already works, such as the brief, a shared task board or a short planning document. For each priority risk, capture its description, trigger, response and owner. Link to relevant files or decisions so people can act without searching through messages. For a solo project, the same record helps you make a calm decision when time is tight.
Check the list at natural milestones: after kickoff, before a major handoff and when scope or timing changes. Close risks that no longer apply, turn risks that have occurred into tasks, and add new ones only when they matter. At delivery, note which plans were useful and which were unnecessary. That small review can make your next project brief and schedule more dependable.
