This week on CIO Playbook with Jeffrey Hurley, I am continuing our discussion on project management with how to use a RAID Log to manage some of the key priorities that could potentially derail your project success. Unknown events and events out of your control are always a risk to project success, however, knowing in advance what these events are gives you the opportunity to develop contingency and mitigation plans. Understanding how to categorize risks, assumptions, issues, and dependencies will move you in the direction of greater project success. I suggested managing your projects with the raid log as a key component of the regular update meetings; whether these meetings are with the working groups, stakeholders, of steering committee members.
What is a RAID Log
A RAID Log is a component of the project management tool box. This log is the risks, assumptions, issues, and dependencies for the project. A central place to track the key components or influences of your project’s ability to deliver on time and to expectations
Why a RAID Log and Not Something Else
There are multiple items that can have a negative impact on a project. Usually there are solutions to these items if you have time to plan for them up front. Much like practicing your building’s evacuation plan, a project can be protected if mitigation plans are in place well in advance of any items on the log happening. If something on the log cannot be mitigated at a minimum the project and business leadership can be aware of and prepared for the event should it happen.
How Should You Set up Your RAID Log
If you google RAID Log both using the web or images options you will discover there are many ways to structure these logs. I have found that there are a couple of key items that need to be a part of the log and then depending on how you want to manage your project you can add additional fields. My personal preference is to provide a series of fields that allow for easy filtering in MS Excel. you could build or buy an application to this as well. However, I have found MS Excel works just fine and that means google docs and Libre Office, etc. can be used to develop these logs if you are looking for something less expensive than the Microsoft suite.
Overall Impact Guidelines
- Critical: Item is required to be escalated to Senior Management with mitigation options if possible
- High: Management item to be monitored by the project manager and senior management
- Medium: Item for project managers to monitor and does not require escalation
- Low: Item to track for awareness and monitor if it needs escalation
- Very High: Will impact the deployment date
- High: Could drive impact to deployment date
- Medium: Could drive impact to intermediate milestone, which could impact deployment date
- Low: Could drive impact to tasks and may impact an intermediate milestone
- Very Low: Could drive impact to the project milestone that could easily be absorbed by the project (non Go-live time)
- Certain: 100% likelihood of occurrence
- Expected: Greater than 90% likelihood of occurrence
- Likely: 60 to 89% likelihood of occurrence
- Possible: 40 to 59% likelihood of occurrence
- Unlikely: Less than 39% likelihood of occurrence
- Open: The item is being actively monitored and tracked
- No longer relevant: The item has been investigated and is of little or no concern
- Closed: The item is closed
Risk Type Guidelines
- Governance: Related to program / project management, approvals, committees, etc.
- Business Process: Related to business process or procedures
- Software / Hardware: Related to software design and development or hardware, network, or enterprise systems
- Training: Related to process or system training
- Testing: Related to system testing and user acceptance testing
- Adoption: Related to system integration and adoption into the daily business activities
- Team / Resources: Related to program / project staffing: vendor, information technology, business teams, etc.
- Communication: Related to information sharing and transparency for the program / project
- Other: Any risk, assumption, issue or dependency not defined by the reset categories
Risk / Assumption / Issues / Dependency Guidelines
- Risk: A risk is the recognition that a problem might occur that may potentially interfere with the successful completion of a project. Risk is anticipated in the future which will require mitigation.
- Assumption: An assumption presumes that a group or deliver will happen, is true, or certain. If this assumption does not come true the project will have an impact. There is a subtly between an assumption and a risk
- Issue: An issue is something that has already happened in the project and a solution to resolve it is being looked for; a mitigation plan is needed
- Dependency: There are four types of dependencies upstream internal dependencies, upstream external dependencies, downstream internal dependencies, downstream external dependencies. The internal upstream and downstream dependencies will appear in your project plans. You may also have your external upstream and downstream dependencies in the project plan, however, it is the external dependencies that will need to be called out separately in the RAID Log for monitoring.
Wait There is Still More to Come Next Episode
Next week we will delve into the following ways to put the RAID Log to work for you
- How Do You Use a RAID Log
- What Does Management Do with the RAID Log
- How do you Incorporate a RAID Log Into a Project
- How do you Maintain a RAID Log
- How Quickly Should Items be Mitigated or Resolved
Photo Credit: Disco-Dan. “Fan Bay Deep Air Raid Shelter And Magazine Room.” Flickr. Yahoo!, 15 Feb. 2013. Web. 14 June 2015.