Anyone who has ever performed risk management for an IT program management office knows the lengths to which some stakeholders will go to avoid risk management. It’s commonly viewed as a pesky bug that gets in the way of “more important” operational activities. For risk management practitioners, the biggest job often is convincing stakeholders that following risk management best practices is more like putting on bug spray as a preventive measure than being the actual bug.
The 1995 Standish Group report advised that the vast majority of software projects come in over budget, behind schedule or just fail completely. While many factors contribute, implementation of a risk management program during the early stages of the project — and proper execution across the lifecycle — can reduce the likelihood of schedule slippage, overspending and project failure.
The reason is simple: Rigorous risk management processes identify risks before they impact the project.
Consider the following do’s and don’ts when establishing and executing a risk management program:
■ DO get executive buy-in. As with any initiative that requires cooperation from many program stakeholders, gaining leadership’s blessing is key. Develop a business case that presents the program’s benefits to persuade leaders to make risk management a priority.
■ DON’T start with nothing. When establishing a risk management program, remember that a set of core risks applies to every IT project. Typically, they fall within the project management “iron triangle” of cost, schedule and scope. Almost every IT project runs the risk of going over budget, slipping on schedule and encountering scope creep. So, when establishing your project risk register, develop risks related to these concepts. Consider creating a set of sample risks as a “starter package” for general use when your program will run multiple projects with similar risks.
■ DO create a collaborative environment. After a project risk register is created, risk sometimes falls into a black hole, never to be updated again until annual risk report time arrives again.
Work with risk owners to determine the best way to communicate updates for each risk. Determine whether there are individuals who should be contacted to update specific risk information. Consider whether you should establish a risk “update schedule” and adjust the frequency of the schedule based on how dynamic or time sensitive the risk is.
DO define criteria. Many risk scoring methodologies use “Low,” “Medium” or “High” for risk impact and probability scores. This approach is fine as long as you define the criteria and communicate the parameters to those assessing risk scores.
Consider using more granular scoring levels (e.g., “Very Low,” “Low,” “Moderate,” “Serious,” “Critical,” etc.) to define risk exposure clearly and allow more targeted risk prioritization and mitigation.
■ DO take action. Specific mitigation steps to take — and activities conducted — should accompany every risk. Mitigation steps should be actionable and time-boxed with the specific activities to take place. For example, “Validate the creation of a resource-loaded Work Breakdown Structure by October 1, 2014” is preferable to “Develop schedule at the beginning of the project.”
■ DON’T forget to validate. Many times risk reports comprise part of overall executive status briefings. If the risks being reported during these updates are dynamic or politically sensitive, ensure the risk owners have signed off on the risk scores and the overall content.
A risk management program is an effective monitoring instrument that gauges the ongoing health of any project. Following these tips will bring visibility to the specific risks the program is facing, increase accountability and prevent critical risks from being realized, just like bug spray prevents bites on a warm summer night.
Daniel M. Langley, PMP, is a program manager with DHA Group, a management consulting and contracting firm primarily serving federal civilian and defense agencies.