The RAID Log means so many things to so many Project Managers. Some (including me for a long time) look at it as a mere Risk Register to record those one-off risks in the project- delays in milestones, approvals not coming in time, a failed UAT, a defect somewhere etc.
Some (including me now) use the RAID log as a very important tool that AIDS the PM. The 4 components of the RAID log are crucial components of the Project Mgmt tool set at the disposal of a project Manager. Here is why I love the RAID Log so much:
1) RISKS: The conventional way of logging risks is to identify them in the execution stage, and that's not right. The process of collection and identification of Risks begins on the first day. For instance, every project deals with and processes data of varying complexity levels. This means identifying recommendations such as data encryption, security tests and DB encryption etc at the beginning of the project. These recommendations get implemented in the solution. This is the best way to use the Risk Register of the RAID. Log a RISK for this level of data complexity, identify these recommendations in the mitigation, and put them in the project plan or in the design document. Remember, the RISK log itself just acts as a placeholder for things that can go awry. It is how and when the mitigation is implemented that is more important. This is a great example of how the RAID log can help in designing, planning and tracking, not just in identification of a RISK.
A good way to make sure all risk are being covered is to conduct a risk identification session once every week or two with the main stakeholders.
2) Assumptions: Log every assumption there is to assume! and act on it, confirm it or reject it! Far too many problems in the project happen later because things were ASSUMED, but not recorded. The simplest example is to assume the business will drive the UAT. Much as the project manager holds this as universally understood, it is not always evident to the business that they are the ones who will drive the UAT. Most businesses may have a generic impression that they will get a chance to REVIEW the product before implementation, but thats about it. It is best to record this in the assumption log and align with the business. Keep revisiting assumptions every now and then, and make sure everyone knows what is being assumed. False and unidentified assumptions can cost the project dearly.
3) Issues: This is the trickiest area- things that HAVE GONE WRONG. These items find their ways into the escalation sections of the status reports on most occasions. Most importantly, correctly logging an issue and its mitigation plan demonstrates to the sponsors that the PM is still in control of the project. It also highlights to everyone involved that we have a problem, and we must all work together to resolve it soon, before it impacts other things.
4) Dependencies: This is the subtlest of all the components, yet so important when used effectively. There is a reason why the MS Project is a very popular PM tool today, and that's because it respects dependencies like none other. I once worked on a project wherein, a particular person sitting in the USA would activate a site, only after which it would be made available to users the next day in my country. The problem here is obvious- the time difference between India and USA meant he would do this when i would be fast asleep in the night. What if he failed, for any reason? How would he contact me to inform me in the middle of the night? Importantly, how would I tell my users, before 8 am that the site cant be used? This is a classic case of how useful dependencies can become. I logged a dependency, aligned this with his team, and ensured there was enough backup and communication between the 2 teams, to wade off any last minute hiccup. Dependencies are usually followed by clear and crisp regular communication, with a call-to-action at a particular date. When dealing with multiple teams each with a contribution to the project, not using the Dependency log is invitation to disaster. Planned leaves, back up plans, are other classic examples of dependencies.
In conclusion, the RAID log acts as a written contract between all concerned parties in the project, and gets everyone on board to act when required. The RAID log is not just a save-my-skin tool for the PM, it is so much more. When used correctly and effectively, it can act as a tool that can help the PM plan, design, execute, monitor and close the project well.
What's not to love about it then?
Some (including me now) use the RAID log as a very important tool that AIDS the PM. The 4 components of the RAID log are crucial components of the Project Mgmt tool set at the disposal of a project Manager. Here is why I love the RAID Log so much:
1) RISKS: The conventional way of logging risks is to identify them in the execution stage, and that's not right. The process of collection and identification of Risks begins on the first day. For instance, every project deals with and processes data of varying complexity levels. This means identifying recommendations such as data encryption, security tests and DB encryption etc at the beginning of the project. These recommendations get implemented in the solution. This is the best way to use the Risk Register of the RAID. Log a RISK for this level of data complexity, identify these recommendations in the mitigation, and put them in the project plan or in the design document. Remember, the RISK log itself just acts as a placeholder for things that can go awry. It is how and when the mitigation is implemented that is more important. This is a great example of how the RAID log can help in designing, planning and tracking, not just in identification of a RISK.
A good way to make sure all risk are being covered is to conduct a risk identification session once every week or two with the main stakeholders.
2) Assumptions: Log every assumption there is to assume! and act on it, confirm it or reject it! Far too many problems in the project happen later because things were ASSUMED, but not recorded. The simplest example is to assume the business will drive the UAT. Much as the project manager holds this as universally understood, it is not always evident to the business that they are the ones who will drive the UAT. Most businesses may have a generic impression that they will get a chance to REVIEW the product before implementation, but thats about it. It is best to record this in the assumption log and align with the business. Keep revisiting assumptions every now and then, and make sure everyone knows what is being assumed. False and unidentified assumptions can cost the project dearly.
3) Issues: This is the trickiest area- things that HAVE GONE WRONG. These items find their ways into the escalation sections of the status reports on most occasions. Most importantly, correctly logging an issue and its mitigation plan demonstrates to the sponsors that the PM is still in control of the project. It also highlights to everyone involved that we have a problem, and we must all work together to resolve it soon, before it impacts other things.
4) Dependencies: This is the subtlest of all the components, yet so important when used effectively. There is a reason why the MS Project is a very popular PM tool today, and that's because it respects dependencies like none other. I once worked on a project wherein, a particular person sitting in the USA would activate a site, only after which it would be made available to users the next day in my country. The problem here is obvious- the time difference between India and USA meant he would do this when i would be fast asleep in the night. What if he failed, for any reason? How would he contact me to inform me in the middle of the night? Importantly, how would I tell my users, before 8 am that the site cant be used? This is a classic case of how useful dependencies can become. I logged a dependency, aligned this with his team, and ensured there was enough backup and communication between the 2 teams, to wade off any last minute hiccup. Dependencies are usually followed by clear and crisp regular communication, with a call-to-action at a particular date. When dealing with multiple teams each with a contribution to the project, not using the Dependency log is invitation to disaster. Planned leaves, back up plans, are other classic examples of dependencies.
In conclusion, the RAID log acts as a written contract between all concerned parties in the project, and gets everyone on board to act when required. The RAID log is not just a save-my-skin tool for the PM, it is so much more. When used correctly and effectively, it can act as a tool that can help the PM plan, design, execute, monitor and close the project well.
What's not to love about it then?
No comments:
Post a Comment