A Simple Project Risk Register Your Team Can Act On

A delivery plan can be tidy while its assumptions remain fragile. A reviewer may be unavailable, a supplier may miss a handoff, or a required decision may arrive too late. A project risk register makes those uncertainties visible while the team still has choices.

You do not need an elaborate scoring system to begin. You need a specific event, someone watching for it, and an agreed response that can become real work.

Separate a risk from an issue

A risk is an uncertain event that could affect delivery. An issue is already happening. “The reviewer may be unavailable” is a risk. “The review deadline passed without a response” is an issue that needs action now.

A dependency is different again: the launch checklist cannot be completed until the final copy is approved. That dependency becomes a source of risk when the approval timing is uncertain. Naming the distinction keeps a current blocker from sitting in a list of things that might happen someday.

Describe an event rather than a broad concern

“Stakeholder risk” gives the team little to work with. Try a cause, event, and consequence: “Because the primary approver is away during review week, copy approval may arrive late, leaving too little time for implementation and testing.”

Keep evidence separate from assumptions. You may know the approver is away without knowing whether a delegate is available. The next useful step is to confirm the delegate, rather than treating a delay as inevitable.

Use a register with seven useful fields

A shared document is enough for an initial register. Record:

• Risk: the uncertain event, its cause, and the affected outcome.

• Likelihood: a qualitative estimate with a short reason.

• Impact: what would change in the delivery commitment.

• Owner: the person responsible for checking and raising the risk.

• Trigger: an observable condition or deadline for taking action.

• Response: a preventive step and a fallback if the trigger is met.

• Review: next check date, current status, and latest evidence.

Define “high” and “medium” in your own context. High impact might threaten a committed launch; medium impact might require resequencing work without moving that launch. These labels support discussion. They are not measured probabilities, and multiplying arbitrary scores does not make an estimate more certain.

Worked example: a landing-page approval

Consider a fictional agency preparing a Thursday launch. Design needs approved copy on Monday. The client’s usual approver will be away, and no delegate has been confirmed.

• Risk: delayed approval leaves insufficient time for build and testing.

• Assessment: medium likelihood because the delegate is unconfirmed; high impact because the launch depends on the approved copy.

• Owner: the project lead.

• Prevention: confirm a named delegate and their approval authority before the review window.

• Trigger: no delegate confirmed by noon on the last working day before review begins.

• Fallback: ask the decision maker to choose between a smaller approved launch scope and a revised launch date, with consequences stated.

The fallback is a decision to raise, not permission to publish unapproved material. Once the delegate is confirmed, record that evidence and reassess the risk. Continue tracking the actual approval; resolving one uncertainty does not complete the dependency.

Turn the response into a task

“Keep an eye on approval” is easy to forget. “Confirm the review delegate and approval authority before noon on Friday” has an outcome you can verify. Give it an owner and completion criteria, using the approach in How to Write a Clear Task.

TeamBoard’s collaboration features support comments and discussion in the context of a task or project. Keep the latest confirmation and next decision beside the response task so colleagues can understand why it exists. This is a team working practice; it does not assume a dedicated risk-register feature or automated risk scoring.

Review changes and decisions

At your project check-in, ask what changed, which triggers were met, whether preventive tasks were completed, and which decisions need escalation. Review a time-sensitive risk before its trigger date rather than waiting for a standing weekly meeting.

If the event occurs, mark it as an issue and focus on resolution. If the exposure ends, close the risk with a reason. Keeping every old item open makes the register harder to use.

Frequently asked questions

How many risks should a small team record?

Begin with the few uncertainties that could change the next delivery decision. Add detail when it changes ownership, timing, or the response. A short register that informs action is easier to maintain than a comprehensive list nobody reviews.

Does a risk owner have to solve everything?

No. The owner checks the evidence and raises the response. A client, sponsor, or another team may need to approve the resulting scope or date change.

Will a register prevent delays?

It cannot guarantee that. It gives the team a shared place to recognize uncertainty and agree when to act. Start with one risk affecting the next milestone, then create one clear response task and schedule the next check.