As we continue the discussion of risk management concepts in the PPG we will continue to talk about risk management at the Portfolio, Program and Project Management (PPPM) levels in more depth. MCLMG Publishing and Research has discussed many different views on the purpose of the PPPM and their functions in the PPPM Roadmap set of articles. The purpose of each function is important to understand to be able to better manage the risks that fall under each layer.
From my personal experience, PM and the project team continue to struggle in the identification of risks within the correct PPPM layer which leads to many risks triggering into issues as they were identified and categorized under the incorrect layer. Understanding what risks should be identified under the correct PPPM layer is therefore critical. If the PM and/or the project team fall into the trap of managing the wrong risks, the team will find that these risks cannot be mitigated and valuable time was wasted in the eventual discovery that they could have been escalated to the proper level for effective treatment.
This article is focused on risk management at the project level. As a visual reminder, chart 1 below is a chart showing the PPPM concept that has been the focus of several PPG articles on the PPPM environment which you can find under the PPPM Roadmap columns.
Chart 1. Portfolio, Program and Project Management (PPPM) Focus
For the project level, the characteristics are as follows:
- Focus is on the execution of the project plans.
- Component: utilization is the project deliverable
- Objective is to optimize the project’s constraint regardless of external impact, and
- Goal is to achieve the customer required quality metric defined as the Fit-for-use deliverable.
The project level is the executable layer of the PPPM with the primary objective being focused on the optimization of producing quality fit-for-use deliverables. From a risk perspective, it is critical for the sponsor, the PM and the project team to understand the purpose of the project level in order to understand their responsibility in the risk management and risk mitigation strategies of each risk potential.
The purpose of each layer does not change the basics for Risk Management at the PPPM levels which are the same: risk identification, risk assessment (quantitative and qualitative) and managing of the risk environment. It is not the management of risks that is of concern, but the identification of the right risk potentials themselves at the right level.
The risk environment at the project level will look for risk potentials that threaten the production of the project’s deliverables. The project manager will plan, execute, and manage the project and the deliverables according to the project’s charter or Statement of Work (SOW). The focus for the PM and the team should be on the planning, execution and management of the production of deliverables. The risks identified should be focused on uncertain future events that if they were to trigger would prevent the PM and the project team from delivering these fit-for-use deliverables.
Project managers should focus on the risks that might affect their projects deliverables and not make the mistake so often made of trying to manage risks at the program level. One way to ensure your risks are project risks is to understand your deliverables and determine what will be the impediment to the completion of the project’s deliverables under the given constraints. Risks that are not directly tied to your deliverables are more than likely NOT a project level risk, but either a program level risk or a portfolio level risk that should be managed at that level.
If a project’s deliverable were say to deliver a “Graphical Tool” to aid in the design of a video game, then the core deliverable is the production of this fit-for-use graphical tool to the customer. Additional deliverables during the project lifecycle for the project could be: a requirements definition document, a software model (use cases), a system prototype, test cases, etc.
Let us walk through a scenario of how the PM and the project team can go down the path of missing true risks for this project. Let me give you an example of a listing of risks from recent IT software projects discovered through an Internet search of problematic projects:
- User involvement
- Executive support
- Requirements inflation (or scope creep)
- Schedule flaws
- Unrealistic expectations
- Staff turnover
- Project management
The question you should ask is: “are these risks tied to the projects’ deliverables?” Right off the bat, executive support, staff turnover, and project management should be the focus for the Program level, as the projects primary focus is on the deliverables and not resource or tactical management.
User involvement, requirement inflation, schedule flaws, etc. are not risks, but they could be causes to risk potentials. You cannot tie them to the deliverables. I hope you are starting to understand the reason so many project fail to manage their risks correctly. Another important conclusion is that focusing on the project’s deliverables will provide the necessary clarity needed to identify the true risks for your project.
While there is so much more that could be discussed under the umbrella of identifying true risks from their causes, we will save that discussion for another risk article. What is important is the project level is the most important level of the three layers as this is the layer where the project is executed and identifying risks that fall under this layer are critical to both identify and mitigation given their direct impact on the production of fit-for-use deliverables.
Many factors influence PPPM performance such as schedules, resources and funding; however, one factor stands out above all others that can make the difference between success and failure: identifying and managing the risk potentials of each of the PPPM levels at the right level. Organizations need to manage risk more effectively by understanding how the project level’s risk environment is so critical towards achieving this objective.