Skip to content

Expert Talk on Risk Management with Cheryl Wilson

A few days ago we enjoyed our ProjectManagers.org Expert Talk with Cheryl Wilson about Risk Management. You can see our interview here:

Cheryl Wilson is an Insightful Risk Management leader with 15+ years’ experience in blending customer needs, technological innovation and customer project management requirement to successful project solutions. Results-focused Project Manager bringing innovation, energy, and insight to optimize project success. Skillful strategist able to transform vision into reality as evidenced through delivery of multiple new risk management concepts, on target risk solutions and customer specific solutions. Key strengths in building, developing and leading effective teams. Metric focused and strong believer in what gets measured gets accomplished. Excellent communicator and strong leader able to build cohesion in diverse, global environments.

Cheryl provides consulting expertise in all areas of PPPM (P3M, that is Portfolio/Program/Project Management). Specializes in the development of Risk Management Environments for Portfolio/Program/Project Levels. Develops specialized risk management training for clients on demand. Provides consulting in setting up Compliance and Ethics Framework within Organizations. Develops priority and standard tools and techniques for Risk Management Programs based on portfolio-wide compliance to portfolio standards, processes and policies. Speaker and mentor.

She is also a featured columnist on:
http://dcpmblog.mclmg.com  MCLMG Deliverables Centered Project/Risk Management Blog  
http://projectgazette.com MCLMG Monthly Newspaper for PM’s / Risk Management / BA / Ethics / Compliance 

Webinar Transcript

Here you can read our interview:

Q: Why do we need Risk Management? 

A: It is an area that can increase the success rate a lot of the projects out there. As you might know, if you’ve been reading that projects today are becoming very complex and also very visible in the failure rate. In fact the Gartner group of 2011 said that projects were still failing at the rate of 70% – 80%. So as you know that senior management is, of course I’ve said about this, they’re concerned about project failure, they’re concerned about the waste of their dollars, they’re concerned about the project going on the tube. So they’re looking for ways to improve their project success rate. So one business improvement process that organizations can do, and they can do it right is implement the Proactive Risk Management program and my business partner and I call this the PRM program as opposed to what a lot of programs have out there and that’s a reactive program. I believe that a lot of folks, a lot of project managers feel that Risk Management is a lot of work and so they try to trim it down and they try to have kind of the minimal they can have because it does take a lot of work, but what’s happening is, and you can tell with 70% – 80% projects failing, projects are (in the Risk Management area) in the reactive mode and set up for proactive mode and it does not take that much to really turn a risk program into the proactive mode and in a long run when you reacting to risks you’re spending a lot more time with your recourses off into another things to react then being into proactive mode. So, one of the first things that is a good point to remember about the Proactive Risk Management program is – it provides a clear understanding to Risk Management to your project team. If they know how to indentify risks, if they know how to escalate a risk, they know which risk belong in the project, which one should be escalated to senior management, they’re going to feel more comfortable within this program and they’re going to be more interactive with it. And another one, you may have to think about this one, but you need to explain, you need to modify the human behavior. Risks are really action, or inaction of human behavior. And then it looks at the precursors of what leads to project failure and imperatives of first management programs get in front of those precursors. These precursors are actually are actually risks on our projects and we need to be able to manage them, be in the front of them and be proactive in managing them because the ultimate goal is to manage what we call “fit for use” deliverables. And what I mean by “fit for use” is deliverables that the quality metric is already being signed up by the customer. So, when you get to the end of your project and you deliver your deliverables they’re not surprised, they already know because they signed off on them, so they’re going to accept them.

Q: What is a good definition of project Risk?

A: There are a lot of definitions that are out there, depending on your standards that you’re reading. But, having worked in the Risk Management area, worked on the trouble projects and having worked on a lot of in depths portfolio level Risk Management situations. The definition that I like to explain to my project teams is an uncertain future events that if it happens will have a negative impact on your project “fit for use” deliverables. All risk, except for those that are systemic risks, and I’ll explain those in a minute, should be tied to one or more project deliverables. When I say systemic risks you’re going to have some risks that are possibly going to affect your project, but your project managers and your team may not have to do anything about them. For instance, whether political environment and things like that. The risk potential it should be logical that we can’t resolve it, what we have to do is we have to mitigate it.

Q: What is the difference between a Risk and an Issue?

A: Well, it’s a very important definition that you understand the difference between the two. I know that a lot of projects just talk about risks, they don’t talk about issues, and in fact a lot of projects are dealing with issues instead of risks. So to know the difference between the two and having your team understand the difference will really set your project up for a success as opposed to a failure. So when I have the definition of risk a few minutes ago when I said it was a negative, it was a potential future invent that can have a negative impact if that event were to actually trigger into reality what you have now is an issue. And there is no longer the probability to impact that because you have realized impact at this moment. Since your issue is currently reality now you can’t mitigate reality, you have to resolve it. And if you’re ever been in a situation within a project where you dealing with issues you’re spending a lot more time, your resources are pulled off your project, pulled off the schedule to actually spend time resolving and issue. So, you mitigate risks, but you seek out to resolve issues, and it’s really critical to understand the two because risk is critical, because risk can disturb your normal project activity if they’re triggered and they end up being an issue. Because issues will directly impact your project team’s attention, it will pull them away from what they’re doing. And a good quote that a friend of mine told me a while back which I remember and I quote this a lot from a CJ Stoneman, he says: “It’s better to mitigate a risk than to survive an issue.” So, instead of being in a mode where you are reacting, it’s better to be in a proactive mode because your team when they’re in the reactive mode their dealing with the issue is so, your schedule and your budget, all those things become so pulled away from what’s your supposed to be doing and that supposed to be any senior project that you’re going to find failure rate increase a lot faster.

Q: What are the differences between Risk Mitigation and Issue Response?

A: This is a great question and you’ll find on Linkedin, you’ll find all over the places in different practices the terminology of risk mitigation and issue response. You’ll see them slightly different than the way I’m going to explain them here. And the reason why I’m going to give you an explanation that I feel is a solid explanation is dealing with risk on teams form many, many years. Risk mitigation, in a mature organization, they understand, they identify, they manage risk primary components. When I say components I’m talking about the probability of the risk happening and the impact on the projects if it were to occur and I’m also indicating that looking at the cost impact when you look at the reducing the Risk Probability of Occurrences, we call it RPO, and the Risk Cost of Impact, RCI, what you have is the Risk Equivalent Value. Let me give in an example. Let’s say on a project you have determined that the monitoring value, if that risk were to trigger is a 100,000 dollars and a chance of this risk become an issue is 1%. The REV (Risk Equivalent Value) would be 100,000 times 0.01 (or 1%) or $1000. In proactive risk management it is the REVs that prioritize your risk and bilge your mitigation plans. If you use determines factor that is kind of a standard out there the probability times impact without bringing the cost factor you have a more subjecting listing of risks and I find that’s why a lot of projects tend to get lost in the risk management. They may have a hundred risk, they may have start to do the probability impact that you still left very large group of risk that you haven’t qualified down to a cost factor and issue response. The once risk potential has experienced the triggering event the project team will immediate start to implement the response plan and proactive programs have already taken some of those risks that have a high REV and actually put together a planned issue response plan. And it’s a plan that is prepared so if your risk were to trigger and your mitigation plan has failed, your response plan is going to be different than a plan you have to reduce that risk. So by having the response plan already ready, your in a more proactive environment. In any case, once a risk becomes an issue, a risk mature organization will minimize the time and cost of that issue so that the team can get back to what they’re supposed to be doing and that’s managing the project with their deliverables on schedule and on budget.

Q: In what phase of a project should we start Risk Management?

A: In my opinion, any time you say it’s never too early. I even feel that back when the Business Analyst (BA) is collecting the stakeholder requirements and the stakeholder analysis that they’re going to be determining a lot of risks at that time, even issues, and if they can mitigate the risk at the beginning when the project is starting to be developed then you’re way ahead in the game. Many, many risks are identified too late in the project and so in our definition of risking issues they’re dealing more issues which throws them into more of a reactive mode than a proactive mode. So the earlier the better, because you’re being more proactive than running your risk program in a reactive mode.

Q: What is a good way to implement Risk Management?

A: So, we talked so long about proactive and reactive, so definitely a proactive mode and I can’t emphasize enough that doing risk management in a reactive mode is why most risk management programs fail in projects, since why a lot of project managers don’t want the risk management program there. So, a proactive mode is actually the best mode. Let me kind of give you a little scenario on both of them. A Proactive Risk Management mode – risk management is planned, it’s a continuous upgrade of the understanding with your project team. It’s looking at risks before they end up being triggered risk into an issue. It’s addressing risk through planning and mitigation and looking at the cost factor. Not a lot of projects do this. Being proactive is immaturity process that a team and a stakeholders and a project management need to plan ahead in time and work hard to have established on the program. On the other hand, a reactive mode is a qualitated list of your risk being listed. Your having a lot of risk that have mitigation plan established for them, you have no cost factor that is being rode in, your identifying risk without sometimes even scoring them. You’re scoring them without really understating the true impact of your project. And a lot of time I’ve seen projects, major projects wait until they start to have identified a few risks before even start the process with their teams. Their teams have no idea what types of first management your going to implement, they don’t know processes procedures, they don’t know how to escalate a risk, they don’t even know how to report a risk to the team, or what the register looks like, or who the ownership is, or who’s owning the risk, who’s pay them on the risk register. If you wait into later interactive mode your success rate is really going down. So just to recap because this is an important question. Proactivity means that the PRM program seeks to improve its own effectiveness in dealing with risk mitigation by:

  • Implementing risk mitigation earlier in the project’s lifecycle,
  • reducing the severity of high REV risks, and
  • “short-circuiting” risks that have triggered into issues by effectively implementing the response required.

We’ve put together eight points and I’ll go over them here. I know you’ve been so kind on your web site to include a link to our blog and our newspaper and shortly we’ll have a web site. These eight points explain more in whitepapers and new books we have out there but if you implement these eight points and your diligent about doing this, you are maturing your organization into proactive organization when it comes to risk:

1.       Obtain senior management support for a Professional Risk Management (PRM) program
·   The risk program needs to be encompassing, even intrusive into all areas of the project when attempting to identify and manage risks that can impact the project’s deliverables. This will take senior management to provide that tone of support. 
2.       Accomplish mindset change through Professional Risk Management (PRM) training for project teams.
·   A good Professional Risk Management (PRM) program is the only project component with the ability to provide oversight into the inner workings of a project. It may be taken it as a threat to PM’s authority. My experience is that many project managers do not possess the mindset needed to support a strong Professional Risk Management (PRM) program.
·   Training is therefore an excellent way to support the necessary mindset change required by a PRM program.
3.       Establish goals and objectives for the Professional Risk Management (PRM) program. 
4.       Understand the parameters of the project.
·   As every project is unique by the definition of its own deliverables being distinct and separate, a Professional Risk Management (PRM) program aligns itself to the parameters of a project that define its existence. These project parameters include, but are not limited to:
·  Project type: IT, manufacturing, new product development, construction, etc.,
·  Project size: measured by either budget, team member count, stakeholder population, etc.,
·  Project complexity: is the project a simple document creation or does it seeks to deliver a hydroelectric dam in a remote area of the globe?
·  Project novelty: how new is the project or its deliverables to the customer’s organization?
5.       Determine Professional Risk Management (PRM) program roles and responsibilities. 
6.       Define Professional Risk Management (PRM) processes, tasks, procedures, and activities.
7.       Develop Professional Risk Management (PRM) value metrics.
o   Metrics for identifying, tracking, and reporting on its progress towards achieving its objectives.
o   There are many methods for tracking performance, but in risk due to the nature of dealing with future events, the performance metrics can be somewhat complex and mathematically challenging since we are dealing with probabilities of future uncertainties.

8.       Monitor and manage the Professional Risk Management (PRM) program.  

Q: Sometimes we get a gut feeling about potential risks. And sometimes we might think a risk is small to include. What should we do with any situations where a potential risk could be deemed too small or irrelevant?

A: You know, this happens a lot. It happens more than I care to admit on projects that I stepped into. I heard that project managers, really good project managers, tell me that, they would tell me: “I thought I can deal with it as I was managing my program, I was doing a good job, it was just kind of going away from me.” So, they didn’t report it and I found later on that I had it reported even if it’s a small risk, and they put it on the bottom of the list and they just had it so they could keep track of it. They’re not going to lose track of it and it’s not going to all of a sudden mushroom. And if you have a risk identified then your project team is also helping you, you’re not alone running a risk management program, it takes the entire team. It could example as a BP oil. Three years later I heard on the news lately that they’re still dealing with the catastrophe. Now that risk was, in their mind, it was a low probability of happening but the consequences of that risk, as we all now, is pretty much ruined the reputation of BP. So, I don’t think any risk is too small. I think it’s how you manage those risks, which is more important, because mitigation on even small risks, the time it takes is much, much better than trying to play catch up if it does trigger into an issue.

Q: Do you have any final advice about doing Risk Management?

A: Well I could repeat myself again and say be proactive, and I’ll say it be proactive! The basis for proactive risk management is the modification of human behavior. If we can get the teams to understand the importance and identifying risks early, ensuring that they’re doing the best they can to play some good mitigation strategies – that’s a first step. Also, really looking at those project precursors that are some precursors to project failure and get in front of them. Proactive Risk Management means working on a Risk Equivalent Value through successful mitigation activities, really being diligent about that, looking for the root causes. That’s a whole another topic on the mitigation strategies on how you can reduce you risks but, being diligent about putting together good mitigation strategies and just planning early in your project, and the key is don’t let your risks run you and your managing program. And as I mentioned, there’s a lot more out there. My business partner Paul Lohnes and I are passionate about project success and a Proactive Risk Management program is such a key fact for success of your program so feel free to visit our links and ask us questions and read some of the white papers we have out there on RMOs and any other topics that we discussed here today.

 

For more information about Proactive Risk Management, read: 

  • Proactive Risk Management: An Argument for Project Risk Management Maturation 
  • Implementing an Effective and Proactive Risk Management Office (RMO) 

You can find both documents at: http://dcpmblog.mclmg.com

For more information about Cheryl, visit: http://about.me/CHERYL_WILSON