RAID Log

What this tool does

CM8-69 is a working RAID log: one register for the risks, assumptions, issues and dependencies on a project or programme. It scores each type the way that type should be scored, bands them, tracks the action to a target date, flags what has slipped, and prints a report you can take into a steering group without reformatting anything.

It runs inside this single file. There is no account, no upload and no network request of any kind, so supplier names, cost exposures and the things going wrong on your project stay on the computer you are using.

The four letters

Most RAID logs go wrong because entries are filed under the wrong letter. The test is about time and certainty, not about how worried you feel.

• Risk — it has not happened. It might. If it does, it hurts. A risk has a probability and an impact, and something you can do about it now.
• Assumption — something the plan treats as true that nobody has proved. Assumptions are quiet until they fail, at which point they become issues. Record who is going to prove it and by when.
• Issue — it has happened. It is happening now. Probability is no longer a question; the only questions left are how much damage it is doing and who is fixing it.
• Dependency — something outside your control has to land for your plan to work: another project, a supplier, a landlord, a regulator, a piece of somebody else's budget.

Two habits keep a log honest. When a risk happens, mark the risk realised, close it, and raise a separate issue — do not quietly edit the risk into an issue, because you lose the history of how long you saw it coming. When an assumption is disproved, close it and raise the risk or the issue it created.

Why an issue is not a risk

This is the single most common error in RAID logs, and it is worth being blunt about. People give an issue a probability score — usually 5, sometimes 3 because "it is not that bad" — multiply it by the impact, and put the result in the same column as the risk scores. Everything is then ranked together and the ranking is meaningless.

An issue has already happened. Its probability is one: certainty. Multiplying a certainty by an impact does not produce a comparable exposure, it produces the impact with a decorative multiplier attached. So this tool refuses the probability field on anything that is not a risk, and scores issues, assumptions and dependencies on impact alone.

The consequence is that a risk score of 16 and an issue score of 4 are not comparable numbers. One is out of 25, the other out of 5. The tool prints the scale next to every score for exactly this reason, and the ranked chart shows risks only. Where the top-scoring table has to mix the types, it orders by severity band first, and within a band by the score as a proportion of its own scale — an ordering, not a common currency.

Scoring

Both scales run 1 to 5. Probability: 1 rare, 2 unlikely, 3 possible, 4 likely, 5 almost certain. Impact: 1 negligible, 2 minor, 3 moderate, 4 major, 5 severe — judged against whichever of cost, schedule, scope or quality it would hit hardest, not against all four averaged.

Assumptions and dependencies get impact alone as well. If you find yourself wanting to score how likely an assumption is to be wrong, that is the log telling you it is no longer an assumption — raise it as a risk, where probability belongs, and leave the assumption pointing at it.

Score the impact after the mitigation you have actually put in place, not before, and re-score it when the mitigation lands. A log full of pre-mitigation scores never improves and stops being read.

Severity bands

The band is what people read in a steering group; the number is what you argue about beforehand. Risk bands come from thresholds you set on the Settings tab — 15, 10 and 5 by default:

The three thresholds are sorted before use, so entering them out of order cannot produce a nonsense band. The thresholds apply to the 1–25 risk score only: there is nothing meaningful to threshold on a 1–5 impact scale, so those bands are fixed. Treat the bands as a triage aid within each type, not as a common currency between types.

Choosing a response

A response strategy belongs to a risk, because it is a choice about an event that has not happened yet. The tool requires one on every risk and refuses one anywhere else.

• Avoid — change the plan so the risk cannot arise. The only response that removes it.
• Reduce — cut the probability, the impact, or both. The most common, and the one that needs a named action with a date, or it is really "accept" in disguise.
• Transfer — move the exposure to somebody better placed to carry it: a contract term, a warranty, an insurance policy. Transfer moves the cost, rarely the disruption.
• Accept — carry it knowingly, with a contingency in the budget or the plan. A legitimate answer, but only when it is a decision somebody made rather than a box nobody filled in.
• Exploit — an upside risk you want to make happen. Opportunities belong in a RAID log too, and they are usually the first thing dropped when it gets busy.

Owners, targets and overdue

Every entry takes an owner, a target date for the action and a status. The owner should be one named person. A team name in the owner column means nobody, and the entries-by-owner chart is there to show you when one person is quietly carrying half the register.

Days open counts calendar days, not working days, and it deliberately keeps running on entries nobody has touched. An entry open longer than the ageing threshold on the Settings tab is marked in the top-scoring table. Entries with no target date at all are worth hunting: they never appear as overdue, so they never appear on anybody's list.

Statuses are open, in progress, closed and realised. Realised is for a risk that happened, and the tool will not let you use it on the other three types. Closing an entry needs a date — that date is what makes the average time-to-close and the raised-versus-closed chart mean anything.

Cost and schedule impact

Two separate fields, deliberately never combined. Cost impact is money: what it would cost if the risk happened, or what the issue has cost already. Schedule impact is working days added to the critical path.

The tool will not turn days into money for you: the rate at which slip converts to cost is specific to your contract, your team and your penalty clauses, and adding days to currency is how a headline figure becomes indefensible. The tile shows both separately, with the number of entries that carry a cost estimate at all, so nobody reads a total built from four of forty entries as a programme exposure.

That total sums risks and issues together, mixing a possible cost with one already incurred — a deliberate simplification for the headline, so filter by type before quoting either on its own. A negative cost records an upside: the saving an exploited opportunity would produce.

Reading the charts and tables

Open risks by score ranks live risks only, coloured by band, with the probability and impact printed on each bar so the score can be challenged.

Raised and closed by month stacks two counts in one bar. The bar height is the two added together and means nothing on its own — read the segments. Months where raised keeps beating closed are months when the log is running away from you.

Summary by type gives the average age of open entries and the average days to close, calculated on different populations and shown in separate columns for that reason. An average time to close of four days against an average open age of ninety says you close the easy ones and leave the rest.

Running the review

A RAID log is a meeting artefact, not a document. Review it weekly on a live project, fortnightly at a minimum, and do four things each time: close what is done, re-score what has changed, chase what is overdue, add what has appeared since. Ten minutes on the top five beats an hour reading all forty.

Filter to one type or one status before the meeting so the screen shows what is being discussed. The filter in force is printed on the report, so the scope of what you circulated is never in doubt.

What this tool cannot do

It cannot tell you whether a score is right. Probability and impact are judgements, and two competent people will often differ by a point; the value is in the conversation the number forces, not in the number.

It cannot find the risk nobody wrote down, which is nearly always the one that lands. It does not model correlations between entries, run a schedule simulation, or produce a contingency figure. It does not know your critical path, so a schedule impact of ten days is ten days you have estimated, not ten days it has calculated. And it does not chase anybody: the overdue flag is a prompt for a person, not an escalation.

Printing and sharing

Print Report builds a report from whatever the current filter shows: header, the six headline figures, all four charts, the top-scoring entries, the summary by type, the full register and your closing notes. Print to PDF to circulate it. The scope line under the title states the filter in force and how many of your records are included — clear the filters before issuing anything described as the whole log.

Saving your work

Entries, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window, a second machine or a tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the register for spreadsheet work and includes every filtered record, not only those drawn on screen. Reset asks twice, then erases everything this tool has stored. There is no undo.

Accuracy & disclaimer

This tool records what you enter and calculates from it. It cannot tell whether an entry is filed under the right letter, whether a score is realistic, whether an owner has agreed to own it, or whether a cost estimate has any basis — and every figure on the screen depends on all four.

It is a project record-keeping and scoring aid. It is not a risk-management methodology, not a contractual record, and not a substitute for the governance your project is run under. Where a contract, a funder or a regulator prescribes a particular scoring scale or reporting format, use theirs.