Project Management: CRAID

Unless you are managing a very simple project, from the moment you start it, to the moment you close it, there will arise uncertainties – the real world does not let you manage in peace. The standard technique used to manage uncertainty across the life of a project is called RAID Management. This is an acronym of course and stands for Risks, Assumptions, Issues and Dependencies. I also add a C for Changes at the front, hence CRAID. It can be a complex subject, but this is where the skill and experience of a PM can really pay dividends. I offer you then a few key pointers about how to TAME uncertainty.

Changes will arise in a project. Someone wants the data flow to work differently than first envisaged, your sponsor wants to add in a feature to make the end result better. Changes require attention and an analysis of their impact on the project baselines – time, cost, benefits and resources.

1. Track: anyone can come up with a change request: when they do, log it in a list, record it’s status and the decision that is made against it.
2. Assess: spend a reasonable amount of time to work out the impact of the change – how does it affect the project timelines if we include it? is it worth doing?
3. Make your mind up: based on the analysis, decide whether to include the change in the project or not – the decision should always come from the Project Board.
4. Execute: add the change – if approved – to any documents, work schedules, plans, tests etc.

Risks are defined as circumstances that might happen and that if they do, will affect your project baselines, whether positively or negatively (its usually negative).

1. Track: get you, your team and your Project Board to think of anything that could go wrong. Log all they come up with in a list and record against each entry what you do about it and what the status is. Also, make sure every entry has an owner.
2. Assess: work out what each risk can do if it materialises: a standard way is to consider on a scale of 1 (trivial) to 5 (almost certain) how likely it is to occur, and what the impact is if it does. The higher-rated items are what you focus on first.
3. Mitigate: think about how to deal with the risk and prevent it impacting you. Can you reduce its effects, put a contingency plan together, transfer some of the risk to someone else, avoid it altogether by doing something different? Just remember that denial is not an option! Give the Project Board regular sight of these actions.
4. Evaluate: keep an eye on the risks in your log (add new ones if necessary) and update your mitigation plans accordingly if things change.

Assumptions are tricky, but they are things you think you can rely on that need to be checked. You get a lot of these at the start of a project, but if you’re doing your job as a PM correctly, they should dwindle to almost nothing once you start creating the deliverables.

1. Track: log them all and give each an owner so you can capture and update status.
2. Assess: check out each assumption to verify it and work out the impact if you’re wrong in your assumption. Where you can’t verify it, can you reduce the impact for example? Log the checking actions you give to team members.
3. Monitor: As with other uncertainties, keep an eye on them so you can react if things start getting more serious.
4. End: the aim is to reduce assumptions so you can forget about them: take every opportunity to close them off, or prevent them hanging over your project.

Issues are basically what happens when risks materialise or when things just go wrong that you didn’t expect. They are right in front of you and may need immediate action, so this is where problem-solving skills can be useful.

1. Track: log the issue so you can track actions and status. Assign it to an owner who will keep you informed about the activity on it.
2. Assess: work out how serious the issue is and what impact it has on the project in terms of cost , time, resource etc. Also evaluate how quickly you need to deal with it – some issues can be left until later and may resolve themselves on their own, and some may have too little impact to be overly concerned.
3. Monitor: agree actions to deal with the issues and bear in mind that some actions create Changes, or other Risks to be recorded as well.
4. Execute: get the actions done.

Dependencies are a special type of uncertainty that you have less control over because they’re in the hands of other people or projects.

1. Track: you see the common theme yes! Log the dependencies and assign an owner among your project team to look after them.
2. Assess: for each dependency, work out who’s doing what to keep an eye on it. If it’s a dependency on a supplier, who owns the relationship with them and how are they going to keep the supplier in line for example?
3. Monitor: keep an eye on the dependencies for anything which might have an adverse impact on the project – you could also add contingencies into plans to cope with any delays for example.
4. End: as with assumptions, the aim is to reduce dependencies so you can forget about them: take every opportunity to close them off, or prevent them hanging over your project.