Drafting a RAID log is one of those skills that quietly transforms a project from “stressful and unpredictable” to “calm and under control.” A RAID log helps you keep track of the four things that can derail a project if you don’t pay attention to them: Risks, Assumptions, Issues, and Dependencies. Think of it as your project’s safety net — simple, practical, and incredibly useful for beginners.

What a RAID Log Is

A RAID log is a simple table where you capture:

• Risks — things that might go wrong later
• Assumptions — things you are treating as true, even though they might change
• Issues — problems happening right now
• Dependencies — things you are waiting for, or things that depend on you

It’s not a complicated document. It’s more like keeping a notebook where you write down the things that could trip you up, so you can stay ahead of them.

Why RAID Logs Matter

A RAID log helps you:

• Stay organised
• Spot problems early
• Communicate clearly with your team
• Reduce surprises
• Make better decisions

It’s the same feeling as writing a list before going to the supermarket — suddenly everything feels clearer and easier to manage.

How RAID Logs Work in Real Organisations

In the NHS Teams track risks like “system outage,” issues like “bug in appointment booking,” and dependencies like “waiting for clinical approval.”

In councils A team might track assumptions about resident behaviour, risks around service delays, or dependencies on external contractors.

In charities They track risks for fundraising events, issues with volunteer availability, and dependencies on partner organisations.

In tech startups and big tech companies RAID logs help teams manage fast‑moving work, especially when many teams rely on each other.

Every organisation uses RAID logs because they bring order to complexity.

Breaking Down the Four Parts

• Risk — Something that might happen. Example: “The new software might not be ready before launch.”
• Assumption — Something you are counting on being true. Example: “We assume the supplier will deliver on time.”
• Issue — A problem happening right now. Example: “The login page is currently broken.”
• Dependency — Something you need from someone else, or something that needs to happen before you can continue. Example: “We can’t start testing until the design team finishes the prototype.”

Once you write these down, you can plan how to manage them.

What Makes a Good RAID Log

A good RAID log is:

• Clear
• Short
• Updated regularly
• Easy to understand
• Shared with the team

It’s not about perfection — it’s about visibility.

Practical Application (Walk‑Through Together)

Let’s imagine a simple everyday project: planning a small family gathering in your new UK home.

Step 1: Identify a Risk

“The food delivery might arrive late.” Action: Order earlier or choose a reliable restaurant.

Step 2: Identify an Assumption

“Everyone will be free on Saturday.” Action: Send a quick message to confirm.

Step 3: Identify an Issue

“The living room is still messy.” Action: Spend 20 minutes tidying before guests arrive.

Step 4: Identify a Dependency

“I need my cousin to bring the drinks.” Action: Remind them the day before.

You’ve just created a simple RAID log — the same way project teams do in NHS digital, councils, charities, and tech companies.

Your Turn (Activity)

Choose a small project in your life — maybe preparing for an exam, organising your finances, or planning a move.

1. Write down one Risk.
2. Write down one Assumption.
3. Write down one Issue.
4. Write down one Dependency.
5. Add one action you can take for each.

You’ve just drafted your first RAID log.

One Thing to Remember

A RAID log keeps your project steady by making the hidden challenges visible — and manageable.