Like all good project professionals, whenever I’m managing a project I find it’s essential to keep a track of intended and incidental Benefits, Lessons learned, key Actions, and of course Resources. That’s why—in line with the best of my project manager peers—I always keep a BLAR log.

Oh, hang on. Let’s try again…

Like all good project managers I always keep track of my extended Team, our Users, the Benefits we’re delivering, and of course the Expectations upon us. That’s why I find a TUBE log is so important.

Hmmm… Take 3…

Every good project manager knows that it’s absolutely essential to keep track of Stakeholders, their Needs, the Outcomes we should be delivering, and (naturally) our Finances. That’s why a SNOF log is…

You can probably guess where this is going.

I’ve long been curious about the so-called RAID log that project managers are supposed to keep. It’s not that we shouldn’t be worrying about things like risks, issues, assumptions and dependencies. (Although I’d contend that we can be more constructive in our thinking around “risks” and “issues”.) It’s just that there’s no particular reason to pick out just those things and group them separately to anything else.

There are lots of things to track, at different times and to different degrees. These include (in alphabetical order): accountabilities, actions, assumptions, benefits, dependencies, expectations, finances, issues, lessons, needs, outcomes, questions, resources, risks, stakeholders, team, users,… and many more. I think anyone would be hard-pressed to say why the four usual suspects should be considered so special (and so alike) that they should always go together. I was reminded of this a short time ago when dipping into Stack Overflow and read one comment that said:

I had never used Assumptions and Dependencies logs until I started working at my prior employer where I encountered them for the first time and used them on a series of projects. My conclusion after that, I’m afraid, was that they provided no real benefits though that could easily be my naiveté with their usage (for which I received no training). Sadly I got the impression they only existed to provide the ‘A’ and ‘D’ for the natty word RAID!

My conclusion from this is that we shouldn’t take project management tradition and custom for granted. I would challenge anyone who talks about using a “RAID log” to ask themselves if they’re using it because they’re just following others, or because they really think those four things need special treatment together. We need to think for ourselves and use the tools that are right for us and the context we work in.

Photo by John Bugg