Enterprise Risk Management vs. Project Risk Management

If you are a history buff like myself, you have probably come across the following statement, “Tactics win battles, but strategies win wars” or something to that effect. While I often find that martial analogies tend to be overused in discussions on project management, but I do think it is applicable when the topic is Enterprise Risk Management . Like an army, companies must adopt specific tactics to ensure the success of specific battles (projects), but at the same time support the underlying capabilities of the army (company) through high level planning and execution of strategies to ensure they win the war, or in the case of companies, remain profitable.

In the project management world, project managers are the officers who execute activities and tactics, monitor progress and make adjustments as needed to increase probability of winning the battle of delivering  a successful project.  In reality though, a significant portion of the risks and uncertainties that project managers face is beyond their immediate control and are symptoms of underlying weaknesses/strengths in their organizations capabilities. This type of risk has to be assessed and managed at a higher management level in the company. In this way we can see that risks can form a hierarchy  within an organization, each can have varying effects on different levels (projects, programs, etc) of the company. With this in mind, the manner in which the impact of these risks propagate through the various levels of the enterprise, should dictate the level at which they are managed.

Enter a formalized process of how to manage risks within an enterprise, which can be characterized as a portfolio of programs and projects. Enterprise risk management allows organizations to optimize how and where they manage risks. Some risks, which are specific to a location such a local regulations are best managed at the project level as they may have unique  characteristics that cannot be effectively managed at a higher level.  Manage other risks, such as resources, capital budgets, or changes in market conditions have systemic effects upon the entire organization and therefore need to at higher level in organization.

What this means is a practical sense is you need the capability to manage multiple sets of risks (risk registers) that represent each level in your organization. For example, an enterprise risk register, could include all of those risks that are being managed by the head office, program risk registers would be used to manage program capabilities, and project risk registers would be include risks that can be controlled  at the project level.  In addition, the system should support the ability to modify where risks are being managed based upon their cumulative impact on the organization. A common example we see is resources. Often resource availability is a challenge for project managers whose resources shared across multiple projects. While resource availability may manifest itself in delays at the project level, an enterprise risk management system allows you to monitor the cumulative impact of these risks at a program level and apply appropriate actions to mitigate or alleviate the impacts. If a risk is critical enough, management of the risk can be transferred up to the  program level. This does not mean that a program risk will not have impacts on the underlying projects, but rather responsibility for reducing or resolving it will now be the responsibility of the program manager. In the example above, project managers would still have to account for the possible impacts of scarcity of resources, but would no longer be responsible for management of the risk.

The point of all of this is that Enterprise Risk Management allows you to address those underlying strategic or systemic issues that affect an organizations capability to deliver value, while delegating situation specific  actions or tactics to the level  at which they can be most effective.

Project Risk Management Software Features

Here is a little experiment that you can try, type “Project Risk Management Software” into Google or other search engine. Not only will you get thousands of hits, but if you examine those that actually link to sites that are selling or marketing software, you will find that they offer a wide range of capabilities. Some are very simple, some quite complex, some look like they are purpose built, that is they are specifically designed for project risk management; whereas, others appear have been included tangentially and offer little clue as to why they were included in the list. With so many solutions available, it can be difficult for someone unfamiliar with this particular topic to separate true contenders from the pretenders. With that in mind, I will now present an overview of what capabilities project risk management software should have. Further, I will separate these out into Mandatory and Nice to Have categories.

Must Have Project Risk Management Software Features

Perhaps the single most important capability provides users a method to identify risks. This identification includes properties or additional data that each risk should include. This data includes: a unique ID, name, date identified, name of identifier, description or risk statement, threat or opportunity, and status (open or closed).

The next set of capabilities required is for risk assessment. Risk assessment requires the capability to add probability and impacts for each risk and impacts must be broken down into categories such as cost, schedule, or performance. The risk assessment should be flexible to support different risk scoring methodologies and algorithms.

You must be able to assign a plan to each risk. Plans can include a strategy that typically is broken out into four categories: transfer, avoid, mitigate, and accept. Risk plans should have steps or activities that will be used to control the risk that include planned date for completion, expected result or changes to the risk score, owner and status.

Each risk should include a record of changes that have a time stamp as well as who made the changes. This can be incorporated with the ability to add notes, comments, reviews, or additional information that can be added to each risk over the course of a project.

Finally, there should be a variety of customizable reports for either individual or multiple risks. Typically, this can include a risk register, risk matrix, and individual risk reports.

Nice to Have Project Risk Management Features

Integration with other project management software is extremely useful. For example, of the risk registers are saved in Excel. The ability to import Excel spreadsheets into your risk register is extremely helpful saving both time and money. If you are performing quantitative project risk analysis, integration with project scheduling and cost estimation tools is invaluable.

For quantitative risk analysis, Monte Carlo simulations are recommended. The Monte Carlo analysis should include the ability to model both risk events (risks) and uncertainties (3 pt. estimates) for cost and resource loaded schedules. The analysis should include a full slate of statistical reports including probability histograms, cumulative probability, and sensitivity analysis. Make sure that the Monte Carlo is designed to run project risk analysis; you should be able to run large schedules (e.g. 1000 activities) in under a minute. Comprehensive quantitative risk analysis should also include additional capabilities such as conditional and probabilistic branching and scenario analysis.

There are probably additional capabilities that we could add to the list, but this is a good starting point for evaluating the quality and capabilities of solutions when you are looking for project risk management software.

Project Risk Analysis Templates

Project risk analysis templates outline the recommended information that should be captured as part of project risk analysis. In many cases project risk register templates are easy to use and at the same time are very useful tools for project risk management and project risk analysis. Project risk analysis templates include:
Risk Breakdown Structure Templates.
Risk breakdown structures are a hierarchical list of risks. Risk breakdown structures help to identify and manage project risks. In RiskyProject you can define different risk breakdown structures at the project level and for each separate task or resource. Each risk is defined by its chance of occurrence, outcome (increase duration, cost, cancel task, etc.) and time of occurrence. In RiskyProject Risk Register you can customize your risk breakdown structure based risk categories, risks, issues, lesson learned, opened and close risks, visible and hidden risks, risk owners, risk managers, and other risk properties. Risk breakdown structure is also implemented for risk assignments with Global Risks view as well as Local Risks tab for each task or resources of RiskyProject Lite and RiskyProject Professional.
Here is standard risk breakdown structures available in RiskyProject:

• Generic Risk Breakdown Structure. 
• Software Development Risk Breakdown Structure. 

Risk Properties Template
It is a list of risk properties which can be captured for each risk in the risk register. These default risk properties are implemented in RiskyProject software, however we can always customize the list of risk properties for the needs of your organization. The risk properties templates also include definition of probabilities impacts and scores for different categories, such as Schedule, Cost, Safety, Performance, etc.

Risk Events vs. Uncertainties in Project Risk Analysis

As part of the risk management plan, you usually identify risks events affecting duration, cost and other parameters, include them to the risk register, assign them to task and resources and perform Monte Carlo simulation of project schedules. To the casual observer, it seems quite straight forward that if you  have a well-defined risk plan and do a high quality risk analysis you have managed all of your risk. But the problem with this process is that it only includes risk events and these only represent a slice of project risk often called “epistemic”. Epistemic risk is characterized by probability and impact and further is manageable, that is, the impact of these risks on your project can be reduced or eliminated through good management. In general epistemic risks are related to our knowledge: we may not know what will happen during a course of project and therefore assign certain probability to some potential events.

However, there is another source of uncertainties that cannot be managed or reduced referred to as “aleatory”. This is important because this missing piece can represent a significant portion of your total project risk. Aleatory uncertainties refer to the inherent variance that occurs in all processes. This variance can be caused by a multitude of factors, but unlike discrete risks they have 100% probability of occurring and cannot be managed to the same extent as epistemic risks. In other words aleatory uncertainties usually are not attributed to certain individual factors. But, how to model them? This type of risk is often referred to as uncertainties and are described by low (optimistic), most likely, and High (pessimistic) estimates that are assigned statistical distributions such as triangular or normal which describe their probability density function.

As with qualitative analysis on risk events, Monte Carlo simulations are used to analyze the impact of these uncertainties and the same visualizations and reports are used. The difference is that there is no risk prioritization and subsequent risk response or mitigation plans. The only way to “manage” these uncertainties is to add risk adjusted schedule margin and cost contingency, which provide reasonable protection to key project objectives to ensure that it is delivered on time and budget.

So what we now see is projects can be impacted by both manageable and unmanageable risks. Yet, often Risk Management Plans include risk analysis processes that are focused on assessing and prioritizing risks, while completely ignoring another major source of uncertainties in their projects. So, even if you have an extremely well defined risk management plan, if it does not include how to incorporate aleatory uncertainties into both your risk analysis and management, you may find that your projects are still not meeting your key objectives.

Risk Management Plan

A well-defined Risk Management Plan is the cornerstone of any risk management process and is key to overall quality of your project management. Risk management plans and risk analysis are two components of project risk management process. The Risk Management Plan is the core document that describes how risk management will be performed on a project.  Risk analysis or the assessment of the risks is a defined methodology that is used to analyze risks that impact a project.

According to the PMI’s PMBOK® the risk management plan “describes how risk management will be structured and performed on a project” and is a supplement and deliverable that  is included with the project management plan.  Risk management plans contain the methodologies, resources, schedule, budget, categories, risk probability and impact definitions and matrixes, risk tolerances, reports, and records. Methodologies should include data sources, software or other tools, and approaches such as Delphi, expert interviewing, Monte Carlo etc. Resources should detail who will be involved in the process and at what stages their involvement is required. Budgets should include costs for risk management activities including associated resource costs that can be included as part of the project cost. Schedules define when risk management activities will take place during the life of the project. Categories define the types of risk impacts that will be analyzed and managed. Typically these include cost, schedule, quality, performance and others.  Risk probability and impact definitions provide guidance on how risk impacts can be qualitatively assessed.  Risk matrixes provide a framework for how permutations of probability and impact types will be ranked and prioritized for planning. Risk tolerances are a measure of stakeholder’s willingness or ability to consume risk. Reports details the specific formats in which the results of the risk management will be presented. Typically, the central format is the Risk Register, but other formats could include risk matrixes, mitigation waterfall charts, histograms, and tornado plots. Records should outline how information will be stored to be used for the current and future projects and how the records will be checked for quality and completeness.

 

Risk analysis is process that can be broken down into 2 sub-processes: qualitative and quantitative. Risk analysis takes place after risk identification and is used to assess and prioritize risks based on their expected or probable impact on project objectives. Of the two, qualitative risk is the most widely used because of relative ease of use and  low cost.  Qualitative risk assessment  supports a quick assessment  of risks and allows for the prioritization of risk response plans based on the result of the analysis. The focal point of qualitative risk analysis is typically the risk register wherein probabilities and impacts are defined by levels or ranges (1 in 10 or Very Low, Low, High, etc). These values are then transcribed onto a risk matrix which allows project teams to categorize in terms such as critical, moderate, or negligible. These assessments are then updated in the Risk Register and are used to prioritize project risks.

Quantitative risk analysis requires more time and effort to perform than qualitative risk analysis and therefore is often only performed on those subset of risks that have been identified as having potential to substantially impact key project objectives such as cost and schedule. The outputs of quantitative risk analysis include probabilistic results for cost, finish times, durations, etc. for the project, activities, or phases, quantified impacts risks, confidence levels for meeting particular outcomes, and realistic “risk adjusted” goals for  cost and schedule and other objectives. Quantitative risk analysis is normally performed using Monte Carlo simulations and the results are shown using histograms, cumulative probability plots, and tornado diagrams. The results can also be visualized using cost, cash flow, result Gantts, success rates, and cruciality reports.

If risk management plan clearly defines methodology of risk analysis, risk definitions, which can be used in risk analysis, as well as other information, such as schedules and budget, such plan will improve chance that project risks will be addressed.

Value of Project Risk Analysis

Many project managers are wounding if there is any value in project risk analysis. Project risk analysis takes effort, requires experienced personnel with specialize knowledge and requires risk analysis software. But does it provide benefits, namely reduction of project duration, cost reduction, efficient resource allocation and others?

We have worked with many clients in different industries. The research shows that the average delay of large IT projects is 30%; however many projects can be delayed significantly longer. Average delay of large unique construction and infrastructural projects is similar. This is a result of risks and uncertainties which were not taken into account when the original project schedule was created. However these risks can be mitigated and if risks are occurring, a response plan can be executed. Mitigation and response planning will not completely eliminate project delays or cost overruns. Plus the execution of such plans cost money and take some time. But based on our experience, execution of mitigation and response plans can reduce overall project delays and cost overruns by 50% on average.

The value of project risk analysis is not only in determining a realistic project schedule with risks and uncertainties, although it is very important. The most value in project risk analysis is risk mitigation planning, which includes:

• risk prioritization or determining what risks can be mitigated first
• analysis of efficiency of mitigation plans and calculating their cost and duration
• analysis of risks as part of project control and just-in-time execution of project risks

RiskyProject software has all the necessary functionalities to perform quantitative analysis, risk analysis with mitigation and response planning. RiskyProject has a depository of risk report and risk mitigation plans which can be assigned to different risks. Mitigation plants in RiskyProject can be presented using waterfall diagrams.

RiskyProject also supports multiple baselines. Each baseline has a set of risks assigned to different activities as well as mitigation and response plans. By comparing risk baselines it is possible to calculate the efficiency of mitigation and response efforts.

 

EVM and Project Risk Analysis

A question that we are often asked is how does project risk analysis (PRA) compare or relate to earned value management (EVM)? It often goes further, if I am doing EVM, is there a need for risk analysis, or is it redundant? In this case, while there is a little overlap, risk analysis and earned value are complementary practices as part of an integrated project/program management process. This begs the question, how do the two complement each other. First, let’s define earned value and project risk analysis.
Project risk analysis is a process of identifying project risk events and uncertainties and assessing their expected impacts on key project objectives such as cost, schedule, and performance using Monte Carlo simulations. EVM was developed to allow project teams to measure how well they are executing their project by comparing planned work against actual work performed over predetermined intervals. Earned value takes into account measures of planned work such as Budgeted Cost of Work Scheduled  (BCWS)  vs Budgeted Cost of Work Performed (BCWP), which provide an indicator of how much work was actually performed vs what was planned. Depending on the particular system, there are a plethora of such metrics which can seem very complex, but they answer a simple, yet very important question: Has the project produced the value for the funds provided? This lies at the heart of how contracts are managed as the payment is based not upon how much work or effort has been done by the project, but by the value that has been created. If you know that you are only going to get paid based upon delivering value according to plan, then it is incumbent upon you to ensure that your plan is realistic. This is where project risk analysis supports the goals of the EVM process.
One of the key objectives of project risk analysis is to create “risk adjusted” realistic project plans. It does this by assessing the possible impacts of risks and uncertainties on project objectives, managing risks, and adding appropriate schedule margin and cost contingency,  such that it provides a high confidence that the project can be executed according to plan. So in this process, project risk analysis is performed as part of the development of the project plan. In addition, project risk analysis, can also augment the EVM process as part of the forecasting of delivery dates.
EVM is used not only to track actual performance, but can include indicators that use current performance to estimate time to complete or cost at completion. These indicators ETC (Estimate to Complete) or EAC (Estimate at Completion) provide values forecast the required budget to complete the project (ETC) not taking into account budget already spent or how much the entire project will cost (EAC) which accounts for how much has been spent and the ETC. One of the main issues with these indicators is that they are single point estimates, which are notoriously inaccurate when estimating under conditions of uncertainty (risks and uncertainties). Project risk analysis can augment the EVM performance tracking by providing forecasts that account for future risks and uncertainties. In this scenario, project plans be analyzed to predict possible outcomes given both the actual project performance and the risks and uncertainties that project has yet to encounter. This is extremely useful as this provides a risk adjusted forecast given current project status.

In the example above, we can see a plot that shows the project schedule plan vs. actuals with a forecast that shows how the actuals will affect the possible schedule outcomes.  In the EVM world, the analysis would provide duration to calculate an EAC for a schedule as shown by the central blue line. But in reality, there is range of possible outcomes that can be expressed using confidence levels or percentiles (P values).  In the example above we can see while the EAC is calculated based on a single date, there is range that can be achieved from the very aggressive (P10) to very conservative and more likely (P80). In this case, the P80 represents a finish date at that is much more feasible than the one provided by the deterministic calculation. In practical terms it means that risk analysis will help to determine statistical distributions of remaining project finish time and remaining cost. These distributions will be used to calculate EAC based on selected percentile. This process will be repeated on different project milestone with taking into an account actual project performance.
So we can see that when in concert, EVM and project risk analysis can effectively used to improve not only chance that projects will deliver the planned value on time and budget, but can also be used together to understand how current project performance may impact future project execution.

New Blog: Sensitivity Analysis in Project Management
http://intaver.com/sensitivity-analysis-for-project-management/

New Blog: Availability Bias in Project Management

New Blog: Availability Bias in Project Management
http://intaver.com/blog-project-management-project-risk-analysis/availability-bias-project-management/

"Watch our video on Event Chain Methodology".

"Watch our video on Event Chain Methodology".

https://www.youtube.com/watch?v=oU-ryWGnbi0&feature=youtu.be