Who owns the RAID log on a project?
The project manager owns the RAID log as an artefact: it exists, it is current, it is reviewed. Each row has a separate owner — a named individual who is accountable for the next action on that item. On a programme, workstream leads own their own logs and the programme manager owns the consolidated view above a threshold.
Two kinds of ownership, routinely confused
"Who owns the RAID log" is really two questions. Who owns the document, and who owns each item in it. Treating them as one is how logs end up with a project manager listed against every row, which means nobody outside the PM is accountable for anything in it.
| Owner of the log | Owner of a row | |
|---|---|---|
| Who | The project or programme manager | A named individual, usually a workstream lead, technical lead or business owner |
| Accountable for | The log existing, being current, being reviewed and feeding reporting | The next action on that item happening by its due date |
| Fails visibly when | Rows go stale, nothing closes, the log is not on the agenda | Actions slip, updates are written by someone else, the item is closed without anything changing |
What the project manager actually owns
The PM is not accountable for mitigating every risk. That is not a workload anyone can carry, and it removes the pressure from the people who can actually act. What the PM owns is the process around the log:
- The log exists in one place, and everyone knows which place.
- New items get captured, scored and assigned rather than raised verbally and lost.
- The review happens on the agreed cadence.
- Items above the escalation threshold reach governance with a decision attached.
- The scoring scale is applied consistently, so a four means the same thing across workstreams.
- Closure requires a written resolution.
The last one is quietly the most important. A log where anyone can close a row with no note becomes a log nobody trusts, and the closure report at the end has nothing to draw on.
What a row owner is being asked for
Row ownership means the next action, not the outcome. Some risks cannot be mitigated by anybody on the project — a regulatory date, a vendor's internal reorganisation, a decision sitting with a group outside the programme. The owner is still accountable for the response: monitoring it, keeping the assessment current, and escalating when the response stops being enough.
Three rules keep row ownership honest:
- A person, not a team. "Infrastructure" cannot attend a review or answer a question. A name can.
- Someone who can act. Assigning a risk to the person who raised it is common and usually wrong; the raiser and the owner are different roles.
- Someone who knows. Ownership assigned in a meeting the owner did not attend is ownership in name only. It shows up two weeks later as a row with no update.
How it works on a programme
At programme scale a single log stops working, because a hundred and fifty rows spanning six workstreams is not reviewable in one sitting and most rows are irrelevant to most attendees. The usual structure is two tiers.
Each workstream lead owns a workstream log and reviews it weekly with their own team. Items meeting an agreed threshold — a score above a set level, cross-workstream impact, an issue above a severity, or anything needing a decision the lead cannot take — are promoted to the programme log. The programme manager owns that consolidated view, and it is deliberately short. The reporting relationship between the two levels is part of the wider structure described in programme governance, and the split of decision rights is what separates the two roles in project manager vs programme manager.
Promotion has to be a defined step rather than a judgement call made under time pressure, otherwise workstreams either promote everything, which recreates the unreviewable single log, or nothing, which leaves the programme manager finding out late.
Where the PMO fits
On projects with PMO support, an analyst often maintains the log mechanically — chasing updates, flagging stale rows, preparing the review pack, producing the reporting extract. That is administration of the log, not ownership of it. The distinction matters when something goes wrong: the question asked afterwards is whether the risk was escalated, and that is the PM's accountability regardless of who typed the row.
The sponsor's part
The sponsor owns nothing in the log day to day, but they are the destination for escalated items and the owner of some of them by default — anything requiring funding, a scope decision, or authority over another part of the organisation. A programme where no row is ever owned by someone senior to the PM is usually a programme where the hardest items are being quietly parked rather than escalated.
When ownership is vague
The symptoms are consistent: rows updated by the PM on behalf of everyone, the same handful of names against most items, owners who are surprised to find out they own something, and closure decisions taken in the review rather than by the owner. The correction is not a policy document. It is reading the owner column out loud in the review and asking each named person for their own update. The RAID Log & Program Governance Pack is built around that structure, with the action log and stakeholder tracker sitting alongside the RAID log; for a single project the RAID Log Template (Excel) covers the same owner and ageing fields on one sheet.
Questions
Can two people own the same RAID item?
In practice no. A secondary owner column reads as shared accountability and works as none. Name one owner and list contributors in the action text if needed.
Should the PM own risks nobody else can act on?
Only where the next action genuinely sits with them, such as escalation or monitoring. Assigning unassignable risks to the PM by default hides them.
Who owns items after go-live?
Open items transfer with the handover — usually to service or operations ownership, recorded in the closure and handover documentation rather than left in the project log.
Does the sponsor own anything in the log?
Typically items requiring funding, a scope decision, or authority over another part of the organisation. Those are escalated to them and recorded with their name.