How to write a risk or issue in a RAID log

No. Change the type on the same record so the history stays attached: the original cause, the decide-by date, the response you chose and the date it converted. Probability stops applying, because the event has happened, so the value at risk becomes the exposure. Raising a fresh item hides how long you knew, which is the part worth learning from at roadmap close.

Ask how often this has happened to you before in similar circumstances, and start there. Estimate in tens, get a second person to write a number down independently before either of you speaks, and take the higher one if they disagree by more than twenty points. You are not trying to be right to the percentage point. You are trying to rank this item honestly against the other things on the log.

Keep the colour as a presentation layer and derive it from the exposure, for example red above a set share of the outcome's target, amber above a lower one. Nobody argues about a band that a formula produced. Reporting rules of this kind sit inside the target operating model Tenhaw's founder co-led at HSBC Global Payment Solutions, designed and piloted for 500 teams, with global rollout due in 2026 and not yet rolled out. What you should not do is store the colour as the underlying record, because then the number that lets you rank and compare no longer exists.

Small enough to review every open item at roadmap close in an hour, and if it is bigger than that, the entry bar is too low. Items with an exposure under a couple of percent of the outcome target are recorded and left alone rather than managed, and anything that is work with an owner and a date belongs in the backlog instead.

The test is whether the damaging event has happened yet. A risk is something that might reduce an outcome's value or move its date; an issue is something already costing you time, money or scope. Both are written the same way, as one sentence of cause, event and consequence, attached to one epic, priced in currency and owned by one named person. The distinction matters because probability only applies to a risk. Once the event happens, the value at risk simply becomes the exposure. Check it is neither before you log it: a defect in shipped work is a bug, a shortcut that slows you later is tech debt, and something another team owes you on a date is a dependency.

Write one sentence in three parts: because of a cause someone could verify today, an event may happen, which would have a stated effect on the epic's value or its date. For an issue the tense changes, so the sentence becomes because X, Y has happened, and it is costing Z. The cause must be a checkable fact, not a feeling, and noun titles like vendor risk or resourcing risk give a reader nothing to decide on. Test the sentence by reading it to someone outside the team, and rewrite it if they cannot tell whether the event has already happened or what it costs. A well-written item lets a stranger read it and act.

Multiply two numbers. Value at risk is the share of the epic's planned contribution actually threatened, which is rarely all of it. A one-quarter delay to a £400k epic exposes roughly a quarter of the annual benefit, so write £100k and record the assumption behind it so someone can argue with it. Probability is your honest estimate in tens, because 65% persuades nobody. The product of the two is the exposure, and it is what you sort the log by. Anything under a couple of percent of the outcome target gets logged and left alone, which keeps attention on the handful of items that genuinely threaten the number. Tenhaw runs this arithmetic on its own engagements and publishes the method in full.

One named person, never a team and never a role, and usually not the person who spotted it. The owner is whoever can actually make the call, so if the response needs budget or a supplier conversation, it is the person holding the budget or the relationship. A risk owned by "platform" is owned by nobody, and it will be discussed for six weeks without resolution because no individual has been asked to decide. Give the owner a decide-by date as well, the last day on which a decision still changes the result, and if that date passes, record which default was taken and why.

Item by item rather than on a fixed cadence. Book each entry's review point at the moment you write it, or it gets reviewed when somebody happens to remember. Three tiers cover it: anything with a decide-by date inside two weeks joins the daily lookahead, anything threatening the value of a live outcome is tested at monthly outcome validation, where that number is being examined anyway, and everything else waits for roadmap close, where each open item is carried forward with a fresh decide-by date or closed with a reason. Count closures at roadmap close as well, since a log that closed fewer items than it opened all quarter is an archive, not a management tool.

Yes, and a healthy log uses it regularly. Accept is one of the four legitimate responses, alongside avoid, reduce and transfer. A mitigation that costs more than the exposure is not a mitigation, so price the response before you commit to it, and where the arithmetic does not work, accepting the risk is the honest call. Write the acceptance down and set a review point so the decision is revisited if the numbers move. A log where nothing is ever accepted is a log where everything is being quietly mitigated by nobody, which is how twenty amber items survive a whole quarter.

Pick the response and write it down: contain it, fix it, or replan around it. Then one next action carrying a name and a date, not three, because a list of five actions is a list nobody owns. Price the response before you commit, since a mitigation that costs more than the exposure is not a mitigation. At Tenhaw that call sits with James Rooney, who leads every engagement personally, because it usually needs budget authority. And make the escalation move a number rather than a colour. If the answer is to descope, cut the epic's planned contribution so the hole shows against the outcome's target and somebody has to own it. If nothing moved, what you sent was a status update.

Give it one of four closing reasons: the event happened, the event can no longer happen, you accepted it, or it was never real. Then add the line most logs skip, what became of the money that was exposed, recorded as landed, partly landed or lost. That second note is the only reason anyone reads the log next quarter, because the pattern across closed items shows which threats your organisation habitually underprices, and it earns its keep in exactly the cases where the answer is embarrassing. If you cannot name which of the four reasons applies, the item is not closed. It has just gone quiet.

Yes, that is what the A and the D of RAID are for, but classify each entry before you write it. Work another team owes you by a date is a dependency. A belief you are relying on and cannot prove is an assumption, and the day it turns out to be false you have a risk or an issue, whether or not it has cost you anything yet. Keep the neighbours out: a defect in shipped work is a bug and links to the quarter's Bug Budget epic, a shortcut that will slow you later links to the Tech Debt epic, and anything with an obvious owner that takes under a day is simply work.

No, log it once. Every item attaches to exactly one epic, and when a threat genuinely spans several it belongs on the outcome above them, raised once with the aggregate exposure. Cloning one risk across three epics counts the same money three times, so when you sort the log by exposure the top of the list stops meaning anything and the items that deserve attention get buried. That single link does other work too, putting the entry one step from a currency target and settling who reviews it and which quarter it sits in. With no live work to attach it to, it goes on the company-level log.

Work backwards from the release window and from roadmap close, rather than forwards from today. The decide-by date is the last day on which a decision still changes the result, so it depends on how long your chosen response takes to execute. In this guide's worked example a replacement payment sandbox needs six weeks to integrate and test, and the quarter's final release window falls mid-September, which puts decide-by at 8 August. Roadmap close is the second boundary, because an epic lives in one quarter and a decision taken after close has made itself. If the date passes with no answer, record the default you took and start the fallback.

Usually three habits have crept in together. Tasks are wearing risk labels. A line like "we have not hired a second tester" is a piece of work with an owner and a date, and it crowds out the two items that needed a decision from someone senior. Value at risk has been copied from the whole epic onto every item, which makes the log read as catastrophic and ranking impossible, so nothing gets prioritised. The response was never chosen, so the escalation stopped at a slide. Tenhaw runs the same test on itself, reporting a month that delivered no measurable value as a failed month. Check each open item. If raising it moved no date, scope or planned contribution, it was a status update.

About forty-five minutes for an entry that matters, and a real entry bar is what keeps that to a handful of items a quarter. Most of the time goes on the arithmetic behind value at risk, and on working out the one person who can genuinely make the call. Those are the two parts that pay. At Tenhaw this is work for the two or three senior people on the engagement. In this guide's worked example, a payment SDK deprecation spotted in week two is priced at £100k of value at risk at 60% probability, so £60k of exposure, which lands it second on a log of six and above the three items the team had talked about most. The return was nine weeks of warning.