Risk Management in Project Management is an critical discipline. Success or failure in our projects is a direct consequence of Risk Management.
How can we ensure our risk management program is going to provide valuable information that will help us manage our projects? From working on many projects managing the risk environment, it is all about knowing where to put our focus. I have stepped into many projects where the risk management program is managed as a separate entity, and the information gathered from the process is not used to help manage the project.
Too many times, as Project Managers (PM) we tend to get wrapped around the axles of requirements, processes and problems (all important!) but not at the expense of losing the focus of the end game, the “fit-for-use” deliverables we are producing for our customer.
Deliverables Centered Project Management (DCPM®), is all about managing what matters: the deliverables. So how can we as PM ensure our risk management program is also deliverables centered and we are mapping our risks to our project’s deliverables?
First, stop and understand the importance of changing gears and understanding the value of DCPM. Our project sponsors or Project Directors want to know if we as PM can manage their resources and budget within an agreed upon timeline to create the deliverables they asked us to produce. They want to know if we can implement Risk Management before we are dealing with issues that soon overtake our projects.
As a risk management professional, my goal in this article is to provide the tools for project managers, risk managers, Business Analyst (BA) and project team members to use to ensure your risk management environment is started when it should be, risk is managed correctly at the stage you are at, and managed as proactively and collaboratively as possible. Knowing when to identify risk and what risk looks like depending on where you are in the project lifecycle is important to know. Risks at the portfolio level are different than the ones at the project initiation and at the project level. The concept of what a risk is remains the same no matter where you are in the project’s life, but managing the risk environment will be different.
What You Will Learn
Risk Management at the Portfolio Level
At the portfolio level, projects are chosen based on the strategic goals of the organization. Strategic risks still need to be identified, analyzed, prioritized and managed however, prior to any project’s initiation, the organization has gone through a process to determine what projects the organization will undertake. So the risk process at the portfolio level will be to determine the business activities the organization will take on. Business cases are developed based on what projects each organization will be performing based on their strategic planning. As new projects are proposed, the mapping of the project is made to the organization’s strategic goals to determine if the proposed project is in alignment with the goals and initiatives. If the proposed project aligns with the strategic goals of the organization, the business case will propose a solution to the stated dissatisfaction with the status quo (DWSQ), and then the project can begin its initiation phase.
A part of this decision includes the discussion of the organization’s portfolio risk tolerance to determine the acceptable amount of risk that an organization will withstand based on the strategic plan. If a project is aligned with the organization’s strategic goals, but it is well beyond the portfolio risk tolerance for that organization, the project should not be accepted for implementation. Understanding the risk process at this level means to understand risks are decided upon based on the tolerance of the organization and not project deliverables at this point.
Once a project is accepted, the project lifecycle starts with the project initiation activities. Risks are no longer decided upon based on any risk tolerance level as once a project is underway, risks cannot be ignored or not tolerated, and they must be mitigated by some risk management approach.
Risk Management during Project Initiation
During project initiation, risks are identified and managed differently from risk management at the portfolio level. Think about it, the deliverables of these two stages are different. During the portfolio stage, the focus is on whether or not a project will be chosen as an optimum ingredient to the organization’s mission/vision initiatives is based on the level of risk that is present. If the risks are too great for the organization based on their strategic goals, the project should not be acceptable. At project initiation, all risks will be managed as the level of what was a tolerable risk has already been established. ALL risks will be managed as it is not a choice of whether or not the risk is too great, it is now that fact that the risk exists and cannot be ignored. Once a project is at the initiation stage, factors such as the size of the project, the complexity, the number of interacting stakeholder groups that are on the project, and the number of outside mandates are all important when developing your risk management environment, but more importantly, it is critical to understand when and how to implement the risk environment for ultimate success.
During the initiation phase, the project charter is developed followed by a detailed project scope statement. Many times the project scope statement is written in the form of a project scope management plan to include:
- Project Deliverables
- Project Major Objectives
- Users of the Deliverables
- Features and Requirements
- Cost Estimates
- Milestones
- Deliverables Acceptance Criteria
- Projects Assumptions and Constraints
- High Level Risks
Reviewing lessons learned and risks from other projects can be crucial to your project’s success. Many risks that PM deal with on IT projects are the same risks that have been dealt with on similar projects. If the PM on the other project did lessons learned correctly, a wealth of knowledge can be brought to bear on the new project.
Remember, the definition of risk is an uncertain future event that if it were to occur will have a negative impact on one or more of its project’s deliverables. Without project deliverables there would be no risk! Entering a project without knowing the risks involved is not responsible actions for any PM.
As the project at this point will have a listing of high level project risk potentials to be addressed and managed. As they are high level at this point, the full risk register does not need to be filled out, but I would recommend putting the risks in the Risk Register to later close out to keep a record of the risks being managed. As the PM and the team go through the assumptions and constraints, there are more than likely risks that need to be addressed. Assumptions remember are things that are believed to be true. Constraints are fixed boundaries, conditions or limits from the project initiation such as technical constraints (hardware, software) or business constraints (limits on the solution based on the organizations strategic plan)
Risk Management at the Project Level
As the project moves from the initiation phase of the project into the project planning and execution, the risk management environment needs to change from managing risks at a high level minimal approach to a much fuller detailed approach. A fuller more robust risk management plan (RMP) should be developed as a part of the project management plan, or in the case of larger or more complex projects as a separate plan. Even though the risks from the portfolio level were to determine whether the project should be accepted for implementation, any risks from the portfolio level need to be re assessed at the project level to determine what if any are project level risks that should be assessed.
This article will provide at a summary level, the outline of the risk management components required at the project level. If you wish a deeper dive into this discussion, please following the articles on this topic in the Project Post-Gazette or on our MCLMG Publishing and Research Blog. It is most important to understand the depth and proactive steps involved once the project gets started. Below is a brief outline of the steps recommended and risk components for your risk environment.
Project Level Risk Management Program Initialization Steps:
- Review of the “As Is” risk environment
- Determine the “To Be” risk environment based on:
- Organizational requirements (processes and procedures required at the organizational level)
- Government mandated regulations and statues
- Determine the projects parameters:
- Size of project
- Project complexity
- Interacting stakeholder size (i.e. number of contracting groups are interacting)
Risk Components:
- Risk Management Plan (within Project Management or separate)
- Risk Communications Matrix (within Communications Plan)
- Senior management
- External stakeholders
- Internal stakeholders (project team)
- Risk Roles Matrix
- Risk Artifacts to be developed
- Risk Register
- Issues Log
- Risk Dictionary
- Risk quantitate assessments
- Risk Probability of Occurrence (RPO)
- Risk Cost of Impact (RCI)
- Risk Equivalent Value (REV) Matrix
- Risk tools and techniques
- Risk causes and effects
- Trigger assessment
- Additional Risk Plans and Action Plans
- Escalation Plan
- Risk Auditing Plan
- Risk Trigger Management
- Risk Causality Management
- Risk Metrics
- Risk Training
As a PM, when you are managing risks at the project level, you have to proactively manage your risk environment regardless of whether or not your appetite is risk adverse. In other words, get hungry and manage your risks.
