In the previous posts in this thread we looked at various types and classes of uncertainties and discussed how and when they are likely to be identified and selected for inclusion in a project’s Risk Register. In the final post of this series, we will look at how to build a repository that can streamline this process by storing uncertainties and qualifying information about them in a structure that facilitates querying and filtering them. Lessons Learned data is an important part of the PMI Project Management improvement process and optimizing the ability to maintain, manage and reuse this information can only accelerate the maturity of your organization’s project management capabilities.
A MUTI-DIMENSIONAL APPROACH
In the previous post, we stressed the need for comprehensiveness—clearly, unidentified uncertainties can’t be managed—and suggested that using a pre-determined framework can be useful to help insure it.
Two frameworks that we discussed include:
- Overall project priorities, viz. the Triple Constraint
- Scope
- Time
- Cost
- Project success factors, overlaid on the PMI Project Lifecycle:
Other categorization schemes might include areas such as:
- Meeting regulatory requirements, such as certifications for functionality, logging and auditability
- Meeting enterprise security and data privacy standards
- Meeting enterprise technical, architectural, interoperability or operational standards
- People, processes and technology
- Your organization’s Business Units or departments
Each of these schemes might highlight additional or different uncertainties and success criteria on the project and, thus, create additional items that will have to be accounted for. Now, all of these frameworks will have some overlapping issues but since the goal is to identify them comprehensively, redundancy is OK.
OUTPUT TAGET AND REPOSITORY DESIGN: THE RISK REGISTER AND THE RISK REPOSITORY
The risk information will be used by the PM team in the form of Risk Register entries. Therefore, it will make sense to store the data in the repository in a format that will facilitate its use for that purpose. Here are typical data elements that are found in a risk register and which, therefore, should be included in the repository:
- Project ID, Risk ID, Name, Description
- The Project ID is specific to the project and the Risk ID is a key to the risk’s ID in the repository. Concatenated, these two values should constitute a unique ID for the instance of the risk on the project.
- Status
- Does this risk still need to be assessed, monitored and managed or have the activities with which it is associated been completed?
- Categories
- To which areas does this risk relate?
- Assessment: Probability (1-10), Impact (1-10), Score (Probability x Impact), Ranking (sort by score)
- How important is this risk?
- Onset Process Group, Work Package association(s)
- When in the project lifecycle is this risk likely to occur and to which work packages is it related?
- Trigger, Response, Response Cost
- What might trigger an occurrence of the event this risk represents?
- What should be done if it occurs and what will it cost the project?
- Owner
- Who is responsible for analyzing, formulating a response for and managing this risk?
- Update Date
- When was this risk last reviewed or updated?
Note several things about the risk register that will impact your repository design:
- You will need to keep data at both the global and project levels. It may well be beneficial to keep project risk instance information, such as Assessment information or WP-relationships, in the repository for reference purposes, even though it will be different for different projects.
- The repository must be designed to support one-to-many relationships between individual risks and categories and risks and WPs.
- The categorization scheme should not be limited to a single set of categories. There are a variety of strategies available for building a multi-dimensional structure.
- The repository key structure should support these requirements:
- It has to support two one-to-many relationships—risk to category at the global level and risk to work package at the project level
- It should provide a hierarchical structure to maintain a global (abstract) risk definition and subordinate instances that are imported at the project level. A multi-part key should serve this purpose.
FUNCTIONALITY
A goal of the global risk repository is to maintain an archive of uncertainties that have been identified and used on projects and categorize them in such a way that they can be easily filtered and searched to select appropriate risks for reuse on new projects. Therefore, a simple mechanism that supports filtering, exporting and importing as well as redundancy resolution when moving data between the register and repository (or vice-versa) will be required.
Generally, the idea is that a user will search the repository based on the categories you have provided and extract the risks tagged with them to the project register. From there the user can review and either keep or delete them. When the project is completed, the project risk register can be imported back into the repository as part of the Closing process.
SUMMARY
This series of posts has addressed how to create an inventory of risks to jump start the PMI Manage Risk process. The following areas were covered:
- Aligning risk prioritization with enterprise project goals; Risks and the Triple Constraint
- Use of Initiation work products to help identify risks for inclusion
- Macro (project-level) vs. Micro (Work Package-level) risks and where they fit in the PMI project management lifecycle
- Using a project success criteria list as a basis for identifying relevant risks
- Using various frameworks as tools to ensure comprehensiveness in the risk identification process
- Adding value to the PM process by creating a repository that facilitates reuse of the risks identified for historical projects