Project Risk Management

Project Risk Management

Project Risk Management
 Project Risk Management

Project risk management  is an important aspect  of project management. According to the  PMI's PMBOK managements one of the ten knowledge areas in which a project manager must be competent. Project risk is defined by PMI as 'an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives'.  
Good Project Risk Management depends on supporting organizational factors, clear roles and responsibilities, and technical analysis skills.  Project Risk management is the identification, assessment, and prioritization of risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events or to maximize the realization of opportunities  
Download Also:
Risk management is the identification, assessment, and prioritization of risks  (defined in ISO 31000 as the effect of uncertainty on objectives) followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events  or to maximize the realization of opportunities.  Risks can come from uncertainty in financial markets, threats from project failures (at any phase in design, development, production, or sustainment life-cycles), legal liabilities, credit risk, accidents,  natural causes and disasters  as well as deliberate attack from an adversary, or events of uncertain or unpredictable root-cause . 
Several risk management standards have been developed including the PMI, the National Institute of standards  and Technology, actuarial societies, and ISO standards. Methods, definitions and goals vary widely according to whether the risk management method is in the context of project management, security, engineering, industrial processes  , financial portfolios, actuarial assessments, or public health and safety.  The strategies to manage threats (uncertainties with negative consequences) typically include transferring the threat to another party, avoiding the threat, reducing the negative effect or probability of the threat, or even accepting some or all of the potential or actual consequences of a particular threat, and the opposites for opportunities (uncertain future states with benefits).  
Certain aspects of many of the risk management standards have come under criticism for having no measurable improvement on risk, whether the confidence in estimates and decisions seem to increase . For example, it has been shown that one in six IT projects experience cost overruns of 200% on average, and schedule overruns of 70%.  In many projects, risks are identified and analysed in a random, brainstorming, fashion. This is often fatal to the success of the project, as unexpected risks arise, which have not been assessed or planned for and have to be dealt with on an emergency basis, rather than be prepared for and defended against in a planned, measured, manner. 
Very early in the preparation and planning stage, it is essential that potential risks are identified, categorized and evaluated. Rather than look at each risk independently and randomly, it is much more effective to identify risks and then group them into categories, or, to draw up a list of categories and then to identify potential risks within each category. 
This way, common influences, factors, causes, potential impacts and potential preventative and or corrective actions, can be discussed and agreed on.  Categorising risks is a way to systematically identify the risks and provide a foundation for awareness, understanding and action. Each project will have its own structure and differences, but here are some categories that are common to most projects (to which you can add your own local, sector, or project specific, categories). 
I have not given deep detail here, but your project team and sponsors should be able to relate to these categories and use them in the risk assessment process. For example, with "operational resources" your team can discuss issues such as, availability, delivery timing, cost, capability, necessary conditions for operation (e.g. ground, weather, light); with "stakeholder resources" your team can identify all stakeholders and list potential risks that these stakeholders may generate, such as bad publicity from the media, delays caused by community or environmental groups, delays caused by utility companies, problems with trade unions. 
Related risks and potential actions, must then be documented in the risk management plan and discussed at all the key stages as  the project progresses. All the details and the actual action taken and the outcomes, must then be recorded and reviewed during the closure and review stage, for lessons to be learned and applied to future projects.  Here the question that most project managers ask: "how do we know if we can manage the risk, if it arises?" Often, sadly, no evaluation is carried out to determine the expertise, experience, capabilities of the team, individuals, organisations that would be required to deal with, manage that risk, if it occurred. As a result, if it did, the team may not be able to deal with it effectively, even though the initial forecast was that the risk could be managed. 
This happens frequently when the planning team is not the project team that manages the project and/or when key individuals in the original project team leave the team during the project and are replaced by individuals with different skills, experience and capabilities. The clear message here is that setting a risk tolerance level is a dangerous business. Each potential risk needs to be carefully, rigorously, analysed and the project team, the supporting teams and individuals, the organisation(s) involved in managing the project, all need to be evaluated to determine whether there is the capability to manage that risk successfully, should it arise. Where gaps in capability are identified, then appropriate corrective action must be taken. During the project itself, this capability must be constantly monitored and, where necessary, action taken to return the level of capability to the required level.  
Conflict over resources often arise during the middle to later stages of a project, because, often unexpected other, newer demands arise which are seen as being of higher priority. This can lead to resources that were originally allocated to the project being taken away, or reduced in quantity or quality, almost certainly to the detriment of the project. The answer to this dilemma is not easy, but in essence, the project management team must include "conflict over resources during the life of the project" as a major potential risk and plan for it accordingly by securing agreements and then monitoring the situation continuously. If a dispute does arise, there is a role here for the project champion and or the client to ensure that the allocated resources are not taken away.  
Fundamental to many of the issues that we discuss here is the question of who should be responsible for risk assessment and management. Too often the responsibility for risk identification, assessment and management, are left to the project team, especially once the project has started. But there are other  individuals and groups, including some external stakeholders, who should be continuously monitoring particular activity and feeding back regularly to the project team leader. Some are easy to identify. 
They include of course, the client, the sponsor, key specialists in the project team's organisation, or organisations, the major external participants, such as emergency services, local authorities and contractors.  The easy way to identify other individuals and groups is to look at your list of stakeholders. Each one has a responsibility, to a greater or lesser degree, to help identify potential risk and give information on this to the project team. Again, the answer to managing the question of risk responsibility is to build discussion, planning and action, on this into the project planning and operational activity.
Project risk management in its entirety, includes the following five process groups:
  • Planning risk management
  • Risk identification
  • Performing qualitative risk analysis
  • Performing quantitative risk analysis
  • Planning risk responses
  • Monitoring and controlling risks 

Quantitative Risk Analysis Tools and Techniques   

Quantitative Risk Analysis is performed on risks that have been prioritized by the Qualitative Risk Analysis process.  The Quantitative Risk Analysis process analyzes the effect of those risk events and assigns a numerical rating to those risks. It also presents a quantitative approach to making decisions in the presence of uncertainty. Since it is more expensive, it is only done on those risks we already identified as potentially and substantially impacting the project’s competing demands. 

This process uses techniques such as Monte Carlo simulation and decision tree analysis to:
Quantify the possible outcomes for the project and their probabilities  Assess the probability of achieving specific project objectives  Identify risks requiring the most attention by quantifying their relative  contribution to overall project risk  Identify realistic and achievable cost, schedule, or scope targets, given the  project risks  Determine the best project management decision when some conditions or outcomes are uncertain.
Quantitative Risk Analysis generally follows the Qualitative Risk Analysis process, although experienced risk managers sometimes perform it directly after Risk Identification. In some cases, Quantitative Risk Analysis may not be required to develop effective risk responses. Availability of time and budget, and the need for qualitative or quantitative statements about risk and impacts, will determine which method(s) to use on any particular project. Quantitative Risk Analysis should be repeated after Risk Response Planning, as well as part of Risk Monitoring and Control, to determine if the overall project risk has been satisfactorily decreased. Trends can indicate the need for more or less risk management action.

Interviewing. Interviewing techniques are used to quantify the probability and impact of risks on project objectives. The information needed depends upon the type of probability distributions that will be used. For instance, information would be gathered on the optimistic (low), pessimistic (high), and most likely scenarios for some commonly used distributions, and the mean and standard deviation for others. Documenting the rationale of the risk ranges is an important component of the risk interview, because it can provide information on reliability and credibility of the analysis.

Probability distributions. Continuous probability distributions represent the uncertainty in values, such as durations of schedule activities and costs of project components. Discrete distributions can be used to represent uncertain events, such as the outcome of a test or a possible scenario in a decision tree.
Expert judgment. Subject matter experts internal or external to the organizations such as engineering or statistical experts, validate data and techniques.

Quantitative Risk Analysis and Modeling Techniques:

Sensitivity analysis. Sensitivity analysis helps to determine which risks have the most potential impact on the project. It examines the extent to which the uncertainty of each project element affects the objective being examined when all other uncertain elements are held at their baseline values. One typical display of sensitivity analysis is the tornado diagram, which is useful for comparing relative importance of variables that have a high degree of uncertainty to those that are more stable.

Expected monetary value analysis. Expected monetary value (EMV) analysis is a statistical concept that calculates the average outcome when the future includes scenarios that may or may not happen (i.e., analysis under uncertainty). The EMV of opportunities will generally be expressed as positive values, while those of risks will be negative. EMV is calculated by multiplying the value of each possible outcome by its probability of occurrence, and adding them together. A common use of this type of analysis is in decision tree analysis. Modeling and simulation are recommended for use in cost and schedule risk analysis, because they are more powerful and less subject to misuse than EMV analysis.
Decision tree analysis. Decision tree analysis is usually structured using a decision tree diagram that describes a situation under consideration, and the implications of each of the available choices and possible scenarios. It incorporates the cost of each available choice, the probabilities of each possible scenario, and the rewards of each alternative logical path. Solving the decision tree provides the EMV (or other measure of interest to the organization) for each alternative, when all the rewards and subsequent decisions are quantified.

Modeling and simulation:

A project simulation uses a model that translates the uncertainties specified at a detailed level of the project into their potential impact on project objectives. Simulations are typically performed using the Monte Carlo technique. In a simulation, the project model is computed many times (iterated), with the input values randomized from a probability distribution function (e.g., cost of project elements or duration of schedule activities) chosen for each iteration from the probability distributions of each variable. A probability distribution (e.g., total cost or completion date) is calculated. For a cost risk analysis, a simulation can use the traditional project WBS or a cost breakdown structure as its model. For a schedule risk analysis, the precedence diagramming method (PDM) schedule is used.

 Project Risk Qualitative Analysis

There are two cycles of analysis that can be done on risks after they have been identified before Risk Planning occurs. The first is Qualitative Risk Analysis which includes methods for prioritizing the identified risks for further action, such as Quantitative Risk Analysis or Risk Response Planning. Organizations can improve the project’s performance effectively by focusing on high-priority risks. Qualitative Risk Analysis assesses the priority of identified risks using their probability of occurring, the corresponding impact on project objectives if the risks do occur, as well as other factors such as the time frame and risk tolerance of the project constraints of cost, schedule, scope, and quality. 
Stakeholder risk tolerances must be taken into account in this phase. Everyone knows that if you change one side of the triple constraint triangle (cost, schedule and scope/quality), then one of the other factors change. For example, if you add to the scope, either cost (hiring more engineers) or schedule will change. As the Project Manager, it is vital that you know which one of these factors drive the  Stakeholders. It may be time to market (schedule), cost or functionality (scope/quality).  Definitions of the levels of probability and impact, and expert interviewing, can help to correct biases that are often present in the data used in this process. The time criticality of risk-related actions may magnify the importance of a risk. 
An evaluation of the quality of the available information on project risks also helps understand the assessment of the risk’s importance to the project.  Qualitative Risk Analysis is usually a rapid and cost-effective means of establishing priorities for Risk Response Planning, and lays the foundation for Quantitative Risk Analysis (a much more rigorous and expensive process)  if this is required. Qualitative Risk Analysis should be revisited during the project’s life cycle to stay current with changes in the project risks.

Qualitative Risk Analysis requires outputs of the Risk Management Planning and Risk Identification processes. This process can lead into Quantitative Risk Analysis or directly into Risk Response Planning.

Risk Probability and Impact Assessment

Risk probability assessment investigates the likelihood that each specific risk will occur. Risk impact assessment investigates the potential effect on a project objective such as time, cost, scope, or quality, including both negative effects for threats and positive effects for opportunities.  Probability and impact are assessed for each identified risk. Risks can be assessed in interviews or meetings with participants selected for their familiarity with the risk categories on the agenda. Project team members and, perhaps, knowledgeable persons from outside the project, are included. Expert judgment is required, since there may be little information on risks from the organization’s database of past projects. 
Using outside experts to help in the assessment is very helpful since they are experts and they are not as biased as the project team. I have found this technique to be very useful.   The level of probability for each risk and its impact on each objective is evaluated during the interview or meeting. Explanatory detail, including assumptions justifying the levels assigned, is also recorded. Risk probabilities and impacts are rated according to the definitions given in the risk management plan. Sometimes, risks with obviously low ratings of probability and impact will not be rated, but will be included on a watch-list for future monitoring.

Probability and Impact Matrix

Risks can be prioritized for further quantitative analysis and response, based on their risk rating. Ratings are assigned to risks based on their assessed probability and impact. Evaluation of each risk’s importance and, hence, priority for attention is typically conducted using a look-up table or a probability and impact matrix. Such a matrix specifies combinations of probability and impact that lead to rating the risks as low, moderate, or high priority.  Descriptive terms or numeric values can be used, depending on organizational preference. The organization should determine which combinations of probability and impact result in a classification of high risk, moderate risk and low risk.  
Usually, these risk rating rules are specified by the organization in advance of the project, and included in organizational process assets. Risk rating rules can be tailored in the Risk Management Planning process to the specific project.  An organization can rate a risk separately for each objective (e.g., cost, time, and scope). In addition, it can develop ways to determine one overall rating for each risk. Finally, opportunities and threats can be handled in the same matrix using definitions of the different levels of impact that are appropriate for each.  The risk score helps guide risk responses. 
For example, risks that have a negative impact on objectives if they occur (threats), and that are in the high-risk zone of the matrix, may require priority action and aggressive response strategies. Threats in the low-risk zone may not require proactive management action beyond being placed on a watch list or adding a contingency reserve.  Similarly for opportunities, those in the high-risk zone that can be obtained most easily and offer the greatest benefit should, therefore, be targeted first. Opportunities in the low-risk zone should be monitored. Earned Monetary Value (EMV) is a good technique to use here.

Risk Data Quality Assessment

A qualitative risk analysis requires accurate and unbiased data if it is to be credible. Analysis of the quality of risk data is a technique to evaluate the degree  to which the data about risks is useful for risk management. It involves examining the degree to which the risk is understood and the accuracy, quality, reliability, and integrity of the data about the risk.  The use of low-quality risk data may lead to a qualitative risk analysis of little use to the project. If data quality is unacceptable, it may be necessary to gather better data.

Risk Urgency Assessment

Risks requiring near-term responses may be considered more urgent to address. Indicators of priority can include time to affect a risk response, symptoms and warning signs, and the risk rating.  Identifying Risks in your projects  All projects have risks. It is the job of the Project Manager to identify these risks as part of the Risk Management Planning Process. Risk Identification determines which risks might affect the project and documents their characteristics. Participants in risk identification activities can include the following, where appropriate: project manager, project team members, risk management team (if assigned), subject matter experts from outside the project team, customers, end users, other project managers, stakeholders, and risk management experts.

While these personnel are often key participants for risk identification, all project personnel should be encouraged to identify risks. I worked on a project where we used several of these techniques. I will point those out to you in the following sections.  Risk identification is an integrative process. The frequency of iteration and who participates in each cycle will vary from case to case. The project team should be involved in the process so that they can develop and maintain a sense of ownership of, and responsibility for, the risks and associated risk response actions. 
Stakeholders outside the project team may provide additional objective information. Especially important is the risk tolerance of the Stakeholders. This is invaluable information in Risk Planning.   The Risk Identification process usually leads to the Qualitative Risk Analysis process. Alternatively, it can lead directly to the Quantitative Risk Analysis process when conducted by an experienced risk manager. On some occasions, simply the identification of a risk may suggest its response, and these should be recorded for further analysis and implementation in the Risk Response Planning process.

Documentation Reviews  

A structured review may be performed of project documentation, including plans, assumptions, prior project files, and other information. The quality of the plans, as well as consistency between those plans and with the project requirements and assumptions, can be indicators of risk in the project.

Information Gathering Techniques

I worked on a project where we spent three days planning the project. We engaged several experts in our technology to help us with the Information Gathering Techniques. This helped the project a lot since we (the project team) were not experts at the time of the project. They were very helpful in the brainstorming and Delphi techniques. During each following phase of the project, the Risk list should be looked at to see if any further risks have been identified.  10 Golden Rules of Project Risk Management   
The benefits of risk management in projects are huge. You can gain a lot of money if you deal with uncertain project events in a proactive manner. The result will be that you minimise the impact of project threats and seize the opportunities that occur. This allows you to deliver your project on time, on budget and with the quality results your project sponsor demands. Also your team members will be much happier if they do not enter a "fire fighting" mode needed to repair the failures that could have been prevented.  
This article gives you the 10 golden rules to apply risk management successfully in your project. They are based on personal experiences of the author who has been involved in projects for over 15 years. Also the big pile of literature available on the subject has been condensed in this article.   Rule 1: Make Risk Management Part of Your Project   The first rule is essential to the success of project risk management. If you don't truly embed risk management in your project, you can not reap the full benefits of this approach. You can encounter a number of faulty approaches in companies. 
Some projects use no approach whatsoever to risk management. They are either ignorant, running their first project or they are somehow confident that no risks will occur in their project (which of course will happen). Some people blindly trust the project manager, especially if he (usually it is a man) looks like a battered army veteran who has been in the trenches for the last two decades. Professional companies make risk management part of their day to day operations and include it in project meetings and the training of staff.

Rule 2: Identify Risks Early in Your Project

The first step in project risk management is to identify the risks that are present in your project. This requires an open mind set that focuses on future scenarios that may occur. Two main sources exist to identify risks, people and paper. People are your team members that each bring along their personal experiences and expertise. Other people to talk to are experts outside your project that have a track record with the type of project or work you are facing. They can reveal some booby traps you will encounter or some golden opportunities that may not have crossed your mind. Interviews and team sessions (risk brainstorming) are the common methods to discover the risks people know. 
Paper is a different story. Projects tend to generate a significant number of (electronic) documents that contain project risks. They may not always have that name, but someone who reads carefully (between the lines) will find them. The project plan, business case and resource planning are good starters. Another categories are old project plans, your company Intranet and specialised websites.

Are you able to identify all project risks before they occur? Probably not. However if you combine a number of different identification methods, you are likely to find the large majority. If you deal with them properly, you have enough time left for the unexpected risks that take place.

Rule 3: Communicate About Risks

Failed projects show that project managers in such projects were frequently unaware of the big hammer that was about to hit them. The frightening finding was that frequently someone of the project organisation actually did see that hammer, but didn't inform the project manager of its existence. If you don't want this to happen in your project, you better pay attention to risk communication.  
A good approach is to consistently include risk communication in the tasks you carry out. If you have a team meeting, make project risks part of the default agenda (and not the final item on the list!). This shows risks are important to the project manager and gives team members a "natural moment" to discuss them and report new ones. Another important line of communication is that of the project manager and project sponsor or principal. Focus your communication efforts on the big risks here and make sure you don't surprise the boss or the customer! Also take care that the sponsor makes decisions on the top risks, because usually some of them exceed the mandate of the project manager.

Rule 4: Consider Both Threats and Opportunities

Project risks have a negative connotation: they are the "bad guys" that can harm your project. However modern risk approaches also focus on positive risks, the project opportunities. These are the uncertain events that beneficial to your project and organisation. These "good guys" make your project faster, better and more profitable.  
Unfortunately, lots of project teams struggle to cross the finish line, being overloaded with work that needs to be done quickly. This creates project dynamics where only negative risks matter (if the team considers any risks at all). Make sure you create some time to deal with the opportunities in your project, even if it is only half an hour. Chances are that you see a couple of opportunities with a high pay-off that don't require a big investment in time or resources.  

Rule 5: Clarify Ownership Issues

Some project managers think they are done once they have created a list with risks. However this is only a starting point. The next step is to make clear who is responsible for what risk! Someone has to feel the heat if a risk is not taken care of properly. The trick is simple: assign a risk owner for each risk that you have found. The risk owner is the person in your team that has the responsibility to optimise this risk for the project. The effects are really positive. At first people usually feel uncomfortable that they are actually responsible for certain risks, but        as time passes they will act and carry out tasks to decrease threats and enhance opportunities.  
Ownership also exists on another level. If a project threat occurs, someone has to pay the bill. This sounds logical, but it is an issue you have to address before a risk occurs. Especially if different business units, departments and suppliers are involved in your project, it becomes important who bears the consequences and has to empty his wallet. An important side effect of clarifying the ownership of risk effects, is that line managers start to pay attention to a project, especially when a lot of money is at stake. The ownership issue is equally important with project opportunities. Fights over (unexpected) revenues can become a long-term pastime of management. 

Rule 6: Prioritise Risks

A project manager once told me "I treat all risks equally." This makes project life really simple. However, it doesn't deliver the best results possible. Some risks have a higher impact than others. Therefore, you better spend your time on the risks that can cause the biggest losses and gains. Check if you have any showstoppers in your project that could derail your project. If so, these are your number 1 priority. The other risks can be prioritised on gut feeling or, more objectively, on a set of criteria. The criteria most project teams use is to consider the effects of a risk and the likelihood that it will occur. Whatever prioritisation measure you use, use it consistently and focus on the big risks.

Rule 7: Analyse Risks

Understanding the nature of a risk is a precondition for a good response. Therefore take some time to have a closer look at individual risks and don't jump to conclusions without knowing what a risk is about.  Risk analysis occurs at different levels. If you want to understand a risk at an individual level it is most fruitful to think about the effects that it has and the causes that can make it happen. Looking at the effects, you can describe what effects take place immediately after a risk occurs and what effects happen as a result of the primary effects or because time elapses. A more detailed analysis may show the order of magnitude effect in a certain effect category like costs, lead time or product quality. 
Another angle to look at risks, is to focus on the events that precede a risk occurrence, the risk causes. List the different causes and the circumstances that decrease or increase the likelihood.  Another level of risk analysis is investigate the entire project. Each project manager needs to answer the usual questions about the total budget needed or the date the project will finish. If you take risks into account, you can do a simulation to show your project sponsor how likely it is that you finish on a given date or within a certain time frame. A similar exercise can be done for project costs.  The information you gather in a risk analysis will provide valuable insights in your project and the necessary input to find effective responses to optimise the risks.

Rule 8: Plan and Implement Risk Responses

Implementing a risk response is the activity that actually adds value to your project. You prevent a threat occurring or minimise negative effects. Execution is key here. The other rules have helped you to map, prioritise and understand risks. This will help you to make a sound risk response plan that focuses on the big wins.  If you deal with threats you basically have three options, risk avoidance, risk minimisation and risk acceptance. Avoiding risks means you organise your project in such a way that you don't encounter a risk anymore. This could mean changing supplier or adopting a different technology or, if you deal with a fatal risk, terminating a project. 
Spending more money on a doomed project is a bad investment.  The biggest category of responses are the ones to minimise risks. You can try to prevent a risk occurring by influencing the causes or decreasing the negative effects that could result. If you have carried out rule 7 properly (risk analysis) you will have plenty of opportunities to influence it. A final response is to accept a risk. This is a good choice if the effects on the project are minimal or the possibilities to influence it prove to be very difficult, time consuming or relatively expensive. Just make sure that it is a conscious choice to accept a certain risk.  Responses for risk opportunities are the reverse of the ones for threats. They will focus on seeking risks, maximising them or ignoring them (if opportunities prove to be too small).

Rule 9: Register Project Risks

This rule is about bookkeeping (however don't stop reading). Maintaining a risk log enables you to view progress and make sure that you won't forget a risk or two. It is also a perfect communication tool that informs your team members and stakeholders what is going on (rule 3).  A good risk log contains risks descriptions, clarifies ownership issues (rule 5) and enables you to carry our some basic analyses with regard to causes and effects (rule 7). 
Most project managers aren't really fond of administrative tasks, but doing your bookkeeping with regards to risks pays off, especially if the number of risks is large. Some project managers don't want to record risks, because they feel this makes it easier to blame them in case things go wrong. However the reverse is true. If you record project risks and the effective responses you have implemented, you create a track record that no one can deny. Even if a risk happens that derails the project. Doing projects is taking risks.

Rule 10: Track Risks and Associated Tasks

The risk register you have created as a result of rule 9, will help you to track risks and their associated tasks. Tracking tasks is a day-to-day job for each project manager. Integrating risk tasks into that daily routine is the easiest solution. Risk tasks may be carried out to identify or analyse risks or to generate, select and implement responses.  Tracking risks differs from tracking tasks. It focuses on the current situation of risks. Which risks are more likely to happen? Has the relative importance of risks changed? Answering this questions will help to pay attention to the risks that matter most for your project value.        
The 10 golden risk rules above give you guidelines on how to implement risk management successfully in your project. However, keep in mind that you can always improve. Therefore rule number 11 would be to use the Japanese Kaizen approach: measure the effects of your risk management efforts and continuously implement improvements to make it even better.  Success with your project.

Examples of information gathering techniques used in identifying risk can include:     Brainstorming. The goal of brainstorming is to obtain a comprehensive list of project risks. Our project team performed the brainstorming with a multidisciplinary set of experts not on the team. Ideas about project risk are generated under the leadership of a facilitator. Categories of risk such as a risk breakdown structure can be used as a framework.  (see earlier post) Risks are then identified and categorized by type of risk and their definitions are sharpened.     
Delphi technique. The Delphi technique is a way to reach a consensus of experts. We used Project risk experts as well as Technology experts to participate in this technique anonymously. A facilitator uses a questionnaire to solicit ideas about the important project risks. The responses are summarized and are then sent back to the experts for further comment. Consensus may be reached in a few rounds of this process. The Delphi technique helps reduce bias in the data and keeps any one person from having undue influence on the outcome.
Interviewing. We also interviewed experienced project participants, stakeholders and subject matter experts to identify risks. Interviews are one of the main sources of risk identification data gathering.     
Root cause identification. This is an inquiry into the essential causes of a project’s risks. It sharpens the definition of the risk and allows grouping risks by causes. Effective risk responses can be developed if the root cause of the risk is addressed.     
Strengths, weaknesses, opportunities, and threats (SWOT) analysis. This technique ensures examination of the project from each of the SWOT perspectives, to increase the breadth of considered. Our project team used this technique to more fully examine the risks that had been identified.     
Checklist Analysis. Risk identification checklists can be developed based on historical information and knowledge that has been accumulated from previous

similar projects and from other sources of information. This means you have to record project information at the end of the project to build the historical database. The lowest level of the risk breakdown structure can also be used as a risk checklist. While a checklist can be quick and simple, it is impossible to build  an exhaustive one. Care should be taken to explore items that do not appear on the checklist. The checklist should be reviewed during project closure to improve it for use on future projects.

Assumptions Analysis. Every project is conceived and developed based on a set of hypotheses, scenarios, or assumptions. Assumptions analysis is a tool that explores the validity of assumptions as they apply to the project. It identifies risks to the project from inaccuracy, inconsistency, or incompleteness of assumptions.
Diagramming Techniques. Risk diagramming techniques may include:
  • Cause-and-effect diagrams. These are also known as Ishikawa or fishbone diagrams, and are useful for identifying causes of risks. We used these frequently in projects.     
  • System or process flow charts. These show how various elements of system interrelate, and the mechanism of causation. Seeing the flow sometimes triggers someone to identify a risk that may have slipped through the cracks.
Influence diagrams. These are graphical representations of situations showing causal influences, time ordering of events, and other relationships among variables and outcomes.     You can never spend too much time in identifying risks. After the list is made, qualitative and quantitative analysis is done to figure out which risks you spend time and/or money on. Murphy’s law is always a good one!

When doing Risk Management Planning, one input you need is a Risk Breakdown Structure. The model is similar to the Work Breakdown Structure. It may change during the Risk Management Planning Process. Here is an example Risk Management breakdown:
Technical  Requirements  
Performance  Management  
Company Vision  Capital  
Organizational  Dependencies  Budget  Prioritization  
Project Management  Estimating  
Risk Breakdown Structures will vary between projects. One benefit of doing one is to remind those people engaged in the Risk Identification process of areas to think about. It will also be an input to Qualitative Risk Analysis where probabilities and impacts are assigned.  The impacts can be numerical or High, Medium, Low.     
Risks are then prioritized according to their potential implications for affecting the Project’s success. Other things to take into account are stakeholder’s risk tolerance levels, reporting formats and how you will track the risks. The next step in the process will be Risk Identification.

What goes into a Project Plan?
The Scope Management Plan: This is a document that defines the Scope of the Project. It is especially important to be though and accurate because it feeds into the Requirements document. It is also important that all the Stakeholders buy into it. It should be signed off before going the next step. If the Scope changes it has to go through a change management process and all of the Stakeholders must sign off on it. 

1-chedule Management Plan: The Schedule Management Plan is a component part of the Project Plan that is use in Activity resource planning. The  Activity resource plan includes expert judgment, various levels of resource levels or skills, size of machines, tools and make/buy decisions.
1-Cost Management Plan:Costs will adhere to a prescribed precision based on the scope of the project and may include a contingency amount. Various cost measures or other indicators (e.g. person-days, volume of product).         
1-Quality Management Plan: The Quality Management Plan describes how the project team will implement the organization’s quality policy. It must address the quality control, quality management and continuous process improvement for the project.

1-Staffing Management Plan: Identifying project roles, responsibilities and reporting relationships. Obtaining the human resources to complete the project. Improving the competencies and interaction of team members to enhance project performance. Team building plays a big part here.         
1-Communications Plan: Determining the information needs of the stakeholders. Making needed communications available to the stakeholders in a timely manner. Collecting and distributing performance information including status reports, performance reports and forecasting.

1-Risk Management Plan: The Risk Management Plan includes risk identification, risk analysis, risk response planning, monitoring and control.   
1-The Procurement Plan: This plan includes what has to be procured, who will provide the estimates, types of contracts to be used, managing multiple providers, constraints and assumptions that could affect the contract and handling make/buy decisions. 

This is a process concerned with identifying, analyzing, and responding to project risk. (PMBOK)  It is also the art and science of identifying, assessing and responding to project risk throughout the life of a project and in the best interests of its objectives. Now in all of the projects I’ve managed in my 30 years of experience, there has always been risk.   
The trick to the game is to figure out what the risk tolerance of your stakeholders is. How much risk are they willing to put up with and how much do they want solid fallback plans for?  In some cases, a level of uncertainty is acceptable and the level of contingency planning can be as simple as put another person on the project, or slip the schedule. Sometimes it’s not so simple, and the stakeholders want to know the monetary value or expected value of the probability of a risk occurring. The basic level for excepted value is: 

Expected monetary value (EMV) = probability * impact The expected value result can either be added to the costs of the project or subtracted from the project’s profit. The project profit or cost is usually referred to as the baseline. The baseline is the initial approved cost or profit structure for the project.   
Project EMV = project cost + risk expected value – opportunity expected value  -Or-  = project value/profit – risk expected value + opportunity expected value 

Remember, risk increases the cost and decreases the profit; and opportunity increases the profit and decreases the cost. Risks are bad things that may (often do) happen to us on projects, sometimes expressed as “threats”. Opportunities are good things that may happen to us on projects and may enhance the overall situation.

Uncertainty  Lack of knowledge of future events  Goals of PRM  To identify project risks and develop strategies which either significantly reduce them or take steps to avoid them.  Opportunity The probability those outcomes will be favorable.  Risk  The probability those outcomes will be unfavorable.  Project Risk  Is the cumulative effect of the chances of uncertain occurrences adversely affecting project objectives. Risk Factors 
  1. Risk Event – Precisely what might happen to the detriment of the project
  2. Risk Probability – How likely the event is to occur
  3. Amount at Stake – The severity of the consequences
Probability  Probability = Frequency of relevant events Total number of possible events        Risk Event Status (criterion value or ranking)  Risk Event status = risk probability x amount at stake


1-Risk Identification  
Determining which risks are likely to affect the project and documenting the characteristics of each.  Can be classified as:
  1. Scope– Risk associated with changes of scope or the subsequent need for “fixes” to achieve the required technical deliverables. 
  2. Quality– Failure to complete tasks to the required level of technical or quality performance 
  3. Schedule– Failure to complete tasks within the estimated time limits, or risks associated with dependency network logic 
  4. Cost – Failure to complete tasks within the estimated budget allowances
  5. Risk Quantification
Evaluating risks and risk interactions to assess the range of possible project outcomes.      
-Risk Response Development  Defining enhancement steps for opportunities and responses to threats.      
-Risk Response Control  Responding to changes in risk over the course of the proj

-Product description  
Risk depends on the nature of the product.  Proven technology has less risk than products requiring innovation and invention.
-Other Planning outputs  Review outputs from the processes for possible risks, e.g., WBS, cost estimates and schedule duration’s, staffing plan, procurement management plan.
  1. Historical information     
  2. Tools and Techniques     
  3. Checklists     
  4. Flowcharting
Helps understand the cause and effects of risks.
  1.  Outputs     
  2. Sources of Risks 
This includes such items as stakeholder actions, unreliable estimates, team turnover, changes in requirements, insufficiently skilled staff.
-Potential Risk Events
Precisely what might happen to the detriment of the project, such as natural disasters, requirement for development of new technology, etc.

-Risk symptoms  
These sometimes are called triggers, early warning of an impending event, etc.

-Inputs to other processes  
Risks can be inputs to other processes as constraints or assumptions.


Stakeholder risk tolerances

This provides a screen for both inputs and outputs to risk quantification.
  1. Sources of risk     
  2. Potential risk events     
  3. Cost Estimates    
  4. Activity duration estimates     
  5. Tools and Techniques    
  6. Expected Monetary value
This is the product of risk event probability of occurring times the risk event value (could be a gain or loss).
Statistical sums  This calculates the range of alternative project budgets from the cost estimates for individual work items.      
The most common is Monte Carlo analysis, which is used to analyze the behavior or performance of the system. The results of a schedule simulation may be used to quantify the risk of various schedule alternatives, different project strategies, and different paths through the network or individual activities.   
  1.  Decision Tree     
  2. Expert Judgment     
  3. Opportunities to pursue, threats to respond to 
This is a list of opportunities that should be pursued and threats that require attention.         Opportunities to ignore, threats to accept.
Related Topics:
The Author: Ala'a Elbeheri
                                         Ala'a Elbeheri
A versatile and highly accomplished senior certified IT risk management Advisor and Senior IT Lead Auditor with over 20 years of progressive experience in all domains of ICT. 
• Program and portfolio management, complex project management, and service delivery, and client    relationship management.      
• Capable of providing invaluable information while making key strategic decisions and spearheading customer-centric projects in IT/ICT in diverse sectors.    
• Displays strong business and commercial acumen and delivers cost-effective solutions contributing to financial and operational business growth in international working environments.      
• Fluent in oral and written English, German, and Arabic with an Professional knowledge of French.  • Energetic and dynamic relishes challenges and demonstrates in-depth analytical and strategic ability to facilitate operational and procedural planning.  
• Fully conversant with industry standards, with a consistent track record in delivering cost-effective strategic solutions.    
• Strong people skills, with proven ability to build successful, cohesive teams and interact well with individuals across all levels of the business. Committed to promoting the ongoing development of IT skills  throughout an organization.

Post a Comment

Previous Post Next Post