How to Develop a Plan to Manage IT Risks

How to Develop a Plan to Manage IT Risks
By Harry Hall

Want to know the secret to managing IT risks?

Drumroll please…

A Risk Management Plan.

Simple, huh?

So simple as to be, well, let’s say completely useless. Because if you knew the secret to consistently managing IT risks, you’d already be doing it, right?

But instead, you continue doing what you’ve always done with a gnawing apprehension that your worst nightmare is just around the corner. You are too busy to “add risk management” to your list of things to do.

The problem is that many CIOs – even the top-tier CIOs – lack an adequate grasp of their IT risks. Even these top dogs understand that they’re one event away from losing the farm. Which risks are greatest?

• Data security breach with reputational harm
• Regulatory risks
• Social media
• Recruiting and retaining qualified IT staff
• Improper balance of outsourcing
• Cloud technologies
• Transition to agile methods
• Disaster recovery
• Outdated operating systems
• Data on user-owned mobile devices
• Third-party risks

But there is a way to give you a better chance of not only surviving, but thriving in the face of great uncertainty. A solid, well-grounded risk management plan can help you reduce threats and enhance opportunities. You will more consistently identify, evaluate, monitor and manage your risks. Perhaps you will even sleep a little better at night.

Let’s not kid ourselves on this matter. Risk management is not an easy ride or quick fix. You must define your risk management plan and diligently follow the process to gain the desired results.

The Things Every Risk Management Plan Has in Common

The risk management plan is not an activity that we do once. The bulk of the time will be in the initial definition of the plan, but you need to periodically review and update the plan. IT risk management plans typically include:

• IT Department Risk Background. Describe how your department supports your company’s strategic plan and why IT is important. Are the current and upcoming projects like other projects the company has completed in the past or is this project portfolio out of the ordinary (and therefore riskier)? How complex are the projects? What parts of the project are most risky? How much experience does the team have in managing risks?

• Methodology. Describe how you will identify risks, assess risks, perform risk response planning, and monitor risks at a department, portfolio, program, and project level.

• Roles and responsibilities. Who will perform which risk management activities? Consider designing a responsibility chart/matrix. List roles such as department managers, program managers, project managers, risk owners, project teams and stakeholders, along with their responsibilities.

• Timing. Define how often you will perform risk management activities.

• Risk Categories. Define the categories for your risks. Standard project categories include schedule, scope, quality, and budget. You may wish to define a risk breakdown structure (RBS) that provides a cascading list of categories and sub-categories. For example, you may have higher level department categories for operational failures, reputational risks, and legal risks.

• Definitions. Define risk management terms such as probability, impact, risk, issues, risk appetite, and risk tolerance. Defining your probability and impact scale is critical to minimize bias in risk assessments/ratings.

• Risk Attitude, Appetite, and Tolerance. What is management’s attitude toward the risks in your projects? Where do they want to take risks? Where are they risk adverse? How tolerant is management of schedule slippage? How about cost variance tolerance?

• Reporting Format. What format will you use to report risks? What will you include? Will you provide reports at different levels of the organization, such as reports to the CEO and management team, Enterprise Risk Management, IT management team, and project teams?

Here are some other items you may wish also to include in your risk management plan:

• How will risks be recorded? In SharePoint, in a project management information system, or risk management system?

• Will there be risk audits? If so, who will perform them? What is the purpose of the audits?

• Who will be responsible for risk reassessments and reviews?

• How will you calculate risk scores (e.g., probability x impact)?

• Will there be go/no-go decisions during the projects? If so, when?

• What tools and techniques will you use to identify risks, qualify risks, quantify risks, and monitor risks?

• Will you quantify risks? If so, which ones?

• How will lessons learned be documented? When? By whom? How will the lessons learned be shared with others?

• How will you determine whether programs and projects are performing well? What metrics will be monitored?

• Must organizational standards and policies such as an Enterprise Risk Management policy be followed? Who enforces these policies? How are the policies enforced?

So what are you waiting for?

Success is not something that can be engineered; it’s just something that happens when the sun, moon, and stars align, right? Wrong.

As CIO, you have a choice. You can choose to fly by the seat of your pants, hoping everyone has their bases covered, or you can reduce the guesswork. Cast the vision for why IT risk management is critical and how you will move from your current state to a desired future state.

If you want things to be more predictable, define your department risk management plan. Define subordinate program and project risk management plans. Be diligent to integrate risk management in your daily projects and activities. Review and update the plans periodically. The best is yet to come!

Harry Hall, PMP, PMI-RMP, is the Director of Enterprise Risk Management at the Georgia Farm Bureau Mutual Insurance Company, one of the largest domestic insurance companies in the state of Georgia. You can read more from Harry on his blog.