The Psychology of Quality and More
If all that was needed was to make plan and then watch it all unfold as expected, then programme and project management would be a relatively easy task. However, the best laid plans of mice and men often go astray as unexpected things happen. In fact the reason programmes and projects often deliver late is not because they are badly planned, but because things crop up that are not planned. These can easily double the amount of time that is needed (this times-two multiplier is a popular and surprisingly accurate fudge factor).
The RAID Log is a simple extension to traditional risk management that supplements the programme or project plan in helping to manage the overall workload. RAID stands for Risks, Assumptions, Issues and Decisions and a simple way to manage the logging of these is in a spreadsheet, with one tab being devoted to each of the four items. The RAID Log should be regularly reviewed and updated in the same way that the main plan is managed.
Risks are a classic and well-known aspect of programme and project management. They are ‘bad things that could happen’ and can lead to delay, cost and quality problems. Risks are managed by seeking mitigating actions that reduce the chance of either the risk happening or the impact, should the risk occur. Contingency actions may also be prepared in case of this.
At the very least, a risk log should include a description of the risk, an analysis and a list of actions that need to take place. Risk logs often have significant supporting detail, such as before-and-after mitigation assessments, owners and traffic-light indicators of seriousness.
When planning something new, many assumptions may be made and some of these may be significant enough and perhaps uncertain enough to be worth capturing. Captured assumptions may then be deliberately tested at the appropriate time as information is gained for this purpose.
The Assumption log may include detail such as the assumption itself, the rationale for why this is assumed and the action to be taken to confirm or otherwise that the assumption is or is not valid.
Issues are, in effect, risks that have happened. If the risk planning has been done well, then they will not be a surprise and you will have the contingency actions on hand to handle them. Whether or not they are a surprise, issues are not usually found on the programme or project plan and so the issue log is the place where they are captured and tracked.
Issue logs may include various detail about the issues. Key items will cover a description of the issues, the actually effect it is having (including how serious this is) and the actions that require to be completed to contain and remove the issue.
One of the tricky bits of projects programmes is when you are dependent on others for particular activities or inputs. You may be working hard and well to your own schedule but then somebody who you need to do something does not deliver in time or to required quality. A common reason for this is that they do not have your priorities and may other work that is keeping them from delivering what you need. It is this higher risk of a difference with those on whom you are dependent that makes treating them as a special case worthwhile.
The dependencies log will capture at least who you are dependent on, what they should deliver and when. You may also want to keep details of the actual agreement and when it was made, plus any later variations of this.
Of course others may also be dependent on you for certain things and you may well have actions in your plan for this.
An alternative or addition that is sometimes used for ‘D’ is Decisions. In project and programmes, decisions are sometimes made that can have a significant effect, though with limited understanding of the impact they may have, for example in the extra work created. Decisions made along the way can also cause confusion where people misunderstand them or do not even know they have been made.
The decision log captures at minimum the decision, the rationale, who made the decision and any consequent work. This helps ensure the decision does not destabilise the plan and also gives a useful reference when someone says ‘Why did we decide that?’
In future articles, we will look in more detail as to how you can work on aspects of RAID management.
Next time: Risk Analysis
This article first appeared in Quality World, the journal of the Chartered Quality Institute
And the big