Weekly RAID Reviews: The Habit That Keeps Projects on Track

Every time a RAID log is produced in your company, can you honestly say it gets reviewed regularly and treated as the important project artifact it is?

If not, this is where problems ensue. The risks were recorded. The dependencies were known. The assumptions had been sitting there for three weeks. But none of them were discussed at the point when a decision could still change the outcome.

That is the real purpose of a weekly RAID review.

It is not a meeting to read through a spreadsheet. It is a regular point of control where the delivery team works out what could disrupt the plan, what already has, and what needs to happen next.

Run well, it gives a project manager something most reporting processes do not: a reliable explanation of what is changing and why.

A weekly RAID review is a recurring session used to examine the project's risks, assumptions, issues and dependencies.

The distinction between those four categories matters less than the discipline of reviewing them properly.

A risk is something that might happen. An issue is something that has happened. An assumption is something the plan currently relies on being true. A dependency is something the project needs from another person, team, supplier or decision.

In practice, these categories often move into one another.

An assumption about vendor capacity becomes a risk when evidence starts to weaken it. The risk becomes an issue when the vendor misses a date. The issue creates a dependency on a recovery plan that another team has to deliver.

The weekly review is where that movement becomes visible.

Without it, the RAID log becomes a record of old concerns. With it, the log becomes part of the project's operating rhythm.

Project risk does not change neatly in line with monthly governance.

A supplier misses a delivery. A technical lead revises an estimate. A stakeholder delays a decision. A team discovers that the migration is more complicated than the discovery work suggested.

None of these events waits for the next steering committee.

A weekly cadence gives the project enough time for meaningful progress between reviews without allowing important items to sit untouched for too long. It is frequent enough to catch movement, but not so frequent that the session becomes another daily status call.

The exact interval matters less than consistency.

The team needs to know that every week there will be a point where unresolved delivery threats are examined, owners are challenged and decisions are made.

That expectation changes behaviour outside the meeting too.

Owners are more likely to update their items when they know they will be asked about them. Stakeholders are more likely to respond when there is a clear escalation point. Project managers spend less time chasing vague updates because the next review creates a deadline.

The value is not just the meeting itself. It is the pressure the meeting applies to the rest of the delivery system.

This is where many RAID reviews go wrong.

The project manager shares the screen. The team works down the log. Each owner gives an update. Forty-five minutes later, everyone knows roughly what happened, but nothing has materially changed.

That is a status meeting with a RAID log open.

A useful RAID review has a different job. It should answer three questions: what has changed? What now threatens a milestone, outcome or commitment? What needs to be decided, assigned or escalated?

The distinction matters because status and control are not the same thing. Status describes the project. Control changes what happens next.

A risk owner saying, “We are still waiting for the security team,” is status. Agreeing that the security lead will provide a decision by Wednesday, with escalation to the programme sponsor if that date is missed, is control.

The first sentence explains the delay. The second creates a route through it. That is the standard a RAID review should meet.

Project teams often spend too much time improving the format of the RAID log and too little time improving the quality of the conversation around it.

Columns multiply. Risk scores become more elaborate. Conditional formatting gets adjusted. A new dropdown is added to distinguish “monitoring” from “mitigating.”

None of this fixes a log full of vague entries.

“Resource risk” is not useful. “Potential delay due to technical complexity” is not useful. “Stakeholder availability may affect timeline” is barely an observation.

A useful RAID item needs to explain the relationship between the concern and the delivery plan. For example: the payments team has not confirmed API capacity for performance testing. If capacity is not confirmed by 14 June, the test window will move and the release milestone will be at least five working days late.

That entry gives the team something to manage. It identifies the dependency, the deadline and the consequence. The next action can be assigned. The escalation point can be agreed. The affected milestone is clear.

The strongest RAID logs do not simply describe concerns. They show what each concern affects. That relationship is what allows a project manager to explain the project with confidence.

Not every open item deserves equal time.

A project with a mature RAID log may contain dozens of entries. Reviewing each one in sequence is a good way to make sure the important items receive the least attention.

The session should focus on movement and consequence. Start with anything that has changed since the last review.

A risk score has increased. A mitigation date has been missed. A dependency has moved onto the critical path. An assumption has been disproved. An issue now affects another workstream.

Then focus on the items that require collective intervention. Some RAID items can be managed by the owner without taking up meeting time. Others need a decision, additional resource, cross-team agreement or senior escalation.

Those are the items worth discussing. A good review is selective. It does not attempt to prove that every line has been checked. It uses the available time to improve the project's chances of success.

Most RAID logs have an owner field. That does not mean the items are owned.

An owner is not simply the person expected to provide the next update. They are the person responsible for moving the item towards resolution, mitigation or validation.

That distinction becomes obvious when an item stalls. The named owner says they are waiting for another team. The other team is not in the meeting. No date has been agreed. The item remains open for another week.

Technically, it has an owner. Operationally, nobody is driving it.

A useful review pushes past the update. What has the owner done? What response are they waiting for? When was it requested? What happens if it does not arrive? Who has the authority to intervene?

This is not about making the meeting confrontational. It is about preventing passive ownership from being mistaken for active management.

A project can tolerate bad news. It cannot tolerate bad news with no route to action.

Risks and issues usually dominate RAID conversations because they sound urgent. Assumptions often sit quietly in the background. That makes them dangerous.

Every delivery plan contains assumptions. The team assumes a specialist will be available. It assumes a vendor will meet a lead time. It assumes data quality is good enough. It assumes a policy interpretation will be accepted. It assumes a decision will be made before build starts.

These assumptions are often treated as notes rather than things that need active management. But an untested assumption is simply a future issue with an uncertain date.

A good RAID review asks whether important assumptions are becoming stronger or weaker. What evidence supports them? When will they be validated? What happens if they are wrong? Who is responsible for finding out?

The point is not to eliminate assumptions. That is impossible. The point is to stop building a delivery plan on claims nobody has checked.

Dependencies are another common source of false confidence.

A project manager records that the project depends on architecture approval, access to a test environment or input from a supplier. The dependency is visible, so it feels managed. But visibility alone does not protect the schedule.

A dependency becomes manageable when it has a required-by date, a named provider, a clear recipient and an understood consequence.

“We need input from legal” is not enough. “The legal team must approve the revised customer wording by 18 September to protect the print deadline” is something the team can act on.

That level of specificity also improves escalation. It is much easier to escalate a missed commitment than a general concern. Senior stakeholders can respond to a clear request. They struggle with statements such as “legal is becoming a blocker.”

The weekly RAID review should turn dependencies into commitments wherever possible. Who owes what to whom, by when, and what happens if it does not arrive?

One of the main reasons RAID logs become detached from delivery is that the items sit in isolation.

A risk is recorded in one tool. The milestone plan sits somewhere else. Actions are tracked in meeting notes. The project manager holds the relationship between them in their head.

That works until the number of moving parts increases. Then a stakeholder asks why the release has moved by four days and the answer has to be reconstructed from old messages, schedule changes and partially updated logs.

Every significant RAID item should connect to the thing it threatens, delays or depends on. That might be a milestone, a deliverable, a decision, a budget line or a customer commitment.

The connection is more useful than a generic high, medium or low score. A high-scoring risk attached to a non-critical activity may need monitoring. A moderate dependency attached to the only available test window may need immediate escalation.

Priority comes from consequence, not just scoring. This is why the critical path should inform the RAID review, even if the project does not use formal Critical Path Method calculations. The team needs to understand which items affect work with no room to move.

See how Causr links risks and blockers to the milestones they threaten

Many teams score risks by multiplying probability by impact. This can be useful for sorting a long log. It creates a shared shorthand and helps the team notice changes over time.

It can also create false precision. A risk scored 12 is not necessarily more important than one scored 10. The difference may simply reflect how two people interpreted a scale.

Scoring works best as a prompt for discussion, not a substitute for judgement.

A low-probability event could still require senior attention if the impact would be severe. A moderate risk might need immediate action because the mitigation window is closing. A high-scoring risk may already have an effective contingency in place.

The review should consider exposure, timing and recoverability. How likely is it? What would it affect? How soon would the project need to respond? How difficult would recovery be? That produces a more useful view than a single number.

Projects often treat escalation as a sign that normal management has failed. That usually means items are escalated late.

By the time the sponsor becomes involved, the deadline has already been missed, the mitigation options have narrowed and everyone is asking why the issue was not raised sooner.

A good RAID review agrees escalation triggers while there is still time to act. The trigger might be a missed date, a lack of response, an increase in expected impact or the failure of a mitigation action.

For example: if the supplier has not confirmed the revised delivery date by Thursday, the dependency will be escalated to the commercial director.

That removes ambiguity. The owner knows what will happen. The project manager does not need to decide from scratch whether the item is serious enough. The escalation is tied to evidence, not mood.

This also makes escalation less personal. It is not an accusation. It is the next agreed step in managing the item.

The quality of a RAID review is often visible in the language people use.

Weak discussions sound like this: we are keeping an eye on it. There has been some progress. We are waiting for an update. It should be fine. We will know more next week.

These phrases may be true, but they do not help the team manage delivery.

A stronger discussion is more specific: the infrastructure team has completed the design but has not booked the change window. The next available slot is 22 August. If the booking is not confirmed by Tuesday, the migration milestone will move by one week.

Now the team can make a decision. It can escalate the booking, find another route, accept the delay or change the sequence of work.

Specificity is what turns RAID management from reporting into delivery.

There is a common failure mode in which the project manager becomes the owner of almost every risk, issue and dependency. This usually happens because the PM is the person doing the chasing.

They schedule the meeting, update the log, request the response, escalate the delay and report the impact. Over time, activity gets confused with accountability.

The project manager may own the RAID process. They should not automatically own every delivery threat.

A technical risk should usually be owned by someone with authority over the technical response. A commercial dependency should sit with someone who can influence the supplier. A product assumption should be owned by the person responsible for validating it.

The PM's job is to make sure ownership is clear, progress is visible and escalation happens when required. That is already enough work.

RAID reviews become slow when the meeting is used to collect information that should have been provided beforehand.

The project manager asks each owner whether the status has changed. Someone searches their notes. Another person says they will check after the call. The scribe updates dates while everyone watches. The session turns into live data entry.

The simplest fix is to separate preparation from discussion.

Owners should update their items before the meeting. The project manager should identify the entries that have changed, stalled or need intervention. The meeting should then begin with a clear view of where the conversation is needed.

This does not require a complicated process. It requires a basic expectation: the log is updated before the review, not during it.

There will still be changes in the room. Decisions will alter actions and dates. New risks will emerge during discussion. But the meeting should not start from a blank page every week.

The best RAID reviews are usually short because they are focused, not because they are rushed.

A typical session might begin with a brief summary of what has changed across the project. Not a complete status update. Just the changes that affect delivery confidence.

The group then reviews new items and confirms whether they have been classified, owned and linked to the relevant part of the plan.

Most of the time should be spent on a small number of items that need action or decision. These are usually the items affecting key milestones, crossing team boundaries or approaching an escalation point.

The meeting should end with a clear record of what was decided, who is doing what and when the next intervention will happen.

That is enough. The value does not come from covering every RAID category evenly. It comes from leaving the room with fewer unresolved decisions than the team entered with.

A six-week release depended on a third-party vendor providing a revised API.

At the start of the project, the vendor confirmed that delivery would take ten working days. The team planned integration testing around that commitment.

During the first weekly RAID review, the PM noted that the vendor had not yet provided a detailed delivery plan. The dependency was not late, but confidence had weakened.

An owner was assigned to obtain confirmation. A fallback option was also identified: the development team could build against a mock service, although doing so would add rework later.

By the second review, the vendor had missed its own internal design date. The dependency was now likely to affect integration testing.

The team did not wait for the final delivery date to be missed. It approved the mock-service approach, assigned two developers and escalated the vendor delay through the commercial lead.

The API arrived four days late. The release still moved, but only by three days. Without the earlier decision, integration work would have stopped completely and the delay would likely have been measured in weeks.

The RAID review did not remove the problem. It made the deterioration visible early enough for the team to preserve options. That is what good project control looks like.

The most obvious sign is not a lower number of open items. A healthy project can have many risks. A troubled project can have a suspiciously tidy log.

The better test is whether items move. Are risks being mitigated? Are assumptions being validated? Are issues reaching resolution? Are dependencies receiving commitments? Are overdue actions triggering intervention?

The age of open items is often more revealing than the total number. A risk that has remained unchanged for eight weeks may be under control, but it may also have become part of the background.

Repeatedly missed action dates are another warning sign. They suggest the meeting is recording commitments without enforcing them.

The project should also become easier to explain. A PM with a functioning RAID process should be able to tell a sponsor what has changed, what it affects, who owns the response and what happens next. They should not need to reconstruct the answer from Slack on Friday evening.

A weekly RAID review will not save a project by itself. It will not fix weak sponsorship, unrealistic dates, unclear scope or a team without enough capacity.

It can, however, stop those conditions from remaining vague.

It gives the delivery team a regular place to turn concerns into named items, named items into actions and missed actions into escalations.

It creates a record of how the project changed. More importantly, it creates a record of how the team responded.

The strongest RAID reviews are not memorable meetings. They are usually direct, slightly repetitive and finished on time.

Their value becomes clear later, when a milestone slips and the cause is already known. The risk was visible. The owner was clear. The decision was recorded. The next step had already started.

Run your weekly RAID review in Causr