Kim Essendrup argues that most projects don’t fail because teams missed some advanced method. They fail because the basics—risks, actions, issues, and decisions—weren’t managed well.

His answer is a simple tool: the RAID log, and a simple question to start with any project: “Show me your RAID log.”

Project Management is Hard, and Basics Cause Failure

Essendrup draws on years of work as a project manager, PMO leader, consultant, and podcast co‑host. He talks regularly with project managers and PMO leaders in all kinds of organizations—large, small, public, private—and sees two things clearly:

• Project management is hard because project managers are “change makers.” Their job is to break the status quo and create something new.

• Projects usually go wrong because of the basics, not because someone skipped PERT, earned value, or a 1,500‑line plan. The problems are unmanaged risks, unresolved issues, lost action items, and weak decisions.

His goal in this talk is to give a practical tool to manage those basics and help projects stay on track.

A Project Disaster in the UK

To illustrate, Essendrup tells a story about taking over a professional services PMO for a global IT integrator in Europe.

A few weeks into the job, he got the classic bad‑news call late on a Friday. A project in the UK Midlands had gone so far off the rails that the customer had sent a legal letter terminating the project and billing the company about $100,000 for the “pain and suffering” caused.

As PMO leader, he was told, “This is your problem. Sort it out.”

By Monday morning he was in a conference room in the UK, drinking the worst coffee he’d ever had and being berated by the customer’s executives.

They sat on one side of a long table and explained all the ways his company had failed them—missed deliverables, broken promises, general disappointment.

As he listened, he thought, “I’d be mad too.”

When they finished, he turned to his own team on the other side of the table and asked what happened. They immediately pushed back.

This was the worst customer they’d ever had; the client had set them up for failure and done everything possible to make sure the project failed.

After tempers cooled, Essendrup asked both sides a simple question: could they show him their RAID log?

The customer had no answer. His own team had no answer either.

He couldn’t tell whether they didn’t know what a RAID log was, or knew exactly what it was and were embarrassed they didn’t have one.

So he opened his own laptop, plugged into the projector, pulled up a RAID log, and said, “Let’s begin.”

What a RAID log is

Essendrup defines RAID as an acronym for:

• Risks

• Actions (or action items)

• Issues

• Decisions

He notes that some people use slightly different words such as assumptions or dependencies, and that a RAID log can be extended with tabs for lessons learned, change requests, stakeholders, calendars, key contractual milestones, external dependencies, and more.

For him, though, the important point is that it is more than four separate logs stuck together. Used well, it becomes a small “sub‑methodology” for:

• Keeping the project on track

• Course‑correcting when things go wrong

• Capturing the most important lessons about what happened, where the project could have gone wrong, how the team responded, and what decisions were made

He argues that some of the most valuable lessons learned from any project are not about whether the plan or budget was slightly off, but about the risks, issues, and decisions that shaped the outcome.

Why Bother with Another Tool?

Essendrup acknowledges that project managers are busy. They manage schedules, budgets, meetings, tools, and now even AI. So why add a RAID log on top?

Because, he says, projects go wrong for the very reasons RAID logs exist:

• Unmanaged or forgotten risks

• Issues that spin out of control

• Action items that fall through the cracks

• Decisions that are slow, poorly made, or undocumented

RAID logs sit:

• In the planning phase (thinking ahead about what could go wrong)

• In ongoing planning (adjusting as you learn)

• In day‑to‑day operations (keeping a handle on what’s happening now)

He pushes back against the idea that “if I just plan better, I won’t need this.” To him, plans always get “punched in the mouth,” and the profession of project management exists because reality doesn’t follow even the best plan.

---

Agile or not, the Problems are the Same

Essendrup says that when he talks about RAID logs, someone will sometimes respond, “We work agile; we don’t do that stuff.” His answer is simple: do you ever have things go wrong? Then you have issues. If there are issues, there are risks. Do you ever have action items that don’t belong in your backlog? Do you ever make decisions? Do you have dependencies?

If the answer is yes—and it usually is—then you already have RAID‑type content in your work. In other words, RAID management is relevant regardless of whether a team uses more waterfall or more agile approaches. The work still produces risks, actions, issues, and decisions.

Four Core Elements

Risks

He encourages teams to think about risks in a grounded way. You can go very deep with quantitative analysis, Monte Carlo, and similar methods, but the essential work is to pause and ask:

• Where can this train go off the rails?

• How will we keep it from going off the rails?

**Risk thinking should include upside opportunities, not just negative threats.

Actions

He differentiates action items from formal project tasks. Action items often come out of meetings: follow‑ups, small tasks, checks, and clarifications. These usually don’t belong in the main schedule or backlog, and project managers have long, messy to‑do lists that are easy to lose track of.

By keeping these lighter, meeting‑driven tasks in a separate action log inside the RAID file, a project manager can track them centrally without constantly re‑baselining the formal plan.

Issues

Essendrup points out that nobody finishes handling an issue and says, “I’d like to do that again.” But the issue log serves two key purposes:

• While an issue is active, it gives the team a central place to coordinate resolution, remediation, and root‑cause analysis.

• After the project, it helps explain why the project ended where it did. If the project misses schedule, budget, or deliverables, there should be a chain of issues that tell the story of what happened.

That story matters for accountability—for everyone involved and for the project manager trying to explain the outcome.

Decisions

Decisions are Essendrup’s favorite part of the log. He notes that project managers often don’t get to make the most important decisions, but they are responsible for getting them made and for informing decision makers.

If decisions are not made well, it is one of the quickest ways for a project to become “another statistic.” Capturing decisions in a decision log—who decided, what, when, and why—helps:

• Drive better decision‑making in the moment

• Provide accountability later

He jokes that when someone asks, “Why did you make this decision?” it’s powerful to be able to say, “I didn’t—you did. Let me remind you,” and point to the log.

Tthe practical problem with relying on emailed meeting minutes. Decisions go into minutes, minutes go into inboxes, and months later someone has to dig through old email late at night to find what was agreed. A central decision log avoids that.

Decision Latency and Resilience

“Decision latency” is a key cause of project failure: the time it takes to recognize a problem, decide what to do about it, and act.

Kim uses a road metaphor. The project plan is a road from where you are to where you’re going, winding through hills, tunnels, and mountains. Along the way, potholes, black ice, a moose—unexpected events—appear.

Each time something like that happens, the team must:

• Identify the problem (“There’s a pothole.”)

• Decide what to do (turn left, turn right, brake, hit the gas and try to jump it)

• Take action

• Reassess what happened

For him, project resilience is “being at the wheel,” paying attention, steering, and responding quickly to these events. RAID management helps teams do exactly that by making risks, issues, actions, and decisions visible and manageable.

Extending the RAID log

Beyond the core four, try adding:

• Lessons learned: captured during the project, not just at the end when people are tired and have forgotten details

• Change logs: if you don’t already have one

• Stakeholder contacts

• Calendars and key contractual milestones

• External dependencies

His view is that capturing these things while the project is in motion creates a richer and more accurate picture than trying to reconstruct them afterward.

Returning to the UK: Using the Log in Practice

Essendrup returns to the UK story to show the RAID log in action.

Once he had the log projected, he asked the customer to restate their number‑one issue. They did, and he typed as fast as he could into the issue log while they corrected his spelling and added details. They spent 10–15 minutes on that first issue, then moved systematically to the next issue, and the next, until they had exhausted all of the customer’s issues.

Then he turned to his own team and captured their issues as well.

Looking at the growing issue list, someone observed that many of the problems were really about dependencies: as contractors, they had depended on information, decisions, and content from the customer that had not been provided, and the customer had not realized those dependencies existed.

They opened a dependency tab and worked through what had been needed, what had been asked for, and where communication had broken down. At several points the customer said, “I didn’t know you needed that,” and Essendrup’s team responded, “Of course we needed that; that’s what we were asking for.”

Then they flipped to the action item log and turned each issue and dependency into concrete action items: what needs to be done now to address this? By the end of that first day, all the chairs had turned to face the projector.

Essendrup describes this as literally externalizing the conflict. Instead of two sides yelling at each other, both sides were now looking at the same RAID log, working together to solve the issues.

Over the week, customer team members were stopping him in the hallway saying, “Kim, I’ve got an action item; we’ve got to get it on the RAID log.” For him, that was the signal that a very simple tool had become the shared backbone for the work.

How to Use a RAID log Day to Day

Essendrup suggests several practical uses:

• Staying on top of a project: open it first thing in the morning; spend ten minutes on it in every team meeting to review risks, actions, issues, and decisions.

• Task switching across multiple projects: use it for discipline (“this is what I focus on for this project”), and for rapid orientation when switching from one project to another.

• Reducing formal meeting minutes: manage meetings directly from the RAID log instead of producing long minutes. Capture decisions, action items, and discussions about risks and issues as you go.

• Managing up: use it with sponsors to show you have a handle on what can go wrong and what is being done, and to track their action items.

• Managing and mentoring project managers: “show me your RAID log” becomes a way to see how someone is thinking about problems and to coach their problem‑solving.

• Sharing learning across a PM team: in team meetings, have project managers take turns briefly walking through a RAID log from one of their projects so others can learn from their challenges and approaches.

• Managing suppliers and customers: as in the UK example, use a shared log to externalize conflict and coordinate actions.

• Troubled or inherited projects: when taking over any project, especially a troubled one, one of the first questions should be, “Show me your RAID log.” If there isn’t one, you’ve found a place to start.

Core Takeaway

Essendrup closes with a clear message:

• Projects tend to go wrong because of the basics.

• RAID logs are a simple, adaptable tool for managing those basics—risks, actions, issues, and decisions—on any project, in any delivery style, at any scale.

Hopefully the next time you pick up a project the first thing you’ll ask is: “Show me your RAID log.”