A Risky Upgrade
Sometimes the simple projects are the ones that carry the most risk. A few years ago, a large organization undertook a project to upgrade its HR software. Since the upgrade was to be handled as part of a renewal of an existing contract, the Sponsor and executives considered it a necessary project with minimum risk.
After the project began, the PM and Sponsor learned that the upgrade would require offsite cloud storage for the first time. The executives had approved the project in concept only, so this information was treated as a clarification instead of a change. Since there was no impact to the project schedule or budget, there was nothing to trigger a change request.
As far as projects are concerned, this one concluded successfully. However, no one realized its overall impact to the organization. You see, the executives had not yet decided on a cloud strategy (i.e. what kind of information would be stored in the cloud and what kind of cloud structure would be used to ensure proper security). In the end, they were surprised to learn that the Sponsor for this small project had effectively made an enterprise-level decision involving the security of employee information.
Fortunately, you can avoid this scenario in your organization by following these four best practices.
- Start with the details.
The example above is the perfect illustration of why executives need project details to make informed decisions. In this case, if they had required more information before approving the project, they could have identified the new cloud-based requirement, and then consulted with specialized units (ERM, IT, and Legal) to determine the best approach going forward.
If leadership will agree to start with the details, and approve each project based on research and analysis, they can minimize surprises (and risks) downstream.
- Partner with the PMO.
Since organizations rely on projects to bring about change, and those projects affect enterprise risks, one would think that ERM would be heavily involved in identifying and managing project risks. However, as far as the disciplines are concerned, ERM has focused on the high-level risks, leaving PMs to handle everything project-related.
The example above illustrates how this can create a large pool of unknown, unrealized risks to the organization. The best way to avoid this is to close the gap between ERM and the PMO by creating a partnership.
To begin with, ERM should make sure that the PMO understands and has access to the current list of enterprise risks. The PMO should then grant ERM access to the project portfolio.
The next step is all about training and ongoing communication. The specifics of your organization would determine the complexity and frequency of these activities. Perhaps ERM needs to train the top PMs on how to spot enterprise risk. Or maybe liaisons should meet regularly to discuss updates. While there is no single method that works for all organizations, it is clear that ERM and the PMO work better as partners.
- Develop a cohesive risk methodology.
The Project Management Book of Knowledge, or the PMBOK (http://www.pmi.org/), sets the standards for project management. While it goes into great detail about identifying and managing project risks, it fails to even mention Enterprise Risk Management as a discipline or a potential stakeholder. That’s probably because PMs are tasked with identifying risks to the successful completion of the project, not the project’s risk to the enterprise.
Because of this, PMs can go to great effort to develop their own processes to identify, score, and manage risks to the project—completely separate from those processes already established by ERM. This can cause a lot of confusion when ERM and leadership try to identify the potential impact of project risks to the organization.
The best response to this is for ERM and the PMO to develop a cohesive risk identification and scoring methodology. This doesn’t mean the same methods and matrices have to be used for both disciplines, just that the outputs of each process should be compatible with each other.
For example, the PMO may decide to utilize a risk rating of High, Medium, and Low, while ERM may use a specialized numeric risk matrix. This is perfectly acceptable as long as both departments understand each other’s processes and terminology and any dependency between the two areas.
- Support beneficial changes.
No matter how well the organization plans—and how much involvement ERM has in the beginning—projects still carry risk. Sometimes that risk can’t be fully understood until the execution phase. In other instances, emerging risks or issues hit the organization, making the project more risky than when it was first assessed.
This information is only beneficial to the organization if leadership is willing to change or drop the project midstream. Unfortunately, it’s human nature for executives, Sponsors, and PMs to want to finish what they started; anything less is deemed a failure.
As a risk manager, you have to fight against that tide and encourage a new standard: pulling the plug on a project is a good thing if it’s good for the organization. Indeed, if leadership is firmly against taking such action, then why monitor risks at all?
I understand that partnering ERM with PMO might be a novel idea to you or your leadership, and it may be daunting to suggest changes that aren’t outlined in the PMBOK or ERM text books. However, the success of enterprise risk management is based on challenging assumptions.
In that spirit, I want to challenge you. Don’t settle for the status quo. Lead the way to success for your organization.
I’d love to hear your feedback! Please leave a comment below, or join the conversation on LinkedIn.
This post focuses on the methods you can employ during the project lifecycle. For more on ERM participation in the strategic planning process, see Part 1 of this blog series, “3 Ways to Reduce Risk in Your Strategic Planning Process.”
About the author
Ashley Jones recently joined ERM Insights by Carol. She graduated from Florida State University in 2003 with a B.A. in Risk Management and Insurance and obtained the Project Management Professional (PMP) designation in May 2012. Ashley has fourteen years of experience in the fields of insurance and risk management, most notably as a Senior Risk Analyst within the ERM department of a $7+ billion property and casualty insurance company. When she’s not working on project or risk management, Ashley is busy writing, blogging, teaching, and speaking on a wide variety of topics.
