---
title: How to Make a RAID Log Slide in PowerPoint (Consulting Style)
description: Build a RAID log slide in PowerPoint that survives a week with 8 risks and 1 dependency instead of locking in four equal boxes.
image: https://www.advis-io.com/hubfs/blog-key-visuals/153-raid-log-powerpoint.en.kv.png
---

[![logo\_transparent-Apr-12-2025-09-23-39-9623-AM-1](https://www.advis-io.com/hubfs/logo_transparent-Apr-12-2025-09-23-39-9623-AM-1.svg)](https://www.advis-io.com/en/?hsLang=en)

- [BLOG](https://www.advis-io.com/blog?hsLang=en)
- [ABOUT](https://www.advis-io.com/about?hsLang=en)

[CREATE SLIDES](https://marketplace.microsoft.com/en-us/product/advisioinc1760912844242.advisio-202604?tab=Overview)

Consulting Slides

# How to Make a RAID Log Slide in PowerPoint (Consulting Style)

Build a RAID log slide in PowerPoint that survives a week with 8 risks and 1 dependency instead of locking in four equal boxes.

[Advisio Editorial](https://www.advis-io.com/en/blog/author/advisio-editorial)

 Oct 18, 2026

---

A RAID log slide only has four categories — Risks, Assumptions, Issues, Dependencies — so it looks like the easiest status-update slide in the deck to build: one four-column grid, drop the week's items in, done. It breaks for a specific, predictable reason. RAID items are never evenly distributed across the four categories, and a grid built before anyone knows the real split locks in a box size that fits none of them. A week with eight open risks, three assumptions, two issues, and one dependency needs a layout where the Risks column runs most of the way down the slide while the Dependencies column is barely a third of that — not four equal boxes with Risks overflowing into six-point type while Dependencies sits mostly empty next to it. The fix is the same one that works for any uneven status grid: size each column to its own item count after the count is final, not before, and keep the columns independent enough that next week's reshuffle is a drag-and-drop instead of a rebuild.

## A Week 3 Steering Committee RAID Log, As It Actually Came Back

This is the log from week three of a mid-size ERP migration, the kind of program that runs a weekly steering committee slide almost by default. Risks: eight open items, including a vendor's data-migration tooling not yet certified against the target environment, two key integration engineers also staffed on a separate go-live, a cutover weekend that overlaps a public holiday, and a change-freeze window that's three days shorter than the test team originally planned for. Assumptions: three, including that the legacy system's transaction volume stays within its current range through cutover. Issues: two, including a test environment that's been running roughly 40% slower than production since a mid-week infrastructure change nobody has fully explained yet. Dependencies: one — sign-off from a third-party payroll vendor on a data-mapping spec, due before the next test cycle can start.

Built as four equal columns, that log is unreadable in two directions at once. Eight risk items, each with a one-line description and an owner name, run past the bottom of a column sized for three or four. Someone shrinks the font to 10 points to force them in, then shrinks it again when a ninth risk gets added at the Tuesday review. The Dependencies column, meanwhile, has one item sitting alone in a box exactly as tall as the overflowing Risks column next to it — which reads, at a glance, like dependencies are being tracked with the same rigor as risks, when in fact there's one line of actual content there.

## Why an Even Split Was Never the Right Default

Three things drive the imbalance, and none of them are mistakes in how the log was kept — they're just how RAID logs behave.

**The four categories don't fill at the same rate as a program moves through its phases.** Early in a program, almost everything worth tracking is a risk or an assumption — nothing has happened yet, so there's nothing to log as an issue. By cutover week, that flips: risks that didn't get mitigated in time convert into issues, assumptions either held or got retired, and the Issues column, nearly empty in week one, is often the fullest column by the week that matters most. A grid built once, at kickoff, for the week-one balance is guaranteed to be wrong for the week-twelve balance.

**A RAID item isn't just a label — it carries an owner, an impact rating, and often a one-line mitigation or next step, and those sub-fields vary in length as much as the item count does.** The vendor-tooling risk above needs three lines to state the risk, name the owner, and note the mitigation in progress. The transaction-volume assumption needs one. A column sized purely by counting rows, ignoring that some rows are three times taller than others, will still overflow even when the item count looks reasonable on paper.

**Items migrate between categories, and a RAID log is the one status artifact where that migration is the point.** An Eisenhower Matrix card might get reclassified from one quadrant to another; a RAID item does something more specific — a risk that materializes stops being a risk and becomes an issue, and a reviewer who tracked that risk for six weeks wants to see the connection, not a brand-new issue with no history. A layout that treats each column as a disconnected list loses that trace the moment an item crosses the boundary.

This is also where a RAID log earns its name over a plain risk register: a risk register tracks one category in more depth — probability, impact score, mitigation owner, review date — while a RAID log trades that depth for breadth, putting risks next to the assumptions, issues, and dependencies they actually interact with on the same page. The layout problem below is specific to that four-category breadth; a single-category risk register with ten columns of detail is a different slide with a different fix.

## Building the Grid So an 8-3-2-1 Split Doesn't Break It

The construction treats each of the four categories as an independent, growable container, not a cell in a shared table.

**Step 1 — Fix column count and width, not height.** Four columns, equal width, one per category, with header bars in distinct colors — a light red for Risks, pale blue for Assumptions, amber for Issues, gray for Dependencies. Column width communicates nothing about item count, so it should stay identical across all four. Height is the variable that's going to move.

**Step 2 — Give every item a stable ID, assigned once and never reused.** R1 through R8 for this week's risks, A1 through A3 for assumptions, I1 and I2 for issues, D1 for the dependency. This is the step most RAID templates skip, and it's the one that makes category migration legible instead of lossy: when risk R4 (the vendor tooling risk) materializes into an issue the following week, the new issue card reads "I3 (from R4)" instead of showing up as an unexplained new line with no connection to six weeks of risk tracking.

**Step 3 — Size each item's card to its own content, then stack cards to get column height.** A card with a one-line description and an owner name needs about 0.4 inches at 11-point type. A card with a three-line mitigation note needs closer to 0.9 inches. Sum each column's card heights, add a small gap (0.08 inches) between cards and a fixed header allowance, and that's the column's actual height — not a guess, not a template default. In the week-three example, Risks comes out around 5.5 inches tall; Dependencies comes out around 0.6 inches. Let them be that different.

**Step 4 — Anchor all four header bars to the same top edge; let the bottoms fall where the content puts them.** This is the single move that keeps a wildly uneven grid from looking broken instead of just looking honest. A flat top edge with a jagged bottom — Risks running two-thirds of the way down the slide, Dependencies stopping after one card — reads as "this is what the week actually looked like," the same way it does on a [balanced scorecard slide](https://www.advis-io.com/en/blog/balanced-scorecard-powerpoint?hsLang=en) when one perspective carries six KPIs and another carries two.

**Step 5 — Group each column as one named object: "RAID\_Risks," "RAID\_Assumptions," "RAID\_Issues," "RAID\_Dependencies."** Select the header bar, every card currently inside it, and the background fill, then Ctrl+G. A column that gained a card since last week, or lost one because an item closed out, is a matter of adding or removing one shape inside its group and letting the group's height follow — not re-measuring three other columns that didn't change.

**A second color for severity, separate from the category color.** The header bars already carry one color code — red, blue, amber, gray — for which of the four categories a card sits in. Don't reuse that same color channel to also signal how bad an individual item is, which is the mistake that happens when someone tries to make a high-impact assumption "stand out" by turning its header red to match the Risks column. Instead, give each card a small 0.1-inch dot in its top-right corner on a separate red/amber/green scale for impact, independent of which column it's in. A Dependencies card can carry a red dot if the payroll vendor sign-off slipping would actually block cutover; a Risks card can carry a green dot if the risk is real but low-stakes. Two color channels doing two different jobs — category on the header, severity on the card — is what lets a reviewer scan for "what's actually dangerous this week" without that scan getting confused with "which list is this item in."

![Comparison diagram: a RAID log slide with four equal-height columns causing an eight-item Risks column to overflow into shrunken text while a one-item Dependencies column sits mostly empty, versus the same RAID log with each column sized to its own item count, stable IDs, and a flat top edge.](https://www.advis-io.com/hubfs/blog-figures/153-raid-log-powerpoint-fig1.en.png)

Figure: four equal-height RAID columns overflowing under an 8-3-2-1 split (top) versus columns sized to each category's own item count (bottom).

## Week 4: Three Risks Close, One Becomes an Issue, One Dependency Clears

The following Tuesday, the vendor confirms the data-migration tooling is certified — risk R4 closes, but not cleanly: it surfaces a smaller issue, the migration tooling flags about 2% of legacy records as needing manual remediation before cutover. Two other risks close outright as their mitigations land. The payroll dependency, D1, clears when the vendor signs off. Net result: Risks drops from eight to five, Issues grows from two to three, Dependencies drops from one to zero for the week.

Because every column is its own named group and every item carries a stable ID, updating the slide is three drag operations and one group-resize, not a rebuild. R4's card moves out of the Risks group, gets relabeled I3 "(from R4)," and drops into the Issues group, which grows by one card's height. Two more cards delete out of Risks, which shrinks. D1 deletes out of Dependencies, which — for this week — is an empty column with just its header bar showing, which is itself useful information: a reviewer sees at a glance that nothing is currently blocking on an external party, rather than wondering whether dependencies simply weren't tracked that week.

**A note from experience:** at a Big Four firm, I watched a PMO analyst rebuild this exact slide from a blank four-column table every single week of a nine-month program, because the previous week's file got treated as a reference to copy numbers from rather than a working file to edit. Measuring four columns by eye, every week, for nine months, is roughly the same total effort as building the grouped, ID-tracked version once and then spending ninety seconds a week moving cards between groups. The slide doesn't get easier to build by being simple-looking; a four-column grid with no internal structure is simple to describe and slow to maintain.

## Three Principles for Any Log-Style Status Slide

- **Size columns after the count is final, never before.** A RAID log, a decision log, a dependency tracker — any status artifact with categorical buckets and a changing item count breaks the same way under a fixed grid.
- **Track provenance when items can migrate between categories.** A stable ID system costs one extra column of discipline and saves a reviewer from re-litigating whether this week's issue is new or six weeks in the making.
- **An empty column is a finding, not a formatting problem.** Don't pad a thin column to match its neighbors' height — a Dependencies column with nothing in it this week is telling the steering committee something real.

## What to Build Before Next Week's Steering Committee

If this week's RAID log is still a four-equal-box table, the fix doesn't wait for a slower week. Set up the four named groups now, even while the log is short enough to fit comfortably — it costs nothing extra today and means next week's reshuffle, whatever it looks like, is a few seconds of dragging cards between groups instead of a redraw. Assign IDs to this week's items even if nothing has migrated yet; the ID is what makes next month's migration traceable, and it's much easier to assign before the log has forty items of history than to retrofit after. And resist the one-time urge to even out the columns by padding the short one — a steering committee reading an honest 8-3-2-1 split learns more about where the program's actual pressure sits than one reading four tidy, equal-looking boxes.

[Advisio](https://www.advis-io.com/?hsLang=en), listed on [Microsoft AppSource](https://marketplace.microsoft.com/en-us/product/advisioinc1760912844242.advisio-202604?tab=Overview), builds the RAID grid directly from this week's actual item list as native, editable PowerPoint shapes — sizing each column to its own count and content length and keeping the header row anchored, so a log that goes from 8-3-2-1 to 5-3-3-0 the following week is a resize, not a rebuild. It fits the same weekly cadence as the [100-day plan slide](https://www.advis-io.com/en/blog/100-day-plan-slide-powerpoint?hsLang=en) most steering committee decks carry right next to it.

[Consulting Slides](https://www.advis-io.com/en/blog/tag/consulting-slides) [Slide Design](https://www.advis-io.com/en/blog/tag/slide-design)

## Similar posts

![logo\_white-1](https://www.advis-io.com/hubfs/logo_white-1.svg)

Transform your business data into actionable insights with AI-powered analytics. Get consultancy-grade presentations in minutes, not weeks.

N&E Building, 6th Floor  
1-12-4 Ginza, Chuo-ku  
Tokyo 104-0061  
Japan

[contact@advis-io.com](mailto:contact@advisio.com)

 

<https://x.com/advis_io><https://www.linkedin.com/company/advisio1/><https://www.facebook.com/people/Advisio/61573197194211/>

- [Blog](https://www.advis-io.com/en/blog)
- [About Us](https://www.advis-io.com/en/about?hsLang=en)
- [問い合わせ](https://www.advis-io.com/contact?hsLang=en)
- [特定商取引法に基づく表記](https://www.advis-io.com/jacommercialtransaction?hsLang=en)
- [利用規約](https://www.advis-io.com/terms?hsLang=en)
- [プライバシーポリシー](https://www.advis-io.com/privacy-policy?hsLang=en)

© 2026 Advisio Inc. All rights reserved.

[Powered by Atlas - a B2B SaaS HubSpot theme](https://www.kalungi.com/atlas-hubspot-theme-for-b2b-saas-software)

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Advisio Editorial",
    "url" : "https://www.advis-io.com/en/blog/author/advisio-editorial"
  },
  "dateModified" : "2026-10-18T22:45:42.816Z",
  "datePublished" : "2026-10-18T22:45:42.000Z",
  "headline" : "How to Make a RAID Log Slide in PowerPoint (Consulting Style)",
  "image" : [ "https://www.advis-io.com/hubfs/blog-key-visuals/153-raid-log-powerpoint.en.kv.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://www.advis-io.com/en/blog/raid-log-powerpoint",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://www.advis-io.com/hubfs/logo.svg"
    },
    "name" : "Advisio株式会社"
  }
}
```