A RAID log is used for tracking Risks, Assumptions, Issues and Dependencies. To be honest I see more similarity than differences between these. They are all about threat.

RAID for physical threat

Here is how it works with physical threat:

Issue: A guy just smacked me in the face.

Risk: A guy is threatening to smack me in the face.

Assumption: I can walk down this dark alley in the bad part of town without a guy smacking me in the face.

Dependency: If my girl friend picks me up in the car then I don’t have to take that shortcut through the bad part of town with all those guys waiting to smack me in the face.

RAID for programmes and projects

Back in programme and project land the same applies. RAID items are just different types of threat. As I showed in a previous post an assumption in a project or programme is an inherent risk and needs to be managed like a risk.

The same applies for dependencies. For example, one of my workstreams was dependent on another team to collaborate on some functionality. I knew the other team was busy so this dependency appeared on my risk register from day one. As as a consequence a senior manager from that part of the organisation was invited to my programme board to ensure the collaboration had sufficient priority.

Issues are risks that have manifested. For me that makes issues higher priority than risks that haven’t manifested but otherwise they are the same. (It bugs me, for example, if a risk register changes the ID of a risk when it becomes an issue; they are in fact the same thing with a different status.)

Put another way, risks, assumptions, issues and dependencies are all threats to the programme or project. They have to be managed but their similarity means I treat them all much the same. The only distinction is that a risk (including assumptions and dependencies) is a merely a potential issue.

Don’t get smacked in the face.