You are not logged in.
E-Learning Innovation Spark Grandview Services Community
  • Innovation_e_Publication
  • Integrated_PM_Feedback_Blog
  • Job_Board
  • pmNERDS_Center_of_Excelence
  • Research_and_Development_Journal
  • Community_Blog
A+ A A-
5 minutes reading time (954 words)

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.

1
The Project Work Breakdown Structure (WBS)
Placement in Performance Measure Framework
 

Comments

No comments made yet. Be the first to submit a comment
Already Registered? Login Here
Guest
Friday, 19 October 2018
If you'd like to register, please fill in the username, password and name fields.