[{"data":1,"prerenderedAt":299},["ShallowReactive",2],{"blog-\u002Fblog\u002Fraid-log-risks-assumptions-issues-dependencies":3,"blog-surround-\u002Fblog\u002Fraid-log-risks-assumptions-issues-dependencies":281,"blog-related-\u002Fblog\u002Fraid-log-risks-assumptions-issues-dependencies":289},{"id":4,"title":5,"audience":6,"body":10,"cluster":25,"date":249,"description":250,"draft":251,"extension":252,"faq":253,"featured":251,"language":263,"meta":264,"navigation":265,"order":266,"path":267,"pillar":268,"primaryKeyword":269,"relatedProject":263,"reviewCycle":270,"searchIntent":271,"seo":272,"stem":273,"tags":274,"type":279,"updated":249,"__hash__":280},"blog\u002Fblog\u002Fraid-log-risks-assumptions-issues-dependencies.md","RAID Logs: Managing Risks, Assumptions, Issues and Dependencies",[7,8,9],"engineering-manager","product-lead","finance-transformation-lead",{"type":11,"value":12,"toc":239},"minimark",[13,27,30,35,38,86,90,93,104,110,113,117,124,149,157,161,164,167,175,179,186,192,196,203,210,213,216],[14,15,16,20,21,26],"p",{},[17,18,19],"strong",{},"A RAID log is the single working record of a programme's Risks, Assumptions, Issues and Dependencies — the things that could knock delivery off course, each with an owner, a due date and a next action."," Done properly it's the instrument ",[22,23,25],"a",{"href":24},"\u002Fblog\u002Fgovernance-and-steering-for-finance-programmes","governance"," actually steers on. Done badly it's a beautiful register that gets updated the night before the steering meeting and forgotten the morning after — while the real risks live in people's heads and the real issues get worked in Slack.",[14,28,29],{},"I've kept RAID logs on finance-transformation programmes for eighteen years, and the difference between the ones that helped and the ones that didn't had nothing to do with the template. It came down to whether anyone worked the log, or just filed it.",[31,32,34],"h2",{"id":33},"what-the-four-letters-actually-mean","What the four letters actually mean",[14,36,37],{},"The letters look interchangeable. They aren't, and the distinctions are the whole point.",[39,40,41,57,67,80],"ul",{},[42,43,44,47,48,52,53,56],"li",{},[17,45,46],{},"Risk"," — something that ",[49,50,51],"em",{},"might"," happen. It has a probability and an impact, and you manage it by ",[49,54,55],{},"mitigating",": reducing the chance, reducing the damage, or both. A risk lives in the future and in the conditional.",[42,58,59,62,63,66],{},[17,60,61],{},"Assumption"," — something you've decided to treat as true ",[49,64,65],{},"unless proven otherwise",", because you can't confirm it yet and you need to keep moving. The danger is that it's silent. An assumption that quietly turns out false doesn't announce itself; it just detonates later as an issue.",[42,68,69,47,72,75,76,79],{},[17,70,71],{},"Issue",[49,73,74],{},"has"," happened and is affecting the work ",[49,77,78],{},"now",". It doesn't get a mitigation. It gets a resolution, an owner, and urgency.",[42,81,82,85],{},[17,83,84],{},"Dependency"," — something your work needs from someone or something else, usually outside your control: data from another team, a decision from a committee, an environment from IT, onboarding from a bank.",[31,87,89],{"id":88},"the-distinction-everyone-gets-wrong","The distinction everyone gets wrong",[14,91,92],{},"The one that costs real money is risk-versus-issue. A risk is future and probabilistic and gets a mitigation. An issue is present and certain and gets a resolution and a named owner. They are not two flavours of the same thing.",[14,94,95,96,99,100,103],{},"Here's the failure I've watched happen more times than I can count: a live problem gets logged as a \"risk.\" It's already true — the data migration is already failing, the interface is already rejecting records — but calling it a risk makes it feel less alarming, so onto the risk register it goes. And risks get ",[49,97,98],{},"watched",". Issues get ",[49,101,102],{},"worked",". The moment you file an issue as a risk, you've taken something that needed an owner and a fix this week and turned it into a line item somebody glances at monthly.",[105,106,107],"pull-quote",{},[14,108,109],{},"A risk is something that might happen and gets a mitigation. An issue is something that already happened and gets a resolution. Log an issue as a risk and you've quietly decided nobody owns it.",[14,111,112],{},"If it's already true, it's an issue. Promote it out of the maybe column and give it a name.",[31,114,116],{"id":115},"every-entry-needs-three-things","Every entry needs three things",[14,118,119,120,123],{},"A RAID log is a ",[49,121,122],{},"working instrument",", not a register you populate for the deck. Every single entry — risk, assumption, issue or dependency — needs three fields that most logs treat as optional and shouldn't:",[39,125,126,137,143],{},[42,127,128,131,132,136],{},[17,129,130],{},"An owner."," One person, not a team. A risk owned by \"Finance\" is owned by ",[22,133,135],{"href":134},"\u002Fblog\u002F07-cost-of-unclear-ownership","no one",", and it will sit there un-mitigated until it becomes an issue.",[42,138,139,142],{},[17,140,141],{},"A due date."," The date the next action happens or the item is reviewed. No date means no urgency means it never moves.",[42,144,145,148],{},[17,146,147],{},"A next action."," Not the risk restated — the specific next thing someone is going to do about it. \"Risk: vendor may miss the connectivity deadline\" is not an action. \"Chase written commitment from vendor PM by Friday\" is.",[14,150,151,152,156],{},"An entry without those three is decoration. This mirrors the discipline that starts at ",[22,153,155],{"href":154},"\u002Fblog\u002Fproject-intake-process-for-finance-and-engineering-teams","intake",": a thing without an owner and a next action isn't being managed, it's being noted.",[31,158,160],{"id":159},"dependencies-the-silent-killer-of-finance-programmes","Dependencies: the silent killer of finance programmes",[14,162,163],{},"If I had to point at the single column that sinks finance programmes, it's the D. Risks you can mitigate and issues you can fix, but a dependency is by definition the part of your timeline you don't control.",[14,165,166],{},"Think about what a finance-systems programme actually waits on. Bank onboarding on the bank's schedule, not yours. Reference data from another team that has its own backlog and no reason to prioritise you. A go\u002Fno-go from a committee that meets monthly. A test environment from IT that's three tickets deep. You can run your own workstream flawlessly and still miss the date, because the critical path runs straight through work that isn't yours.",[14,168,169,170,174],{},"This is why connectivity and cross-team data are almost always the real critical path — and why dependencies bite hardest near ",[22,171,173],{"href":172},"\u002Fblog\u002Fcutover-and-go-live-for-finance-systems","cutover",", when every deferred dependency comes due in the same fortnight. A dependency logged in month one with an owner and a chase date is a dependency you can escalate while there's still time. A dependency nobody owned is the reason the go-live slips, discovered the week it was needed.",[31,176,178],{"id":177},"how-the-log-connects-to-governance","How the log connects to governance",[14,180,181,182,185],{},"The RAID log is the natural agenda for a steering committee — because the items on it are precisely what steering exists to steer. When a risk needs a decision above the team's authority, or an issue needs a blocker cleared, or a dependency needs someone senior to lean on another function, the RAID log ",[49,183,184],{},"is"," the escalation path.",[14,187,188,189,191],{},"That's the join with ",[22,190,25],{"href":24},": the team works everything it can own, and everything that exceeds its authority becomes an escalation the steering committee actually resolves. A steering meeting that reviews a RAID log without deciding anything is the status theatre I've written about elsewhere. A steering meeting that clears three blocked dependencies is governance doing its job.",[31,193,195],{"id":194},"docs-versus-reality","Docs versus reality",[14,197,198,199,202],{},"Here's the honest failure mode, and I've been on both sides of it. The RAID log is maintained beautifully — colour-coded, RAG-rated, immaculate — for the monthly deck. Meanwhile the risks people actually lose sleep over were never written down, because saying them out loud felt political. The real issues are getting worked in a Slack thread that never touches the log. And the assumptions that will hurt you are the ones nobody flagged as assumptions at all — they were just ",[49,200,201],{},"what everyone thought was true",".",[14,204,205,206,209],{},"A risk logged and never mitigated is not risk management. It's a paper trail for the post-mortem — proof that someone saw it coming and did nothing. The test of a RAID log isn't whether it's complete. It's whether anything on it ",[49,207,208],{},"changed"," since last time: an owner chased a dependency, a mitigation dropped a probability, an issue got resolved and closed. If the log looks the same month after month, it isn't managing your programme. It's watching it.",[14,211,212],{},"Keep it small, keep it owned, and work it every week. A RAID log earns its place the moment it stops being a document and starts making someone do something before the date it was due.",[214,215],"hr",{},[14,217,218],{},[49,219,220,221,225,226,229,230,233,234,238],{},"Part of the ",[22,222,224],{"href":223},"\u002Ftopics\u002Ffinance-systems-delivery","Finance Systems Delivery guide",". See also ",[22,227,228],{"href":24},"governance and steering for finance programmes"," and ",[22,231,232],{"href":134},"the cost of unclear ownership",". The ",[22,235,237],{"href":236},"\u002Fnewsletter","newsletter"," sends one finance-systems pattern every two weeks.",{"title":240,"searchDepth":241,"depth":241,"links":242},"",2,[243,244,245,246,247,248],{"id":33,"depth":241,"text":34},{"id":88,"depth":241,"text":89},{"id":115,"depth":241,"text":116},{"id":159,"depth":241,"text":160},{"id":177,"depth":241,"text":178},{"id":194,"depth":241,"text":195},"2026-07-24","A RAID log tracks a programme's risks, assumptions, issues and dependencies — and works only when you actually mitigate and chase them, not file them.",false,"md",[254,257,260],{"question":255,"answer":256},"What is a RAID log?","A RAID log is a single working record of a programme's Risks, Assumptions, Issues and Dependencies. Each entry carries an owner, a due date and a next action, and the log is reviewed and worked on a regular cadence. Its purpose is to keep the things that could derail delivery visible and owned — not to produce a tidy register for the steering deck. A RAID log that's only updated before a status meeting isn't managing anything; it's documenting it.",{"question":258,"answer":259},"What is the difference between a risk and an issue?","A risk is something that might happen — it has a probability and an impact, and it gets a mitigation to reduce one or both. An issue is something that has already happened and is affecting the work now — it gets a resolution and an owner, urgently. The distinction matters because logging a live issue as a 'risk' is how it quietly goes unowned: risks get watched, issues need working. If it's already true, it's an issue, and treating it as a maybe is how it drifts.",{"question":261,"answer":262},"Why do dependencies sink projects?","Because dependencies are the things your work needs from someone or something outside your control — data from another team, a decision from a committee, an environment from IT, onboarding from a bank — and their timelines aren't yours to set. You can run your own workstream perfectly and still miss the date because a dependency you flagged in month one didn't land. In finance programmes, cross-team data and external connectivity are usually the critical path, and they bite hardest near cutover.",null,{},true,9.5,"\u002Fblog\u002Fraid-log-risks-assumptions-issues-dependencies","finance-systems-delivery","RAID log","annual","informational",{"title":5,"description":250},"blog\u002Fraid-log-risks-assumptions-issues-dependencies",[275,276,277,25,278],"delivery","raid-log","risk-management","finance-systems","text","TABivLpNbJl_IfkaqeqLJM0EMPmv_UZ4O1sSr4ZRkpo",[282,285],{"title":283,"path":154,"stem":284,"type":279,"language":263,"draft":251,"children":-1},"Project Intake Process for Finance and Engineering Teams","blog\u002Fproject-intake-process-for-finance-and-engineering-teams",{"title":286,"path":287,"stem":288,"type":279,"language":263,"draft":251,"children":-1},"Real-Time Treasury: What It Actually Means","\u002Fblog\u002Freal-time-treasury","blog\u002Freal-time-treasury",[290,293,297],{"path":24,"title":291,"description":292},"Governance and Steering for Finance Programmes","Programme governance steers a large finance-systems programme — the decision structure, cadence and escalation. Good governance keeps a big programme unblocked.",{"path":294,"title":295,"description":296},"\u002Fblog\u002Fagile-vs-waterfall-for-finance-systems-delivery","Agile vs Waterfall for Finance-Systems Delivery","How to choose a delivery approach for finance systems — why pure agile strains against a hard cutover, and why a hybrid spine usually wins.",{"path":154,"title":283,"description":298},"How a team receives, shapes and decides on incoming work before committing people — the stages, the fields that matter, and four honest decisions.",1784914211622]