Identifying and Managing Project Risk
Encyclopedia
Identifying and Managing Project Risk by Tom Kendrick, is a book about identifying and managing risks on projects. The book is geared to be used by a junior Project Manager
and Kendrick aligns the chapters of the Book to the Project Management Institute
's (PMI) Guide to the Project Management Body of Knowledge
, (PMBOK) 2000 edition.
That being said, there is a newer edition (2009) of this book, with significant modifications that bring it up to date with the current PMBOK. Much of this article no longer applies.
This text is designed to be used as a supplemental source of information when studying for the Project Management Professional
(PMP) certification exam.
, and more prominently uncertainty
, is complete in a general fashion focusing a majority of his discussion on risk in projects due to poor planning and change management
processes.
He uses a collection of project elements from various projects his client's have conducted. He uses this data, Project Experience Risk Information Library (PERIL) database, to quantify and rank classes of risk. In the early part of his book he uses this significantly and the Appendix lists approximately 120 of the element's descriptions.
The book is structured to follow the PMBOK stages of a project — initiation, planning, controlling, executing and closure. Each chapter discusses a set of concepts and concludes with a bulleted "Key Ideas" section and an anecdote from the two attempts to construct the Panama Canal.
Although the book is written in a very generic manner, it has a decidedly high-tech flavor. This partly because the author worked at Hewlett-Packard
for twelve years.
He continues the introduction by justifying project planning and the challenges one might encounter in an organization that feels a project planning methodology is not needed. He describes ways one can address the need to set up a planning process and that the implementation should be scaled to the size of the projects being performed.
The PERIL database is described and qualified while some of the biases in it are enumerated. Within the three primary constraints on a project, the database shows the risk elements in the order of frequency of occurrence as 1) schedule
, 2) scope
and 3) resource
. Implicitly the reader can determine the database classifies each risk with a description, Project type (IT, Product development, etc.), schedule impact, cost impact, class (scope, resource, schedule) and subcategory.
Using the PERIL database Kendrick cites that even though the number of risks classified as scope related are one-third of the entries, they account for approximately half of the cumulative schedule delay. He enumerates the ranked sources as:
Kendrick describes a variety of methods for arriving at and defining deliverables and hence defining the scope. He suggests using the "is/is not" method of bounding the scope.
Three high-level risk assessment tools are discussed — Risk Framework, Risk Complexity Index and Risk Assessment grid. Risk Framework looks at the project's technology, the market and the manufacturing effects and uses the relative change to each of these to determine the risk level of the project. Risk Complexity Index looks at the technical aspects of the project (technology, architecture and system) and generates a number from 0-99 to quantify risk. Risk Assessment creates a grid of technology, structure and size to estimate the risk.
The risk issues addressed by a work breakdown structure
(WBS) are then discussed. Often considered only a project planning task Kendrick points out the uncertainty and risk introduced into a project when the WBS is not fully defined and understood. A WBS at too high a level can leave scope ill defined not allowing for proper estimates or definition of work to be performed. Often WBS elements that are defined at too high a level indicate work that is not understood and indicates significant risk due to uncertainty on the project.
Schedule is the second level of risks effecting project duration in the PERIL database. The top five (the book lists ten) categories are:
Dependency on external parties is the largest sub-categorization of schedule risk in the database (editors note: as might be expected since it is always safe to blame the other party) followed by poor estimations.
To assist in reducing these risks, Kendrick explains that the process should start with the WBS and apply estimates for effort and resources. This is an iterative process. A number of things should be kept in mind:
He summarizes a number of estimating techniques:
He spends significant time through-out the book discussing the PERT method and clearing up misconceptions on the PERT process. He explains that the PERT method of estimation generates the expected duration of a task by adding the pessimistic, optimistic and four times the most likely durations and dividing them by six. The standard deviation is determined is the difference of the pessimistic and optimistic durations and dividing them by six. The standard deviation is a reflection of the uncertainty in the estimates.
After determining the durations and sequencing the critical path
can be determined. The Critical Path is the longest contiguous path of tasks with no lag. The easiest way to do this is by using one of the many computerized tools on the market. He cautions that an increase in critical and near-critical paths will bias significantly increase the probability that the project will not complete by the projected time. This is due to the statistical probabilities of multiple paths causing failure.
As with many sections of the book, he provides lists of general items to use when planning.
The final category of risks are the resource risks. The top five (ten are provided in the book) are:
When planning one must determine the skill set required and to identify and reserve the people with those skills. As with schedule sequencing he recommends a computerized tools to properly look at staff loading. The loading will need to be compared to other project's needs and resource availability. Conflicts need to be resolved and documented since this also indicates inherent risk in the project.
Outsourcing
, the primary cause of resource induced delay in the database, is mitigated best by thorough planning, proper RFP (Request for Proposal
) generation, a clear and succinct contract and monitoring the subcontractor for progress. Although incoming inspection is required, this is too late to mitigate risk.
Funding issues were small in the PERIL database but the sources of error are due to overlooked staffing, travel, training and equipment costs. Funds for all of the anticipated financial outlays must be defined and planned for early in the project planning cycle.
Throughout the sections that discuss scope, schedule and resource risk, Kendrick repeats that analyzing these items must be an iterative process since they are the primary constraints and changes in one will effect the others.
If scope is the least important, determine methods to achieve the most for the customer while using less resources, trim low priority scope, suggest alternative solutions to the problem being addressed, look for reusable components from other projects.
For resource constraints look at cross-training staff or training new people. Outsourcing is an option but introduces significant risk.
If schedule constraints are an issue, it is possible to use schedule float. Also carefully analyze the schedule for tasks that can overlap, If they exist, look at defining the tasks with more granularity. Lastly, if the funds are available, add more resources to try to compress the schedule. All of these introduce their own risk.
Continually analyze the project for other risks. Kendrick provides a general list of risk categories to assist in brainstorm
ing, analyzing historical data or previous projects.
The key to assessing risk is determining the probability and impact of the risk and knowing when these values cannot be determined. Trying to make quantitative decisions from qualitative data is not sensible. To this end, Kendrick describes some standard and accepted methods of presenting non-quantifiable risks for the project. A majority of his time in spent discussing two methods in of quantitative analysis — two dimensional bubble chart
s and PERT analysis. As in previous areas on the book he presents beta-distributions of for risks and he lays the groundwork for the understanding of why simulation products are important when analyzing risk in complex projects. He presumes a modicum of knowledge of statistics but no knowledge of beta-distributions is required.
Risks fall into three broad categories — controllable known, uncontrollable known and unknown. For the former two, one must understand the risks before they can determine how to manage them. This is done using root cause analysis
. As the name implies its goal is to look for the root cause on the problem and solve it at that point. Kendrick briefly discusses the use of fishbone diagrams as a tool to assist in this process. Even unknown elements should be handled in this manner, but obviously as they are incurred. do it.
The four ways of handling risk are:
Determining which option to chose is primarily financial, but schedule and manpower may be involved. As a tool, Kendrick provides a number of "checklist" opinions for looking at each of these options.
Contingency planning is briefly discussed for scope, resource and schedule.
Kendrick highlights the common project level risks as (citing Capers Jones
as the original source):
Kendrick provides a suggested survey where all responses are on a scale of one-to-three and using the a weighted average (1:3:9) of the responses to determine the risk of the project biasing the negative impact. Results in the 2.51 - 6.00 range are considered medium and anything above high risk.
He then returns to the PERT modeling data generated by task and explains the use, limitations and additional theory. He uses simulations to generating an approximation of the logical outcomes.
He describes two less rigorous approaches for the looking at project risk compared to other project. Project Scale compares the total effort months of the project to other projects, the higher the ratio the more risky. Project Appraisal uses a process similar to appraising a house to determine risk based on other completed projects.
The remainder of this section is devoted to measuring projects and determining whether a project is tracking to plan or deviating in a negative manner. He discusses a number of soft techniques (qualitative judgements) and hard techniques (financial base on actuals) to determine the "health" of the project.
This section is an assortment of activities that Project Managers may do to align the project team and the stakeholders for the upcoming project. These items include:
Execution of the project entails the Project Manager applying the plan, leading the team and monitoring the project status looking for trends that can indicate variations (good and bad) in the project execution. Results of the analysis need to be communicated and adjustments made through a change management and/or issue resolution process.
Communication is imperative. Kendrick describes a variety of tools to aid in communication and notes where challenges may be become more difficult (remote projects, multiple languages, large number of stakeholders with differing goals). He also provides the obligatory how-to-run-a-meeting discussion.
Project traceability is important and Kendrick outlines the needs and requirements of a Project Management Information System. This system should be a repository for all project documents and appropriately accessible to all people.
For longer projects Kendrick suggests a periodic project review and assessment. He provides a checklist of the items this should include and show to conduct the meeting.
Proper closure of a project has significant benefits for reducing risk on future projects. Whether the project is considered a success or a failure the results should be documented and reviewed. These data can then be used in future planning processes to improve planning and reduce risk.
A project retrospective should be conducted and actions taken on the suggestions to improve processes for the future. Lack of action will reduce participation in subsequent retrospectives.
Project manager
A project manager is a professional in the field of project management. Project managers can have the responsibility of the planning, execution, and closing of any project, typically relating to construction industry, architecture, computer networking, telecommunications or software...
and Kendrick aligns the chapters of the Book to the Project Management Institute
Project Management Institute
The Project Management Institute is a not-for-profit professional organization for the project management profession with the purpose of advancing project management.- Overview :...
's (PMI) Guide to the Project Management Body of Knowledge
Project Management Body of Knowledge
A Guide to the Project Management Body of Knowledge is a book which presents a set of standard terminology and guidelines for project management. The Fourth Edition was recognized by the American National Standards Institute as an American National Standard...
, (PMBOK) 2000 edition.
That being said, there is a newer edition (2009) of this book, with significant modifications that bring it up to date with the current PMBOK. Much of this article no longer applies.
This text is designed to be used as a supplemental source of information when studying for the Project Management Professional
Project Management Professional
Project Management Professional is a credential offered by the Project Management Institute . , there were 393,413 active PMP certified individuals worldwide...
(PMP) certification exam.
Overview
Kendrick's coverage of riskRisk
Risk is the potential that a chosen action or activity will lead to a loss . The notion implies that a choice having an influence on the outcome exists . Potential losses themselves may also be called "risks"...
, and more prominently uncertainty
Uncertainty
Uncertainty is a term used in subtly different ways in a number of fields, including physics, philosophy, statistics, economics, finance, insurance, psychology, sociology, engineering, and information science...
, is complete in a general fashion focusing a majority of his discussion on risk in projects due to poor planning and change management
Change management
Change management is a structured approach to shifting/transitioning individuals, teams, and organizations from a current state to a desired future state. It is an organizational process aimed at helping employees to accept and embrace changes in their current business environment....
processes.
He uses a collection of project elements from various projects his client's have conducted. He uses this data, Project Experience Risk Information Library (PERIL) database, to quantify and rank classes of risk. In the early part of his book he uses this significantly and the Appendix lists approximately 120 of the element's descriptions.
The book is structured to follow the PMBOK stages of a project — initiation, planning, controlling, executing and closure. Each chapter discusses a set of concepts and concludes with a bulleted "Key Ideas" section and an anecdote from the two attempts to construct the Panama Canal.
Although the book is written in a very generic manner, it has a decidedly high-tech flavor. This partly because the author worked at Hewlett-Packard
Hewlett-Packard
Hewlett-Packard Company or HP is an American multinational information technology corporation headquartered in Palo Alto, California, USA that provides products, technologies, softwares, solutions and services to consumers, small- and medium-sized businesses and large enterprises, including...
for twelve years.
Analysis
The introductory two chapters lay the groundwork for people that are new to project or risk management. He starts with the definition of risk as the "loss multiplied by the likelihood" and expands from there. He explains that this relates to uncertainty in estimates for duration and cost. He identifies the benefits as:- Lowering cost and confusion
- Prioritization and stakeholder support
- Input for portfolio management
- Mitigation
- Setting expectations and establishing reserves
- Communication and control
Project Risk Planning
| Risk should be a primary driver for project selection |
| Project planning and definition are the foundation to controlling risk |
| Risk management should be maintained in a Project Risk Plan |
He continues the introduction by justifying project planning and the challenges one might encounter in an organization that feels a project planning methodology is not needed. He describes ways one can address the need to set up a planning process and that the implementation should be scaled to the size of the projects being performed.
The PERIL database is described and qualified while some of the biases in it are enumerated. Within the three primary constraints on a project, the database shows the risk elements in the order of frequency of occurrence as 1) schedule
Schedule (project management)
In project management, a schedule consists of a list of a project's terminal elements with intended start and finish dates. Terminal elements are the lowest element in a schedule, which is not further subdivided...
, 2) scope
Scope (project management)
In project management, the term scope has two distinct uses: Project Scope and Product Scope.Project Scope"The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions."Product Scope...
and 3) resource
Resource (project management)
In project management terminology, resources are required to carry out the project tasks. They can be people, equipment, facilities, funding, or anything else capable of definition required for the completion of a project activity. The lack of a resource will therefore be a constraint on the...
. Implicitly the reader can determine the database classifies each risk with a description, Project type (IT, Product development, etc.), schedule impact, cost impact, class (scope, resource, schedule) and subcategory.
Scope Risk
| Clearly define deliverables |
| Ensure the value of the deliverables exceeds the scope of work |
| Define a work breakdown structure small enough to ensure work is understood |
| Assign ownership and determine reasons any items are not accepted |
| Note all risks, including non-quantifiable risks due to size or complexity of project |
Using the PERIL database Kendrick cites that even though the number of risks classified as scope related are one-third of the entries, they account for approximately half of the cumulative schedule delay. He enumerates the ranked sources as:
- Scope creep
- Hardware defect
- Software defect
- Scope gap (ill defined scope)
- Dependency change (unexpected legal, regulatory, etc.)
- Integration defect (change due to unexpected behavior)
Kendrick describes a variety of methods for arriving at and defining deliverables and hence defining the scope. He suggests using the "is/is not" method of bounding the scope.
Three high-level risk assessment tools are discussed — Risk Framework, Risk Complexity Index and Risk Assessment grid. Risk Framework looks at the project's technology, the market and the manufacturing effects and uses the relative change to each of these to determine the risk level of the project. Risk Complexity Index looks at the technical aspects of the project (technology, architecture and system) and generates a number from 0-99 to quantify risk. Risk Assessment creates a grid of technology, structure and size to estimate the risk.
The risk issues addressed by a work breakdown structure
Work breakdown structure
A work breakdown structure , in project management and systems engineering, is a deliverable oriented decomposition of a project into smaller components. It defines and groups a project's discrete work elements in a way that helps organize and define the total work scope of the project.A work...
(WBS) are then discussed. Often considered only a project planning task Kendrick points out the uncertainty and risk introduced into a project when the WBS is not fully defined and understood. A WBS at too high a level can leave scope ill defined not allowing for proper estimates or definition of work to be performed. Often WBS elements that are defined at too high a level indicate work that is not understood and indicates significant risk due to uncertainty on the project.
Schedule risk
| Estimates with wide variations should be investigated for thorough understanding |
| Identify source of estimates, especially if not empirical |
| Identify high risk dependencies |
| Compare estimates to historical values looking for large variations |
| Pull risk forward to allow time to react |
| Identify all potential critical paths |
| Note project duration risk |
Schedule is the second level of risks effecting project duration in the PERIL database. The top five (the book lists ten) categories are:
- Project Dependencies
- Parts Delays
- Estimation errors
- Decision Delay
- Hardware Delay
Dependency on external parties is the largest sub-categorization of schedule risk in the database (editors note: as might be expected since it is always safe to blame the other party) followed by poor estimations.
To assist in reducing these risks, Kendrick explains that the process should start with the WBS and apply estimates for effort and resources. This is an iterative process. A number of things should be kept in mind:
- Historical data should be used where applicable.
- Resources planning (done next) will affect these estimates so these processes will need to be iterative.
- Be cognizant of people hesitating to give estimates, it may imply additional uncertainty.
- If the durations are greater than two weeks they should be broken down further.
- Make sure to incorporate holidays, vacations and other non-project time.
He summarizes a number of estimating techniques:
- Project-level Think-Do-Check based on project size.
- Historical data
- Prior experience
- Delphi GroupDelphi methodThe Delphi method is a structured communication technique, originally developed as a systematic, interactive forecasting method which relies on a panel of experts.In the standard version, the experts answer questionnaires in two or more rounds...
Estimating (a form of Consensus estimates) - Program Evaluation and Review TechniqueProgram Evaluation and Review TechniqueThe Program ' Evaluation and Review Technique, commonly abbreviated PERT, is a statistical tool, used in project management, that is designed to analyze and represent the tasks involved in completing a given project...
(PERT)
He spends significant time through-out the book discussing the PERT method and clearing up misconceptions on the PERT process. He explains that the PERT method of estimation generates the expected duration of a task by adding the pessimistic, optimistic and four times the most likely durations and dividing them by six. The standard deviation is determined is the difference of the pessimistic and optimistic durations and dividing them by six. The standard deviation is a reflection of the uncertainty in the estimates.
After determining the durations and sequencing the critical path
Critical path method
The critical path method is an algorithm for scheduling a set of project activities. It is an important tool for effective project management.-History:...
can be determined. The Critical Path is the longest contiguous path of tasks with no lag. The easiest way to do this is by using one of the many computerized tools on the market. He cautions that an increase in critical and near-critical paths will bias significantly increase the probability that the project will not complete by the projected time. This is due to the statistical probabilities of multiple paths causing failure.
As with many sections of the book, he provides lists of general items to use when planning.
Resource Risk
| All skills required to finish the project must have a named resource |
| Do not over commit staff |
| Identify tasks with unreliable resource estimates |
| Identify all understaffed tasks |
| Document all outsourcing risks |
| Build in funding for training, equipment and travel |
| Determine the complete project cost |
The final category of risks are the resource risks. The top five (ten are provided in the book) are:
- Outsourcing delays
- Lack of funds
- Attrition of resources
- People joining the team late
- Scarcity of skills
When planning one must determine the skill set required and to identify and reserve the people with those skills. As with schedule sequencing he recommends a computerized tools to properly look at staff loading. The loading will need to be compared to other project's needs and resource availability. Conflicts need to be resolved and documented since this also indicates inherent risk in the project.
Outsourcing
Outsourcing
Outsourcing is the process of contracting a business function to someone else.-Overview:The term outsourcing is used inconsistently but usually involves the contracting out of a business function - commonly one previously performed in-house - to an external provider...
, the primary cause of resource induced delay in the database, is mitigated best by thorough planning, proper RFP (Request for Proposal
Request for Proposal
A request for proposal is issued at an early stage in a procurement process, where an invitation is presented for suppliers, often through a bidding process, to submit a proposal on a specific commodity or service. The RFP process brings structure to the procurement decision and is meant to...
) generation, a clear and succinct contract and monitoring the subcontractor for progress. Although incoming inspection is required, this is too late to mitigate risk.
Funding issues were small in the PERIL database but the sources of error are due to overlooked staffing, travel, training and equipment costs. Funds for all of the anticipated financial outlays must be defined and planned for early in the project planning cycle.
Throughout the sections that discuss scope, schedule and resource risk, Kendrick repeats that analyzing these items must be an iterative process since they are the primary constraints and changes in one will effect the others.
| Align project plan and objective |
| Document project priorities |
| Identify project alternatives (mitigation) |
| Explore Project Opportunities |
| Remove unnecessary project scope |
| Document risk and impact of proposed changes |
| Use all means to identify unknown project risk |
Constraint Management
When controlling project constraint it must be understood that only two of the three constraints can be defined, the third will be determined by the other two. It should be determined which of the three (resource, scope or schedule) is the controlling constraint and which is the most acceptable to change. Determining this and insuring the stakeholders understand the consequence of this is of utmost importance.If scope is the least important, determine methods to achieve the most for the customer while using less resources, trim low priority scope, suggest alternative solutions to the problem being addressed, look for reusable components from other projects.
For resource constraints look at cross-training staff or training new people. Outsourcing is an option but introduces significant risk.
If schedule constraints are an issue, it is possible to use schedule float. Also carefully analyze the schedule for tasks that can overlap, If they exist, look at defining the tasks with more granularity. Lastly, if the funds are available, add more resources to try to compress the schedule. All of these introduce their own risk.
Continually analyze the project for other risks. Kendrick provides a general list of risk categories to assist in brainstorm
Brainstorm
Brainstorm generally refers to brainstorming, a group or individual creativity exercise.Brainstorm may also refer to:-Film:* Brainstorm , directed by Douglas Trumbull* Brainstorm , directed by William Conrad...
ing, analyzing historical data or previous projects.
Quantifying and Analyzing Activity Risk
| Determine probability and impact for each risk |
| Use qualitative methods to prioritize risk |
| Apply quantitative analysis to specific risks |
| Do not over complicate PERT analysis |
The key to assessing risk is determining the probability and impact of the risk and knowing when these values cannot be determined. Trying to make quantitative decisions from qualitative data is not sensible. To this end, Kendrick describes some standard and accepted methods of presenting non-quantifiable risks for the project. A majority of his time in spent discussing two methods in of quantitative analysis — two dimensional bubble chart
Bubble chart
A bubble chart is a type of chart where each plotted entity is defined in terms of three distinct numeric parameters. Bubble charts can facilitate the understanding of the social, economical, medical, and other scientific relationships.- Overview :...
s and PERT analysis. As in previous areas on the book he presents beta-distributions of for risks and he lays the groundwork for the understanding of why simulation products are important when analyzing risk in complex projects. He presumes a modicum of knowledge of statistics but no knowledge of beta-distributions is required.
Managing Activity Risk
| Do root cause analysis |
| Use one of the three methods of handling risk — mitigate, avoid, transfer |
| Develop contingency plans for all risk |
| Publicly display risks |
| Look for ways to prevent risk |
Risks fall into three broad categories — controllable known, uncontrollable known and unknown. For the former two, one must understand the risks before they can determine how to manage them. This is done using root cause analysis
Root cause analysis
Root cause analysis is a class of problem solving methods aimed at identifying the root causes of problems or events.Root Cause Analysis is any structured approach to identifying the factors that resulted in the nature, the magnitude, the location, and the timing of the harmful outcomes of one...
. As the name implies its goal is to look for the root cause on the problem and solve it at that point. Kendrick briefly discusses the use of fishbone diagrams as a tool to assist in this process. Even unknown elements should be handled in this manner, but obviously as they are incurred. do it.
The four ways of handling risk are:
- Avoidance - Take action to avoid the risk
- Mitigation - Define actions to take when the risk occurs
- Transfer - Have someone else handle the risk i.e. insurance
- Acceptance - Identify the risk as acceptable and let it happen.
Determining which option to chose is primarily financial, but schedule and manpower may be involved. As a tool, Kendrick provides a number of "checklist" opinions for looking at each of these options.
Contingency planning is briefly discussed for scope, resource and schedule.
Quantifying and Analyzing Project Risk
| Generate a formal survey project risk |
| Determine project uncertainty based on prior estimates |
| Use effort months to determine project size. |
Kendrick highlights the common project level risks as (citing Capers Jones
Capers Jones
Capers Jones is a specialist in software engineering methodologies, and is often associated with the function point model of cost estimation. He also collects data on software quality, software risks, and software best practices. His many computer science publications have been widely used by many...
as the original source):
- Estimates that are excessively inaccurate
- Too aggressive a schedule
- Poor management
- Scope creep (poor change management)
- Large projects not staffed appropriately
Kendrick provides a suggested survey where all responses are on a scale of one-to-three and using the a weighted average (1:3:9) of the responses to determine the risk of the project biasing the negative impact. Results in the 2.51 - 6.00 range are considered medium and anything above high risk.
He then returns to the PERT modeling data generated by task and explains the use, limitations and additional theory. He uses simulations to generating an approximation of the logical outcomes.
He describes two less rigorous approaches for the looking at project risk compared to other project. Project Scale compares the total effort months of the project to other projects, the higher the ratio the more risky. Project Appraisal uses a process similar to appraising a house to determine risk based on other completed projects.
The remainder of this section is devoted to measuring projects and determining whether a project is tracking to plan or deviating in a negative manner. He discusses a number of soft techniques (qualitative judgements) and hard techniques (financial base on actuals) to determine the "health" of the project.
Managing Project Risk
| Start the project with a kick-off workshop |
| Determine the appropriate metrics |
| Set the project reserve |
| Validate and adjust the objectives |
| Implement and use a Change Management Process |
This section is an assortment of activities that Project Managers may do to align the project team and the stakeholders for the upcoming project. These items include:
- A recommended list of documentation that summarize general best practices for a project, cautioning that quality, not quantity, is the measure.
- A project start-up workshop; including its preparation and execution. The goal is to align people to the goals and educate them on the challenges.
- Determining the appropriate metrics for the project, ensuring they are not burdensome and effect behavior in a positive manner. Too often, metrics change behavior to provide better metrics not better performance.
- Setting the amounts and conditions for use of the project reserves.
- Negotiating the final objectives of the project with stakeholders to improve the chances of project success.
- Validate that all team members and stakeholders accept the plan of record.
- Describe to all team members and stakeholders the change management process and how it will be enforced.
Monitoring and Controlling Risky Projects
| Be religious on collecting status information ensure that it is only the status you need |
| Monitor status and trends continuously |
| Promptly address problems |
| Communicate, communicate, communicate |
Execution of the project entails the Project Manager applying the plan, leading the team and monitoring the project status looking for trends that can indicate variations (good and bad) in the project execution. Results of the analysis need to be communicated and adjustments made through a change management and/or issue resolution process.
Communication is imperative. Kendrick describes a variety of tools to aid in communication and notes where challenges may be become more difficult (remote projects, multiple languages, large number of stakeholders with differing goals). He also provides the obligatory how-to-run-a-meeting discussion.
Project traceability is important and Kendrick outlines the needs and requirements of a Project Management Information System. This system should be a repository for all project documents and appropriately accessible to all people.
For longer projects Kendrick suggests a periodic project review and assessment. He provides a checklist of the items this should include and show to conduct the meeting.
Closing Projects
| Document the project results |
| Recognize contributors |
| Conduct a retrospective |
Proper closure of a project has significant benefits for reducing risk on future projects. Whether the project is considered a success or a failure the results should be documented and reviewed. These data can then be used in future planning processes to improve planning and reduce risk.
A project retrospective should be conducted and actions taken on the suggestions to improve processes for the future. Lack of action will reduce participation in subsequent retrospectives.
Further reading
- Lam, J., Enterprise Risk Management: From Incentives to Controls (2003). Wiley; 1 edition, ISBN 0-471430005
- Virine, L. and Trumper M., Project Decisions: The Art and Science (2007). Management Concepts. Vienna, VA, ISBN 978-1-56726-217-0
- Wideman, R.M. Project and Program Risk Management (1992). Newtown Square, PA: Project Management Institute. ISBN 978-1-880410066