Nine columns and a Monday morning. What a RAID log can do.

The log everyone keeps

Every project that touches a customer has one. An ID, a type, a title, a description, an owner, a due date, a status, and a couple of yes or no flags.

It is a good log. The trouble is Monday.

Before every review, someone opens the spreadsheet and rebuilds the picture by hand. What slipped. Who owes what. What is waiting on the customer. What changed since last week. Then it gets copied into slides.

That work happens every week, on every project, and it tells the team nothing the log did not already know.

What we built

We started from a blank nine-column template and kept it as it is. No new columns. Then we filled it with 34 invented items for a made-up Workday deployment: in the middle of testing, 105 days from go-live.

• The review order is set before the meeting. Items overdue two reviews running come first, then the rest of what is late, then items with no owner, anything due today, and what the customer owes.
• Who owns the next move. Every open item is with the customer, with your team, or not yet triaged. The oldest customer asks sit right underneath, with one button that copies the list for their side.
• One click for the status report. The customer-facing report comes from the same rows. Nothing gets copied into slides.
• Every number opens. Tap a count, a name or a cell and the log filters to the items behind it.

The part a spreadsheet does not show you on its own

A spreadsheet shows you this week. So the review keeps last Monday's copy of the log and compares the two.

What is new. What closed. What moved to the customer. Whose due date slipped. What is still waiting. And the one that matters most when leadership asks: what was overdue last week and is still overdue now.

Then we tried to break it

A demo that only looks good to the person who built it is not finished. So before anyone saw it, it went through three review passes.

• Read the way a senior Workday project manager would. That pass found a test plan that ran backwards, with a payroll parallel run before end-to-end testing was even scheduled, three items that ignored a January go-live, and raw defects logged as project issues. All fixed.
• Every sentence checked against what the screen actually does. Fourteen sentences said more than the page could back up. Each one was rewritten until it was true.
• Checked for a phone and a keyboard. Dots that overlapped at phone width, labels too faint to read, controls a keyboard could not reach, and a print button that printed a blank page. All fixed.

That part never shows up in a screenshot. It is the reason the screenshots can be trusted.

What this means if you run projects

The best place to start is usually the thing your team already keeps. Not a new platform. The log, the tracker, the sheet that gets rebuilt every week.

We build the review around how your team actually runs, for a fixed price agreed before the work starts. Your data stays where you decide it lives.