Process Group: P
Determining which risks may affect the project and documenting their characteristics.
|1. Risk Mgmt Plan
2. Scope Baseline
3. Activity Duration Estimates
4. Activity Cost Estimates
5. Stakeholder Register
6. Cost Mgmt Plan
7. Schedule Mgmt Plan
8. Quality Mgmt Plan
9. HR Mgmt Plan
10. Procurement Documents
11. Proj Docs
|1. Document Reviews
2. Info Gathering Techniques
3. Checklist Analysis
4. Assumptions Analysis
5. Diagramming Techniques
6. SWOT Analysis
7. Expert Judgment
|1. Risk Register|
10 Critical success factors:
- Early identification
- Iterative identification
- Emergent identification
- Comprehensive identification
- Explicit identification of opportunities
- Multiple perspectives (input from broad range of project stakeholder)
- Risks linked to project objectives (Ref: What is risk?)
- Complete risk statement
- Ownership and level of detail
- Risk management plan – As you may have guessed correctly by now, the risk management plan comes as an input to every risk management process in our project that happens after it is created. As this document explains how risk management activities are to be carried out in our project, it is an indispensable resource. We will be using the following from the risk management plan:
- Assignment of Roles & Responsibilities
- Budget and Schedule provisions & allocations to Risk Management activities
- Scope baseline – The scope baseline includes the Project Scope Statement along with any constraints & assumptions. As you might already know, wherever assumptions are involved, there are bound to be uncertainties and it is these uncertainties that we are looking for. Also, constraints can be a major source of risks. A Work Breakdown Structure is going to give us a detailed perspective of the project work that will be done including tasks and sub-tasks. By going through this WBS thoroughly we can uncover a lot of potential risk possibilities.
- Cost management plan – The Estimating Costs and Determining Budgets process of Project Planning creates the Projects Cost Baseline or in other words the Project Budget. The approach used in managing the project costs can be a major source of risks. For ex: a project that is operating on a tight budget with little room for maneuvering has a great risk of cost overruns. On the other hand, if the project has good cost reserves planned already, then the risks go down accordingly.
- Schedule management plan – The Develop Project Schedule process creates the Project Schedule. By understanding the Projects Schedule and the Schedule Management Plan will give us a good idea of whether the project is operating on tight deadlines or has any slack in terms of completion dates. As in the case of Projects Budget, projects operating on a tight schedule can have a great deal of risk in terms of schedule overruns.
- Quality management plan – The approach to quality management in the project has a direct bearing on the project risks. A Project where a great deal of importance is given to quality related activities to produce a good quality work product usually has lower risks when compared to one that does not follow good quality practices. In cases where the quality or work done is compromised (for whatever reason it may be), risks are introduced. Poor Quality Standards is a major source of risks in many projects. If we address the Quality aspect of our project, we will be eliminating a good number of risks at its source.
- Activity cost estimates – The Cost Estimates are created in the Estimating Costs process and these estimates can give us a good idea of the likely cost involved in all the scheduled project activities. This way we can identify if the project is in any danger of cost overruns.
- Activity duration estimates – The activity duration estimates are created in the Estimate Activity Duration process. The quality and accuracy of the estimates can have a direct impact on the risks. If the estimate is accurate then the risks of schedule overruns are low whereas if the estimates are rough or ball-park then the chances of schedule slippages are pretty high which in turn means high risk.
- Stakeholder register – The stakeholder register gives us details about the list of all people who have a stake in our project. We can use it to identify the high influence group of stakeholders and handle them accordingly. We can also use this document to invite all those important stakeholders to the risk related meetings to ensure that everyone is on the same page.
- EEF – We have learnt what these enterprise environmental factors are many times in this blog. The factors that are relevant in our identifying risks area are:
- Commercial Databases
- Public & Industry studies
- OPA – The organizational process assets include files & data from previous projects. We can study what the actual risks were, the responses that we used and the actual outcomes of the responses. We can utilize this information to ensure that we do not commit the same mistakes as our predecessors. Looking at the lessons learned documents from previous similar projects would be a good idea too. Document Templates also come under this section.
- Project doc – There are a whole bunch of other project related documents that can be sources of risks or risk related information. Some of them are:
If you see closely, the scope baseline was considered as a separate input entity just a few paragraphs ago and has been mentioned again as part of the general term “Baselines” along with the Cost and Schedule baseline. Also, the Schedule Management Plan & the Cost Management Plan were covered already as inputs in detail and their baselines are considered here. This should give you a fair idea of the fact that the golden triangle “Scope-Time-Cost” are the key sources of risks for the Project and need to be investigated & analyzed thoroughly in order to minimize risks and to enhance the chances of the Project’s Success.
Apart from all the above mentioned inputs, any other document or information related to the Project that can be a source of risk or that can provide insights that will help in project risk management can be considered as input to this process.
TOOLS / TECHNIQUES
- Info Gathering techniques
- Delphi technique
- Root cause analysis
- Diagraming techniques:
- Cause & Effect diagrams
- System / process flowcharts
- Influence diagram
- Document review
- Checklist analysis
- Assumptions analysis
- SWOT analysis
- Expert Judgment
Identify risks tools / techniques by Practice risk for Project Risk Management
|Assumptions & Constraint analysis||– Simple structured approach
– Can be based on project charter
– Generated project specific risks
|– Implicit / hidden assumptions or constraint s are often missed||– Requires a comprehensive list of assumptions and constraints.|
|Brainstorming||– Allow all participants to speak their mind and contribute to the discussion
– Can involve all key stakeholders.
– Creative generation of ideas
|– Requires attendance of stakeholder. Difficult to arrange and expensive.
– Prone to groupthink
– May produce biased results by strong person (management)
– Often not well facilitated
– Requires filtering
|– Attendance group of stakeholders.
– Commitment to honesty.
– Good facilitation.
– Use of structure (categories or RBS)
|Cause and effect diagram (Ishikawa)||Visual presentation||– Diagram can quickly become over-complex||Effective selection of critical impacts.|
|Check lists||– Captures previous experience
– Presents detailed list of risks.
|– Checklist can grow to become unwieldy
– Risk not on the list will be missed
– Misses opportunity
|– Regular maintenance is required.
– Use of structure can assit (RBS)
|Delphi Technique||– Captures inputs from technical experts
– Remove sources of bias
|– Limited to technical risks
– Dependent on actual expertise of experts
– May take longer time than available due to iterations of the expert’s inputs
|– Effective facilitation
– Careful of selection of experts
– Clear definition of scope
|Document review||– Exposes detailed project-specific risk
– Requires no specialist tools
|– Limited to risks contained in the document||– Understanding of relevance of prior exp.|
|FMEA / Fault Tree Analysis||– Structured approach, well understood by engineers
– Overall reliability by using quantitative tools
– Good tool support
|– Focuses on threats, not so useful for opportunities
– Requires expert tools
|– Detailed description of the area being assessed.
– Statistical accurate data
|Force Field analysis||– Create deep understanding of factors that affect project objectives||– Time consuming and complex technique
– Only applying to single objective, not provide whole project view
|– Prioritized objectives|
|Industry knowledge base||– Captures previous exp
– Allow benchmarking against external org
|– Limited to what has previously happened
– Excludes project-specific risk
|– Access to relevant info|
|Questionnaire||– Broad thinking to identify||– Dependent on quality of questions
– Limited topics covered by questions
– Can be a simple reformatting of checklist
|– Clear and unambiguous questions
– Detailed briefing of respondents
|Root-Cause analysis||– Basic for development of pre-emptive and comprehensive responses
– Can serve to reduce complexity
– No valid strategy for addressing the root cause.
|– Willingness by management
– Ability to identify if a risk is an outcome of a more fundamental cause.
|SWOT Analysis||– Focus on both Opportunity and threat
– Structured approach
– Focus on internal and external
|– Tends to produce high level generic risks, not project-specific.||– Good facilitation
– Avoid confusing 4 SWOT perspectives
|System dynamics||– Exposes unexpected inter-relation between project elements (feedback and feed-forward loops)
– Produces overall impacts of all included events and risks.
|– Requires software and expertise to build model
– Focus on impact, but difficult to include the concept of probability.
|– Understanding of feedback
– Competency in applying tools and understanding their output
– Quality of system model
– Accuracy of input data collected for the specific project.
|WBS Review||– Ensures all elements of project scope are considered.
– Provides for risks related to different level of detail
|– Excludes external risks (not included in WBS)||– Good WBS|