The RAID Log: Right Topics, Wrong Sequence

If you were to poll project managers on which software tool (aside from email) they use most often, for the largest number of tasks, I imagine that Excel would predominate. From complex calculator to data analyzer to zero-effort database and factoid organizer, I doubt there is a more ubiquitous multi-tool. And yet, we sometimes use it in ways that inhibit our understanding of the problems we’re trying to solve. One example that comes to mind is a spreadsheet template we used in a former life, called a “RAID log.”

The spreadsheet had four tabs: Risks, Assumptions, Issues, and Decisions. Each tab had columns defined that would drive identification and management of their namesakes. In and of itself, it was an excellent starting point. But the sequencing that made the template name pronounceable hid the complex relationships among the four objects. And that probably caused more than a few problems along the way.


Most projects begin with a limited number of facts, or “knowns,” and a by-product of the project is to expand that knowledge base. But at the beginning, a lot of assumptions are needed to fill in the gaps. These assumptions help us better visualize the current state, the desired future state, and the space between. With assumptions, we can make plans and estimates, communicate and collaborate, and otherwise act on those things we know to be facts. Consequently, all projects begin with a set of assumptions.

That said: every assumption carries some amount of uncertainty. Because we depend on assumptions to proceed with our work, and that uncertainty is present, each assumption represents a source of risk. Of course, not all assumptions are foundational, and few will be purely wild-assed guesses, but one of our process goals in every project should be to verify every assumption. To do this, every assumption should be documented and referenced when used in estimates, plans, schedules, budgets, and any other project activity.


Whether the goal is to correct a problem, develop a new capability, or comply with some external requirement, projects are approved to address issues. If the status quo were acceptable, no one would spend money to change it. On many projects, the project is an umbrella for the resolution of all sorts of issues. As you explore the project scope for details, more issues will emerge, and some of your assumptions will be challenged. This is a good thing: solving the wrong problem won’t get you any points. You might discover some issues can be resolved along the way, while others depend on the outcome of the project. Persistent issues frequently have roots in an earlier solution, and it’s common for them to be well-documented. So capture that content in your project issue log.

Once you transition to the execution of your project, more issues will manifest, especially as you make changes or consume scarce resources (like the time and attention of your stakeholders). On some projects, tracking and resolving issues becomes the key to making progress. The old adage about being up to your ass in alligators speaks volumes about the potential for creating new problems while trying to solve old ones.


A risk is an uncertainty that matters. As noted, every assumption has an element of uncertainty, and every issue matters. Consequently, a review of assumptions and issues logs should give you a starting point in identifying risks. If an assumption is incorrect, what are the consequences? What is the likelihood of resolving one issue, only to create a new one? In reviewing the plan, identifying risks isn’t just about understanding the proposed solution, but the current state.

As Tim Lister so famously said, “Risk management is how adults manage projects.” Tracking risks, from identification to analysis to action to retirement, is one of the keys to a successful project. Once you understand both the risks and the issues, you can select better risk responses. Being able to link risks to assumptions, and to both the issues that made them worth taking and the issues that they might become, will help you keep preventive and corrective actions from falling through the cracks.


The most expensive part of any project is indecision. Many decisions are the leverage needed to resolve issues; others drive risk responses. Still others change or confirm assumptions. Many schedule delays can be attributed to the failure to make a timely decision, or the failure to communicate a decision once made. Once the need for a decision is identified, whether to resolve an issue, manage a risk, or just eliminate alternatives, it should be logged. Allowing a pending decision to drag on too long is an impediment to the project, and to the business of the organization. A review of the decision log for pending items should be part of every steering committee meeting.

The relationships among assumptions, issues, risks, and decisions are complex, and somewhat recursive. Tracking them is not a chore to be done once and then checked off the to-do list. Taken together, they are the background (and sometimes foreground) of every project. Understanding how they interact can be critical to keeping your project on track. So if you use a spreadsheet like our old RAID log, be sure to use it wisely.

Rules of Thumb for Creating a Work Breakdown Structure

I think a lot of us have wondered whether our work breakdown structure (WBS) would seem reasonable to our peers. A Redditor on the projectmanagement subreddit recently asked, “How many rows deep is your typical MS Project plan for a complex project lasting 1 year? Am at 1000 rows now. Am I above or below average?”

I don’t think there is a meaningful “average” to cite because a WBS is based on too many specifics. I think a more actionable question is, “Will this breakdown allow us to communicate the work to be done and assess progress and work remaining?” That said, there are a lot of rules of thumb out there for creating a work breakdown structure (WBS). I find these to be generally useful:


  • A task should be something that takes from 2 days to 2 weeks to complete.
  • If you have a small number of tasks assigned to one or two resources that individually take less than 2 days, put them in a checklist and make completion of the checklist a task. Checklists are our friends.
  • If you have a single task that takes more than 2 weeks, maybe it should be divided into smaller pieces. Agile teams commonly break an epic into two or more stories.
  • Think in terms of deliverables. If a task doesn’t produce a deliverable or further the evolution of a deliverable, should it really be a task?
  • If person A produces a deliverable, person B inspects the deliverable, and person C approves the deliverable, you have at least three tasks.

Structuring The Work

  • A WBS should include three types of entries: detail tasks, describing the work to be done; summary tasks, which group detail tasks on some meaningful basis; and milestones, which allow us to note progress based on completion of selected detail tasks.
  • A WBS should be in the form of an outline, with two or more levels of indenture. It is common to have a summary task with multiple child summary tasks, and so on. The term ragged pyramid is descriptive of many WBS.
  • There are two primary audiences for a WBS: the people who will be assigned to perform the tasks (and the people they report to) and project stakeholders who want to understand how the project will affect them. Keep both audiences in mind.
  • Design your WBS for dependencies. If you have six detail tasks under a single summary task, to be performed one after another, and there is a single dependency running from the summary task to the next detail task under some other summary task, it will probably be easier to explain to both audiences than some rat’s nest of links going all over the place.
  • If a summary task only has two detail tasks under it, maybe the details should be merged into one of the peers of the summary task, or moved up to the same level as the summary. Similarly, a summary task with so many detail tasks that you have scroll through them might be a candidate for reorganization.
  • When I have multiple teams working in parallel, I often put each team’s tasks under their own summary task. When they reach a milestone that requires a hand-off to another team, that outbound dependency is located in the top summary task. Especially useful when I have one or more vendors participating.

Considerations for Managing the Work

Make your structure as detailed as needed to facilitate an understanding of the work, but not so detailed that it becomes unmaintainable. If your 1000 row WBS includes 800 or so detail tasks and they average a week in duration, then you will average 16 tasks initiated and another 16 closed out each week over the course of a year. If that doesn’t seem manageable to you, or those assumptions aren’t reasonable, consider your alternatives, from delegating administration of task updates to fissioning into two projects.

If anyone would like to add a rule, or dispute one of mine, leave a comment below.

Because You Purchased …

A couple of months ago, I purchased a copy of Roy Underhill’s “The Woodwright’s Eclectic Workshop” at a bricks-and-mortar store and gave them my Email address. I just got an Email from them with recommendations based on that purchase. The list included six more books on traditional woodcraft by Roy, one on woodworking in colonial America by Keith Wilbur, and “Gun Digest Guide to Concealed Carry Handguns” by Dick Jones.


Still worried about Artificial Intelligence taking your job?