How is it possible to manage risk during the very process of identifying risks? And six ways to do so? Really?
I once read an article that claimed that 90% of project risk can be reduced or eliminated by using sound risk management processes. I remember thinking that the statement must be pure hyperbole. No studies were cited. No data were analyzed. No anecdotal evidence was provided.
At the same time, it occurred to me that if we as Project Managers focused our efforts to identify risks in a serious, comprehensive way, we certainly would be able to reduce or eliminate a high percentage of project risk. Maybe not 90% as noted in the article, but enough to make a significant difference to the bottom line. All too often we perform risk identification haphazardly, half-heartedly, and in ways that are actually detrimental to our project performance.
The following six considerations will help ensure that our risk identification is pursued creatively, thoroughly, and practically. Focused attention on identifying risk will pay huge dividends in managing risk.
1. Identify risks early. What’s the old saying – “To be forewarned is to be forearmed.”? One of the first exercises to be undertaken by the project team, even as project execution is getting underway, is the identification of risks. Experienced project teams have access to their organization’s risk policy, checklists and lessons learned from other projects, procurement and project charter documentation, stakeholders, and other such sources for identifying threats and opportunities to the project. The earlier that risks can be identified, the less expensive to manage them. The earlier they are identified, the less impact on later project phases where their effects are often exacerbated.
In an earlier blog post (“How our Client’s Risk Planning Saved the Day”),
2. Identify risks ongoing. How many times have you seen a great Risk Management Plan developed, complete with a thorough identification of risk events, only to later find it on a shelf gathering dust? But here’s an undisputed fact: risks don’t stop with those identified at the outset of the project. They keep coming.
In my mind, this is a form of professional arrogance. Let me paraphrase a statement by a seasoned Project Manager: “I’ve seen everything. I’ll know risk events when they appear, and I’ll handle them then. Why worry about something that may not happen anyway?”
Consider this scenario. We were over a year into project execution when I began to observe a key technical resource behaving oddly. Members of the team also noted some inconsistent behavior in her actions. As part of our ongoing risk policy, I identified the risk as soon as I and other team members had cause for concern. (I had to tread carefully here as it appeared to also be an HR issue.) Senior management was alerted, and a contingency plan was put in place. When the employee later took a hiatus for a health-related issue several months later, we immediately implemented our contingency plan.
What of the seasoned Project Manager who earlier boasted that he could handle the risk event when it happened? Yes, he would have handled this situation, at what cost? How many days and weeks might have been lost in looking for a replacement technical resource? Fortunately, our organization’s risk policy required an iterative approach to identifying risks. Because of that, our senior management was in the loop early, and we didn’t lose any momentum when the risk event materialized.
3. Use all available sources. I love risk category prompt lists. I love risk event checklists. I love having an established risk policy to guide our risk planning.
But how often do project teams use these as the be all/end all in their risk planning?
I can think of dozens of examples over my career of risks that would never have been identified by solely using available prompt lists and checklists. I learned (after making more than my fair share of mistakes) that each project stood on its own. Yes, there similarities to previous projects provided valuable insights; but what about the risks for this project, at this time, with this project team, for this client?
Every project has many sources in addition to prompt lists and checklists that should be explored for risk identification. Depending on the size and complexity of the project, not all these sources need to be explored; but they are excellent methods for identifying risks:
- interview stakeholders, both those directly involved and not directly involved with the project;
- review procurement documents, agreements, the project charter, lists of assumptions and constraints, and other initiation documentation for ambiguity or clauses that could have negative (or positive) effects on the project;
- brainstorm with team members most knowledgeable in each risk category for their input, including the client’s subject matter experts;
- solicit expert judgment from experienced resources not associated with the project;
- review lessons learned documents from similar projects; and
- perform an organization SWOT analysis to identify strengths and weaknesses of the project team, the client organization, and/or business areas affected by the project.
4. Interview appropriate stakeholders. The first source for risk identification noted above was stakeholders, those directly involved with the project and not directly involved. These are often overlooked; or if their input is solicited, it may not be the appropriate input for what is needed.
Examples from my own project work include the following. In each instance (except the first), interviewing the stakeholders quickly uncovered potential risks to be managed.
- Gaining insight on high-level project objectives and business requirements from the main project sponsor, the CIO. We soon learned that he was not knowledgeable about the business and provided incorrect information.
- Meeting with the project financial sponsors to understand their constraints and stipulations for the final outcome. We learned that they wished to remain arms-length from the day-to-day project execution, which gave us more latitude to function.
- Reviewing supplier agreements to ensure equipment would be delivered and installed in time for deployment. We met with executives above the sales manager to solidify the agreements.
- Clarifying ambiguous policy and procedure rules with the organization’s policy team, who were not involved with the project. We learned that they had no control over how their organization’s workforce functioned, but they were responsible for accuracy of the workforce’s results. We quickly brought policy experts onto the project during the requirements definition.
- Meeting with the Independent Validation and Verification vendor to establish ground rules of when and how to introduce their findings. We agreed to work together closely for the benefit of our common client, and to quickly resolve points of contention that might arise.
5. Create a comprehensive risk register. There is nothing more frustrating when I perform project audits than to find risk events documented in emails, logged in a haphazard spreadsheets of risks, recorded in meeting minutes, or floating around in someone’s head. Risks needed to be managed from a single document – a comprehensive risk register.
A risk register is a single repository that (at a minimum) describes each risk event unambiguously, distinguishes between cause and effect, identifies an owner for each risk, documents potential risk responses and applicable contingency plans, indicates the current status of the risk, and provides dates for resolution.
The risk register needs to be maintained in a consistent manner. Does every risk event have a short title that quickly brings its content to mind? Is the statement of risk written in a structured manner that removes ambiguity? Is an owner assigned immediately? Are risk responses documented clearly? Where applicable, are preliminary contingency plans documented with the risk responses? Is the most current status accurate? Are deadlines for resolution reasonable, and are they timely?
6. Keep the risk register visible. On most of my projects we developed a cadence for recurring project meetings, one of which was the weekly status meeting. A review of each risk event in the risk register was a constant on the agenda. New risks were discussed and added as needed. If a meeting went long, we would ensure that other items could be skipped to allow time for the risk register to be reviewed before adjournment. Not only was the risk register visible in this way, ensuring accountability, it was also accessible to the risk owners at all times for update.
Six considerations for comprehensive risk identification. Six considerations that lead directly to focused risk management. And with the last point, visibility, accessibility, and accountability are the core people aspects of risk management that result in better managed projects overall.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.