This is Why a Risk Management Plan is Important

Many projects either fail outright, or do not achieve the objectives that were set out for them, simply because risk management was executed badly. One of the main reasons that it was executed badly is that it was planned badly (or not planned at all).

I have witnessed projects firsthand on which risk management was an afterthought. Then when some uncertain event happened, the project management staff scrambled to determine what could be done to mitigate the issue. Had a Risk Management Plan been in place from the outset of the project, the risk might have been mitigated before it even took hold.

This need not be! I lived most of my career in the world of the fixed-price project. I have worked on, managed, and provided oversight for projects ranging from a few million dollars to hundreds of millions. Fixed price! Millions of dollars! What could be riskier than that?! My contention is that if IT providers can assess and mitigate risk on such large fixed-price bids, why are they often so casual about planning for risk during the project execution? Similarly for internal IT organizations.

Whenever a firm I worked for considered bidding on a fixed-price project – regardless of project size – we addressed numerous questions before determining our bid strategy. In the world of fixed-price bidding, it is necessary to mitigate as much risk as possible in the bid response. We did not want to expose the firm to loss. Note the emphasis was on mitigating risk to ourselves, the bidding organization, rather than for the client. We seldom considered project risk based on the client’s organizational objectives.

Our response was additionally tempered by what our competitors might be bidding. Within that context, we would ask questions such as:

• • does the Request for Proposals (RFP) tell the whole story?
  • does the language of the RFP suggest that our interpretation of the requirements may be different from the organization’s intent?
  • might there be major outside influences? (For example, in providing project management services to government departments, I would consider whether there might be a major piece of upcoming legislation that would affect the overall project requirements?)
  • what is the risk appetite, risk tolerance, and risk threshold of the organization requesting bid responses?

This last consideration regarding the risk appetite of the requesting organization is extremely important. For example, I was on a proposal team that bid leading-edge technology for a mission-critical government program. Our bid was well designed. The benefits of the new technology were well explained. Our price, as we learned later, was more than 25% below our nearest competitor. But we lost the bid. Our failure: our bid manager had not understood how risk averse this particular government entity was. Nor had he understood that their preference was to stay with a “safe” mainframe solution rather than risk the new server technology we proposed. To them safety was more important than the money that they would have saved.

Beyond our risk assessment during the bid process, it was also imperative for our Project Manager to manage the project risk when we won the bid. In particular, he or she was required to manage the risk to our firm. After all, we had bid a fixed price, and every day of schedule delay cut into our bottom line.

Us, us, we, we, our, our – it often seemed that the project was all about us. It often seemed that the risk to our client was secondary.

What about the risk to the organization for which we were conducting the project? What risk planning had we undertaken to help ensure that their project would meet their objectives, and would be delivered according to their timeline and within their budget?

Sad to say that bid responses were, and still are, often constructed in a way to push as much of the project risk as possible onto the client. Even though a Risk Management Plan is often requested in the RFP (typically a boilerplate requirement), the bidding organizations typically respond with boilerplate responses. During the execution of the project, that same Risk Management Plan is often given only lip service.

For example, I’ve witnessed projects where the risk management review was a standing item on the weekly status agenda. Often time would run out before we would get to this agenda item. Or, if time permitted, the meeting facilitator might address the attendees like the following: “Are there any comments regarding the risk register?” The client would not respond adequately because they themselves often did not understand the importance of a risk management or how to go about it.

Additionally, there was seldom any purposeful allocation of resources or project budget to risk management. Contingency planning for potential risk was often little more than a wet finger raised in the wind to determine the probability of a given risk.

My description of the lack of attention to risk management planning may seem overly critical; but there are those reading this article who can reflect on past (or current) projects, and agree that this is true more often than it should be.

A Risk Management Plan is an important component
of the overall Project Management Plan

Planning risk management involves defining how risk management activities for the project will be conducted.

In the plan, the degree, type, and visibility of risk management must match the importance of the project to the organization. Many of the projects I worked on required the complete replacement of mission-critical systems. The existing legacy systems were old and brittle, written in a programming language for which programmers could no longer be found, running on expensive technology that could no longer be upgraded, and maintained and patched for so long that even experienced programmers no longer wanted to touch the code.

For example, I once interviewed an end-user on one of my projects who had been recently hired directly out of college. When she was trained on the organization’s legacy system, she came face to face with “green screen” technology for the first time. She kept reaching for the mouse to move the cursor, which of course didn’t exist for this type of application. The system was older than she was, implemented in technology that she had never been exposed to. Based on her reaction, and the fact that older workers were retiring, it was safe to say that the project was very important to the organization. Therefore, the degree, type, and visibility of risk management was critical to that organization.

A Risk Management Plan must also outline how vital it is to communicate potential risks to the stakeholders on a regular basis. Executive management can assist in mitigating many types of risks quickly and efficiently when they are made aware of them early in the project.

Once the importance of a Risk Management Plan is understood, four considerations are important in developing the plan:

1. The overall risk management context of the project must be understood and defined. This includes an understanding of the stakeholder risk appetite, and the strategic risk exposure of a given project to the client organization. Based on this understanding, the project team can allocate appropriate resources and focus on risk management activities.
2. Experts should be consulted based on their knowledge of the organization and of similar projects. Senior management and project stakeholders will have a definite view as to what risks may occur on the project. Project managers and Subject Matter Experts who have worked on similar projects will bring lessons learned that can contribute to risk mitigation. Industry groups and consultants also have relevant ideas regarding risk management planning for the type of project being conducted.
3. Risk management must be purposefully planned, and cost elements and schedule activities must be included in the overall Project Management Plan. Risk contingency deserves more than a wet finger in the wind, and appropriate contingency reserves should be planned.
4. A Risk Management Plan should define the approaches, tools, and data sources to be used in managing the risk on the project. Roles and responsibilities, estimated funds, and timing of risk management processes should be documented. Risk categories must be defined; and the different levels of risk probability and impacts specific to the project context should also be defined and documented. Equally important is the definition of the methods for reporting risks and their mitigation, and the tracking of risk mitigation activities

You may be asking how all of this risk management planning is relevant to the people aspects of project management for which I so strongly advocate. After all, haven’t I just described risk management planning in terms of the technical and/or process aspects of good project management?

Yes and no. Having participated in projects in which risk management planning and execution was either poorly done or not done at all, and which did not reach all their objectives as a result, risk management planning is more than just a process exercise for the benefit of project outcomes. Careers, end-users, and the constituents served by the new system (i.e. people!) are affected when risk management is not planned for and executed appropriately.

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.