pmNERDS Community: Login

  • Innovation_e_Publication
  • Integrated_PM_Feedback_Blog
  • Job_Board
  • pmNERDS_Center_of_Excelence
  • Research_and_Development_Journal
  • Community_Blog
A+ A A-

A Risk Boundary Problem

“If I concern my project with risk assessment, then my project targets such as Budget, Schedule, and quality become more reliable, but this will require me to define better project boundaries between strategy, program mandates, and project requirements.”

What is risk? The answer to this question depends on who answers it and the boundaries the individual establishes around themselves. If the answer comes from someone who is responsible for all processes within the Integrated PM system boundary, a clear answer can be expected. Risk is obvious when people own their processes. The owner is anxious about resources being well spent and not wasted, and that the results are acceptable. They want to maximize the chance of success and looks for clues to act upon. In other words, the owner deliberately sees risks and responds to them. If they grow nonchalant and detached, they don’t see many risks or don’t feel like acting upon them. When nonowners see risks, and communicate them to those who run the process, the result is conflict.

Risk arises from factors beyond our control. A designer may consider requirement analysis as a source of risk because it is external to him and he is not sure whether the analysis results will be communicated completely and correctly. This is a "dependency risk." A boundary is drawn around the process, and risks that threaten the process from across the boundary are seen. Risk perception has a built-in boundary perception. Risk definition has meaning only with reference to this boundary.

Within the process owner's boundary, a problem is not immediately seen as a risk, even if it happens to be vague and uncertain. The propensity is to assign the problem to process control and process management.

Across the boundary, the propensities change. A process owner has no influence beyond her boundary. Neighboring processes are alien and appear to be sources of risk. Problems tend to get labeled as risks.

When the boss of the SBU (strategic business unit) looks at the same risk from a larger perspective, the risk looks smaller and local. The risk appears to have occurred due to lack of cooperation between two process owners. She does not want to think of this local issue as a major risk, as things can improve through better management. If provoked, she may term this an internal risk that can be solved by taking internal measures. The SEU boss realizes that the better the management, the fewer the internal risks.

There are some sensitive internal conditions, such as when a PM chooses to run a project without adequate resources and authority. The processes have weaknesses that are well known to the stakeholders. Process weaknesses are potential breeding grounds for risks. But the PM may not have the resources, power, and influence to improve process capabilities. All the PM can do is mitigate the harmful effects, promote awareness of the risks, and prepare contingency plans. Risks have a different connotation in this case.

It is important to define internal risks, because they contribute to more than 65 percent of risks in a typical business environment.

Internal risks are solved by internal response plans. Most internal risks evoke short-term plans that operate within the life of the project. These are dependency risks that are solved by better coordination and risk communication. Some internal risks arise because of lack of process capability. There is no quick solution to such problems. This calls for a well-designed process improvement plan. The nature of improvement can be a series of continual improvements or kaizens, or a major breakthrough improvement of the Six Sigma style. Such improvements require more resources and time.

Yet another type of internal risk is seen on comparing growth objectives with current performance levels. Today is fine, but tomorrow may bring hurdles. Perception of such risks comes from long-term vision. If growth goals are taken seriously, one finds more risks. If growth goals are taken as secondary concerns, one does not see risks. I find that architects of the organization will detect growth-related risks, while most PMs don’t. When an organization is divided, more boundaries appear and employees see more internal risks. When the organization is integrated, such as in Integrated PM, internal risks are called process management issues. In an integrated organization with boundaries, collaborative efforts make up for weaknesses and create an organizational capability that is greater than the sum of individual process capabilities. This is the Integrated PM system with sub-components. In fragmented organizations, risks multiply.

Internal risk is the probability of suffering losses while pursuing performance and growth goals because of inadequacies in process capability (including core and support processes) and organizational structure.

Beyond the organizational boundary, however, things are different.

External conditions are beyond our control. There are risk factors beyond our sphere of influence. Competitors cut prices and marketing times almost ruthlessly. Social forces may erode staff loyalty. The PM sees external risks as threats and develops strategies to deal with them.

External risk is the probability of suffering loss while pursuing performance and growth goals because of uncer-tainties in external conditions.

There cannot be a better example of external risk than requirements.

The requirements keep changing; they "creep." The volatility of requirements is a perennial source of uncertainty and, hence, risk. Requirements go through a metamorphosis, becoming bigger and clearer in each phase of their evolution. Requirement evolution is a subject for continuous observation and modeling. Requirement volatility is beyond our control and is uncertain. Change is inevitable and is beyond prediction. When the requirement risk occurs, it can cause numerous problems for the project. Managers are aware of this. They cannot avoid it, but are prepared. Those who have mastered this risk, experience fewer surprises when requirements change.

Continue reading
118 Hits
0 Comments

What is Project Risk?

“If I perform risk management for a project, we might be more successful, but I’m not sure what risk really is.”

The original meaning of risk is associated with gambling- to risk is to gamble. When we take risks, there is a chance of gaining and perhaps an equal chance of losing. Project risk has evolved to mean more.

Uncertainty in business ventures has come to be known as risk. Every business venture is basically risky. In new business ventures, project initiatives, and new product development, there are unknown factors and their impacts on the venture are equally unknown. The unknown factors could be favorable or unfavorable. There is a probability that one may either gain or lose business value. However, a loss may hurt the venture. Most business ventures like to assess the probability of loss and compare it with the probability of gain. The decision to go ahead depends on whether the odds are favorable or unfavorable. Risk is the probability of suffering loss. Using this approach, the PMO or Project Steering Committee will not pursue a venture that has a risk probability greater than 49 percent. The odds must be in favor of winning the gamble, even though the tilt is marginal.

Definition 1.1: Risk is the probability of suffering loss.

A refinement of this definition is to include goals, gains, or opportunities in the statement. Perhaps it is implied and obvious that risks relate to gains. Nevertheless, if risks are divorced from the associated goals, then one sees just a set of problems. A risk list should not be reduced to a problem list. Risks have a much broader role to play. We should always include the expected and potential gains that a project offers in the risk assessment.

Definition 1.2: Risk is the probability of suffering loss while pursuing goals

Then there is the consideration of the magnitude of harm from the risk. What will its impact be? The consequence of the risk is evaluated. If the harm is tolerable but the gains are attractive, new decision rules can emerge. One may even take a risk where the occurrence probability is greater than 50 percent. The threshold is not 49 percent. Risk is seen as a weighed parameter and can fluctuate. The weight is based on the magnitude of loss due to risk, if the risk ever occurs.

Risk magnitude is measured using many different estimation methods. When the estimations form a range; such as a minimum of 12 and a maximum of 20, for a measure you want to maximize. You would compute half the distance between the max and min which is 4. Your estimate magnitude is 16 (the mean of the two numbers) with a risk of 4. 4 is 25% of 16, so you might report a risk magnitude of 25%. My point here is magnitude is dealt with in multiple ways.

Risk is defined as the combination of probability of occurrence and the magnitude of loss it causes. This combination is also known as risk exposure. The new definition below takes this into consideration.

Definition 1.3: Risk is the combination of probability and magnitude of loss.

Typically, project risk is defined and measured using Definition 1.3. Measure-ment of risk is often a subjective process. Both the probability and loss are measured using linguistic measures such as "high," "medium," and "low" which are nominal metrics. What matters is not just the risk, but its intensity, measured as risk exposure. Will the risk occur? What will the harm be? These are more significant questions than, "What is the risk?"

A clarification is due at this juncture. If loss occurs because of factors within our control, it is not considered as a risk. Only factors beyond our control give rise to risk. This is the general perception that makes risk management simple. Internal factors are within our control. Hence, only external factors that contribute to loss, which are not under the project manager’s direct control, qualify as risk factors. When this notion prevailed, people believed that they had not caused the risks.

Sometimes, processes are not in control and results are not predictable or what were intended. Such losses become risks. In this case, the origin is not the criterion - predictability and control are important factors. Hence, a complete risk definition would be:

Definition 1.4: Risk is the probability of suffering loss while pursuing goals due to factors that are unpredictable or beyond the PM’s control.

Continue reading
196 Hits
0 Comments

What types of problems can risk assessment be applied to?

“If I use risk management practices then I might be able to determine a range of possibilities, but I'm not sure of the type of problems risk assessment can be applied?”

Risk management may not be everything you think. Here are some examples of how project estimates other than traditional 'Risk’ logs are used in project planning and project portfolio management.

The Legal Model - A model that calculated the net benefit of settlement vs. litigation was built to aid in legal decisions. The net benefit of a settlement, net cost of litigation, the net cost of the settlement, a total cost of a verdict, and other outputs were calculated. Input variables that comprised broad categories included parameters such as litigation costs, total damages, the likelihood of a verdict, and other probabilistic and economic aspects. Project selection and ranking were then based on the estimates of this risk model. Maintaining a 'risk log' wasn't even part of the effort, but the use of anticipated risk events and the associated probabilities certainly are.

An Environmental Health and Safety Model- Models were built that calculated the total environmental, health, and safety risk and cost associated with entry by the company into various countries around the world. Risk of subcomponents of the model were also calculated and presented. Input-variable categories (many variables per category) included public perception considerations, government approvals/permits, ecological/cultural parameters, health and safety considerations, and evaluation of preexisting damage. In this case, risk assessment happened during strategic program planning and then downstream to provide guidelines and constraints to project managers.

Pipeline Route-Selection model- Oh boy, a comprehensive time-series model was constructed to help a consortium decide which of several routes would be selected to construct a pipeline for a major oil field. The pipeline route-selection model calculated tariffs and other parameters from variables that represented major categories of consideration. These included political concerns, environmental problems, commercial considerations, financial parameters, technical considerations, taxes (for many countries), and other parameters. This model was used with great success to rank and prioritize the routes of pipeline projects. Financial estimates then drove project constraints. Notice when in the project planning cycle, risk management practices and risk events were considered.

Political models- Models were constructed that evaluated other countries based on categories of variables. Categories included political stability, foreign investment conditions, operating environment, transportation infrastructure, and other considerations. Results from the models facilitated comparison of countries on a common scale. Once again, these models drove selection criteria based on risk factors, not during the execution of a project already committed to.

Capital Project Ranking and Portfolio Management model- This model calculated profitability index (PI), internal rate of return (IRR), net present value (NPV), and other financial outputs. Input variables included project safety and environmental aspects, cost estimates, incentives, discount rates, taxes, maintenance and insurance costs, and other considerations. This model was run on all capital projects at a manufacturing facility. The projects were ranked and portfolio-managed based upon the model outputs. No this wasn't the only model used. Before this model was used, other assessments were leveraged while financial information wasn't yet available. These capital projects had already gone through capacity planning and were now going through the second level of estimation. Notice that risk modeling of risk events are used throughout the project planning lifecycle to provide probabilistic estimates. Too many times, as project managers, we use the single value, deterministic estimates of performance factors which are not fixed.

New Products model- Research and development organizations generate products and processes, each of which may have commercial value. It is, however, expensive to launch a new product in the marketplace. Therefore, products and processes need to be ranked. A model was built that included categories of variables. Some of the categories were technical considerations, marketing aspects, financial/commercial facets, and others. The model facilitated the application of weights to the various considerations. Results from the model allowed the prioritization of potential new products. These models can be complex, but depending on when the estimates are being used, can take less than 5 minutes per project to estimate.

Fate/Transport model - A model was constructed to calculate inhalation exposure. Exposure was represented in the model as the average daily dose for noncarcinogens and the lifetime average daily dose for carcinogens. Among the input variables were parameters such as the concentration of chemicals in the air, inhalation rate, bioavailability, exposure duration, exposure frequency, body weight, average lifetime, and other considerations.

My point is that risk management efforts involve more than only the maintenance of the project risk log, and typically models save the organization time, and make their project planning efforts more robust and consistent, smoothing the way for project management activities.

 

Joocial Post Management Message Hashtags Description (optional) Post This Default Evergreen Post No Channels Agenda Repeat Expression Until Post Image

Continue reading
175 Hits
0 Comments