Project Management: Who Should Own the RAID Log?

The RAID log usually has an owner but the problem is that “owner” can mean three different things, and most projects never stop to define which one they mean.

The project manager maintains the file, so everyone assumes the project manager owns the risks. The sponsor is accountable for the project, so everyone assumes the sponsor owns the major issues. A technical lead is named against an entry, so everyone assumes they are responsible for every action connected to it.

Then the ball drops along the way.

The PM has been chasing updates but cannot approve more resources. The sponsor has not seen the details. The technical lead says they own the mitigation, not the commercial dependency blocking it. The log is up to date, but the project still has no clear route to a decision.

This is why RAID log ownership is not a single role. One person should own the integrity of the process. Individual people should own the entries. Someone with the right authority should own the decisions and residual risk. When those responsibilities are separated clearly, the RAID log becomes useful. When they are not, it becomes another spreadsheet the PM is expected to keep alive through force of personality.

On most projects, the project manager or delivery lead is the custodian of the RAID log.

That means they are responsible for making sure the log exists, is accessible, follows an agreed format and is reviewed at the right cadence. They make sure new items are recorded properly, owners are named, dates are visible and unresolved items reach the right forum.

They also protect the integrity of the record.

If an issue is marked closed without evidence, they challenge it. If a risk has not been updated for six weeks, they bring it back into review. If two teams have recorded different versions of the same dependency, they force the discrepancy into the open.

That is process ownership.

It does not mean the PM personally owns every risk, assumption, issue and dependency in the log.

This distinction matters because project managers are often held accountable for outcomes they cannot directly control. They can coordinate a supplier escalation, but they may not own the contract. They can surface a technical risk, but they may not be qualified to choose the mitigation. They can report a funding gap, but they cannot approve the budget.

The PM owns the system that makes these things visible. The people with the relevant authority and control own the response.

A RAID item should be owned by the person who can move it.

That sounds obvious, but many logs assign ownership to whoever first raised the concern, whoever happens to attend the meeting or whoever is most likely to provide an update.

None of those is necessarily the right person.

An entry owner is responsible for progressing the item towards mitigation, validation, resolution or closure. They do not need to perform every action themselves, but they must be able to coordinate the response and influence the people involved.

A technical risk should usually sit with someone who can shape the technical response. A supplier dependency should sit with someone who can influence the supplier or the commercial relationship. A business assumption should sit with the person responsible for validating it.

The owner needs more than a name in a column. They need a defined next action, a date, and a clear understanding of what happens if progress stalls.

Without that, ownership is ceremonial. The entry may technically belong to someone, but the project is still relying on the PM to chase it every week.

See the RAID log template

This is another common source of confusion.

The PM or project coordinator often updates the RAID log during the meeting. Because they are the person typing, they gradually become associated with every open item.

The actual owner provides an update, the PM writes it down, and everyone moves on.

A week later, the item has not progressed. The owner assumes the PM is following up. The PM assumes the owner is taking the agreed action. The log shows a clear name, but the behaviour around it says otherwise.

Recording an update is an administrative task. Owning the item is a delivery responsibility. Those should not be confused.

The PM can maintain the record, challenge the quality of the update and escalate missed commitments. The owner still needs to drive the response.

A good RAID review makes that distinction explicit. The person giving the update should be able to explain what they have done, what is blocking them, what decision they need and what happens next. If all they can say is that they are still waiting, the item is not being actively owned.

Some RAID items cannot be resolved at team level.

They need additional budget, a change in priority, acceptance of residual risk, a scope decision or intervention across organisational boundaries.

At that point, the entry owner and the process owner may have done everything expected of them. The project still needs someone with authority to make a decision. That is where accountability sits.

Depending on the project, that person may be the sponsor, programme director, business owner, steering committee or another senior decision-maker.

Their role is not to maintain the log. It is to act when the log exposes something the delivery team cannot resolve alone.

This is why a sponsor who is technically accountable but rarely engaged is of limited use. Accountability without availability is mostly theatre.

If the project cannot reach the accountable person quickly enough to protect the milestone, the escalation route is not working.

The RAID process should make clear who can approve a change, accept a risk, release funding or change priorities. It should also make clear how and when they will be brought into the conversation.

Project teams sometimes resist assigning a single owner because an item crosses several functions.

A data migration issue may involve engineering, operations, compliance and a supplier. A regulatory dependency may require input from legal, product and an external adviser. A release risk may sit across several workstreams.

The instinct is to assign several owners. That usually makes the item harder to manage.

Shared ownership often means nobody is sure who is expected to drive the next step. Each person assumes someone else is handling the coordination.

A better approach is to assign one owner for the item and separate owners for the actions underneath it. The item owner remains accountable for moving the overall concern forward. Action owners deliver specific pieces of the response.

For example, the technical lead may own the integration risk, while the vendor manager owns the revised statement of work and the engineering manager owns the additional development capacity.

The item still has one person responsible for the whole picture. That matters when the actions begin to diverge, dates are missed or the mitigation stops being credible.

Ownership is often assigned badly because teams focus on who caused the problem. That is not always relevant.

A supplier may have caused a delay, but an external supplier is not a useful internal owner if they cannot be held accountable through the project’s governance. A stakeholder may have introduced the late requirement, but they may not be the right person to manage the delivery impact.

The better question is who can now influence the outcome. That might be the commercial lead, the product owner, the technical director or the workstream lead.

RAID ownership is not about blame. It is about control.

The project needs someone who can organise the response, make commitments and escalate when those commitments are not met.

Assigning the item to the person closest to the cause may feel fair. Assigning it to the person best placed to move it is usually more useful.

Some organisations assign every high-severity risk or issue to the sponsor.

This creates the appearance of senior accountability, but it usually weakens practical ownership.

Sponsors are rarely close enough to the detail to manage the mitigation day to day. They may be able to approve funding or change direction, but they are not the person coordinating technical actions, vendor responses or operational workarounds.

A red item still needs an operational owner. The sponsor may own the decision or accept the residual risk. They should not automatically replace the person responsible for progressing the item.

For example, a technical lead may own a critical architecture risk. The sponsor may approve the additional budget required to mitigate it. The project manager may own the escalation process and reporting.

All three roles matter. Collapsing them into a single “owner” field hides the way the work actually gets done.

Many RAID logs stop at the person responsible for the next action.

That is not enough when the item reaches a point where a decision is required.

A risk may need acceptance. An issue may require scope reduction. A dependency may require a contractual escalation. An assumption may need to be replaced with a different planning basis.

The log should show who owns that decision. Otherwise, the entry owner spends several weeks producing updates without having a route to resolve the underlying problem.

This is one reason items remain open for so long. The action owner is working. The PM is reporting. Nobody has named the person who must make the call.

A mature RAID process distinguishes between action ownership and decision ownership. The first tells you who is doing the work. The second tells you who can change the position of the project.

Explore decision tracking in Causr

An owner without a date is only a contact.

The RAID entry needs a clear point by which something should happen. That may be a target resolution date, a mitigation deadline, a validation date or the next agreed review point.

Not every risk can have a closure date. Some risks remain open for most of the project. But even then, the next action should have a date, and the basis for continued monitoring should be clear.

The useful question is not always “When will this be closed?” It may be “When will the next piece of evidence be available?” or “When will we know whether the mitigation has worked?”

Dates create accountability because they turn general intent into a commitment. They also give the project an objective escalation trigger.

Without a date, an item can remain “in progress” indefinitely. With a date, the project can see when progress has stopped.

Most ownership models look fine while work is progressing. The test comes when a deadline is missed.

Does the entry owner revise the plan and explain the consequence? Does the PM challenge the lack of movement? Does the accountable person intervene when the team cannot recover?

Or does the due date simply move by another week?

Repeatedly moving dates without changing the response is one of the clearest signs that ownership is weak. It suggests the log is recording delay rather than managing it.

A missed commitment should create a change. The item may need escalation. The mitigation may need to be replaced. The impact may need to be revised. The owner may need support or additional authority.

Something should happen beyond editing the date field.

A good project manager does not simply collect updates. They challenge whether the item is being managed properly.

Is the owner the right person? Is the next action specific? Is the due date credible? Has the impact changed? Does the item now threaten a milestone? Is the mitigation still working? Does someone senior need to intervene?

This is active process ownership.

The danger comes when challenge turns into absorption. The PM starts sending the chasers, booking the supplier call, drafting the mitigation, escalating the funding request and updating every stakeholder. The owner remains named in the log, but the PM is doing the work.

That may keep the item moving in the short term. It also teaches the project that ownership can be delegated back to the PM through inactivity.

Eventually, the PM becomes the operational owner of everything that nobody else is driving. That is not a sustainable control model.

The PM should expose weak ownership, not quietly compensate for it.

Assumptions are often the weakest-owned part of a RAID log. They are recorded because the template includes an “A,” but nobody is quite sure what ownership means.

An assumption owner should be responsible for validating whether the assumption remains safe to use.

For example, if the plan assumes a specialist will be available in October, the owner should confirm that availability before the date becomes critical. If the project assumes a supplier can meet a transaction volume, the owner should obtain the evidence that supports it.

The owner is not responsible for making the assumption true. They are responsible for finding out whether it is true soon enough for the project to respond.

This is an important distinction. An assumption with no validation action is just an untested dependency.

The RAID log should show what evidence is required, who will obtain it and when the project needs the answer.

A dependency has at least two sides. Someone needs something, and someone else is expected to provide it.

The internal owner should be the person responsible for securing the dependency and managing the consequence if it is not delivered.

That person may not control the provider. They should still be able to confirm the requirement, agree the date, maintain the relationship and escalate when the commitment weakens.

A dependency owner who simply reports that another team has not responded is not managing the dependency. They need to make the required-by date visible, explain the impact of delay and use the agreed escalation route.

The provider may also need to be named in the record, but naming the provider is not the same as assigning an owner.

The project still needs someone on its side responsible for getting the dependency over the line.

A risk owner is responsible for the response to uncertainty.

That includes monitoring the conditions around the risk, maintaining the mitigation, recognising when the exposure changes and escalating when the project’s response is no longer sufficient.

They are not responsible for guaranteeing that the event never occurs. A well-managed risk can still happen.

The owner’s job is to make sure the project understands the exposure and has a credible response.

This is why assigning every risk to the PM is poor practice. The PM can coordinate the process, but they may not have the technical, commercial or operational authority needed to manage the uncertainty.

The strongest risk owners are close enough to understand the warning signs and senior enough to act on them.

An issue is already affecting the project. The owner therefore needs to drive resolution or containment, not simply provide commentary.

They should be able to explain the current impact, the recovery action, the decisions required and the expected path back to control.

An issue may remain open for some time, particularly on a large programme. That does not make vague ownership acceptable.

The item should still show what is changing week to week and who is responsible for each part of the response.

If the same update appears in three consecutive reviews, the project should question whether the current owner has enough authority, capacity or support to resolve it.

The person who owns an item should usually propose closure. They are closest to the response and should be able to explain why the concern no longer needs active management.

The custodian should then check that the closure is supported.

For a risk, that might mean the exposure has passed, the event can no longer occur or the residual risk has been formally accepted.

For an issue, it might mean the service has recovered, the workaround is stable or the root cause has been addressed.

For an assumption, it should mean the assumption has been validated, disproved or replaced.

For a dependency, it should mean the required outcome has been delivered or is no longer needed.

Major items may also require approval from the accountable person.

Closure should not happen because the team is tired of seeing the item. It should happen because the state of the project has changed.

A simple model is usually enough where the project manager or delivery lead owns the RAID process. They maintain the cadence, quality and visibility of the log. Each entry has one named owner responsible for progressing it. Specific mitigation or recovery actions may have separate action owners. Material decisions and acceptance of residual risk sit with the relevant sponsor, business owner or governance body. Contributors provide evidence and updates. They do not become owners simply because they are involved.

The model works when the hand-offs between those roles are clear.

The entry owner knows when to escalate. The PM knows who must act. The accountable person knows which decisions will reach them and how quickly they need to respond.

That is more useful than a large RACI diagram that nobody refers to after project kick-off.

A project depends on a third-party supplier completing an API change before integration testing begins.

The technical lead owns the dependency because they understand the requirement and can confirm whether the supplier’s output is usable.

The vendor manager owns the commercial action to secure a revised commitment.

The project manager owns the RAID process, makes sure dates and impacts are updated, and raises the item at the weekly review.

The programme sponsor owns the decision on whether to fund a fallback option if the supplier cannot recover.

The supplier misses its first internal design date.

The technical lead updates the likely impact on testing. The vendor manager requests a recovery plan by Wednesday. The PM records an escalation trigger: if the supplier does not confirm the revised delivery date by Thursday, the sponsor will decide whether to release funding for the fallback.

The dependency has one overall owner, but the work and decision rights are distributed clearly. Nobody needs to debate who is supposed to act when the deadline is missed.

That is what good RAID ownership looks like.

The log contains several items owned by “Project Team.” The PM is named against risks outside their control because nobody else volunteered. High-severity items have updates but no next actions. Due dates move every week without escalation. The sponsor sees only a summary slide and is surprised when asked to make a decision. Technical owners report that they are waiting for other teams, but no dependency owner has been named.

Resolved items are closed because the immediate problem has passed, even though the underlying condition remains. Each of these problems looks administrative. Together, they show that the project has not defined who is responsible for turning information into action.

A better RAID tool can improve visibility. It can preserve history, show overdue actions, connect items to milestones and make updates easier to find.

It cannot decide who should act.

Teams often move a weak RAID process into a new platform and expect the discipline to improve automatically. The same unnamed owners, vague actions and missed dates simply become easier to filter.

The ownership model has to be agreed first. The tool should then make that model harder to ignore.

It should show who owns the item, who owns the next action, what the item affects and when escalation is due.

The value comes from preserving those relationships, not from producing a cleaner table.

The project manager usually owns the process. The person closest to the response owns the individual item. The relevant senior stakeholder owns the decisions that require authority, funding or acceptance of residual risk. Those responsibilities should support one another. They should not be collapsed into a single name in a spreadsheet.

A RAID log is working when nobody needs to ask who is driving the item, who is doing the next action or who will make the decision if the team cannot resolve it.

The ownership is visible. The dates are clear. The escalation route already exists. The PM does not have to carry the whole thing alone.