FIGURE 11-8. Methodology imputs.

FIGURE 11-9. Resistance to change.

Sales ▼ Finance ▼ H.R. ^Engineering! ] Marketing Procurement Manufacturing R&D

FIGURE 11-9. Resistance to change.

project managers may become involved in the sales effort, thus diminishing the power of the salesforce.

• Marketing: Marketing people fear that project managers will end up working so closely with the customers that they may eventually be given some of the marketing and sales functions. This fear is not without merit because customers often want to communicate with the personnel managing the project rather than with marketing staff, who may well disappear after the closure of the sale.

• Finance (and accounting): These departments fear that project management will require the development of a project accounting system (such as earned value measurement), which, in turn, will increase the workload in accounting and finance. Accounting personnel are not happy with having to learn earned value measurement, and having to perform accounting both horizontally (i.e., in projects) and vertically (i.e., in line groups).

• Procurement: The fear among this group is that a project procurement system will be implemented in parallel with the corporate procurement system, and that the project managers will perform their own procurement, thus bypassing the procurement department.

• Human resources management: The H. R. department may fear that a project management career path ladder will be created, not to mention a need for project management training programs. Human resources personnel may find that their traditional training courses, with which they feel very comfortable, have to undergo major change to satisfy project management requirements. This will increase their workloads.

• Manufacturing: Little resistance is usually found here because, although the manufacturing segment of a company is not project-driven, staff there are usually familiar with numerous capital installation and maintenance projects, which will have required the use of project management.

• Engineering, R&D, and Information Technology: These departments are almost entirely project-driven with very little resistance to project management. Project management is viewed as a necessity.

Getting the support of and partnership with functional management in the involved departments can usually overcome the resistance that exists on an organi-


Causes of Resistance

Ways to Overcome Resistance

• New guidelines/processes

• Dictate mandatory conformance

• Need to share "power"

from above


• Create new comfort zones at an

• Creating a fragmented work

acceptable pace


• Identify tangible/intangible individual

• Giving up established work



• Changing comfort zones


Causes of Resistance Ways to Overcome Resistance

• Unknown new relationships • Maintain existing relationships in effect

• Multiple-boss reporting • Avoid cultural shock

• Multiple temporary assignments • Find an acceptable pace for rate of change

• Severing established ties zational level. However, the resistance that may occur on an individual level is usually more complex and more difficult to overcome. Individual resistance levels may result from:

• Potential changes in work habits

• Potential changes in the social groups

• Embedded fears

• Potential changes in the wage and salary administration program

Tables 11-2 through 11-5 show how these different issues can lead to resistance, and list possible solutions. It is imperative that we understand the resistance to change. If individuals are happy with their current environment, there will always be resistance to change. But even if people are unhappy with their present environment, there will still exist resistance to change unless: (1) people believe that the change is possible, and (2) people believe that they will somehow benefit from the change. People are usually apprehensive over what they must give up rather than excited about what they will get in return. Not all people will be at the same readiness level for change even if the entire organization is going through the change. People will handle only so much change at one time and, if management eases up on its pressure for change, employees will revert back to their old ways.

Management is the architect for the change process. Management must develop the appropriate strategies such that the organization can align itself with change. This is best done by developing a shared understanding with the employees expected to make the change.


Causes of Resistance Ways to Overcome Resistance


Causes of Resistance Ways to Overcome Resistance

Fear of failure

• Educate employees on benefits of changes to

Fear of termination

the individual/corporation

Fear of added workload

• Show a willingness to admit/accept mistakes

Fear of uncertainty/unknowns

• Show a willingness to pitch in

Dislike of uncertainty/unknowns

• Transform unknowns into

Fear of embarrassment


Fear of a "we/they" organization

• Share information

TABLE 11-5.


Causes of Resistance Ways to Overcome Resistance

• Shifts in authority and power • Link incentives to change

• Lack of recognition after the changes • Identify future advancement

• Unknown rewards and punishment opportunities/career paths

• Improper evaluation of personal performance

• Multiple-boss reporting

Performing the following can facilitate the change process:

• Management must explain to the employees the reasons for the change and solicit feedback.

• Management must explain to the employees what outcomes are desired and why.

• Management must champion the change process.

• Management must empower the appropriate individuals to institutionalize the changes.

• Management must be willing to invest in training necessary to support the changes.


A partnership is a group of two or more individuals or groups working together to achieve a common objective. Historically, partnerships were often between companies working together rather than between individuals. In project management, the critical partnership is the working relationship between the project and line managers.

In the early days of project management, the selection of the individual to serve as the project manager was most often dependent upon who possessed the greatest command of technology. The ultimate result, as shown in Figure 11-10, was a very poor working relationship between the project and line managers. Line managers viewed project managers as a threat, and their relationship developed into a competitive, superior-subordinate relationship. The most common form of organizational structure was a strong matrix where the project manager, perceived as having a command of technology, had a greater influence over the assigned employees than did their line manager.

As the magnitude and technical complexity of the projects grew, it became obvious that the project managers could not maintain a command of technology in all aspects of the project. Now, project managers were viewed as possessing an understanding of rather than command of technology. Project managers were now becoming more dependent upon line managers for technical support. The project man-



Technical Capability ^

Command of Technology

Technical Capability ^

Technical Understanding



Working Relationship

Matrix Strength



FIGURE 11-10. Partnership strength.

ager now finds himself or herself in the midst of a weak matrix where the employees are receiving the majority of their technical direction from the line managers.

As the partnership between the project and line managers begins to develop, management recognizes that partnerships work best on a peer-to-peer basis, rather than on a superior-to-subordinate basis. Now the project and line managers view each other as equals and share in the authority, responsibility, and accountability needed to assure project success.

Good project management methodologies emphasize the cooperative working relationship that must exist between the project and line managers. Conflict resolution channels may be clearly spelled out as part of the methodology, and which manager has the final decision in specific areas of knowledge may be specified.



Most project management methodologies today have sections on risk management. The project management methodology may very well dictate the magnitude of the risk control measures to be undertaken. The risk control measures for risk assumption may be significantly more complex than risk control measures for avoidance.

Figure 11-11 shows the intensity of the controls versus the intensity of the risks. As the intensity of the risks increase, we tend to place more controls in the risk management process and the project management methodology. Care must


Standard Controls


Standard Controls

Risk Intensity


FIGURE 11-11. Risk control measures.

Risk Intensity


FIGURE 11-11. Risk control measures.

be taken that the cost of maintaining these control measures does not overly burden the project. Time and money are required for effective risk management. Excessive controls may require that the project manager spend more time performing risk management rather than actually managing the project.

How to determine the proper amount of risk control measures is not easy. This can be seen from Figure 11-12, which illustrates the impact on the schedule

Too Long n

^ Appropriate

Too Long n

^ Appropriate

Too Many isk Manageme «-Filters and> Gates

Risk Controls ■

Too Many isk Manageme «-Filters and> Gates


FIGURE 11-12. Risk controls.

constraint. If not enough control measures are in place, or if there simply is no risk management plan, the result may be an elongated schedule due to ineffective risk control measures. If excessive risk control measures are in place, such as too many filters and gates, the schedule can likewise be elongated because the workers are spending too much time on contingency planning, risk reporting, documentation, and risk management meetings (i.e., there may be too many gates). This results in very slow progress being made. A proper balance is needed.


If project managers had unlimited funding they could always identify a multitude of risk events. Some of the risk impacts may be insignificant, whereas others may expose the project to severe danger. With a large number of possible risk events, it is impossible to address each and every situation. It may be necessary to prioritize risks.

Assume that the project manager categorizes the risks according to the project's time, cost, and performance constraints, as illustrated in Figure 11-13. According to the figure, the project manager should focus his/her efforts on reducing the scheduling risks first. The prioritization of risks could be established by the project manager, by the project sponsor, or even by the customer. The prioritization of risks can also be industry- or even country-specific, as shown in Figure 11-14. It is highly unlikely that any project management methodology would dictate the prioritization of risks. It is simply impossible to develop stan-



Technical Performance or Quality




Second Priority

Third Priority

FIGURE 11-13. Prioritization of risks.

FIGURE 11-13. Prioritization of risks.

(Note: Lower priorities more often undergo tradeoffs)

<- American Priorities


Product Timing Quality &

2 A Price Performance

Quality r4 io

<8 Cost of Development

6 7 A Product Performance

FIGURE 11-14. Ordering of tradeoffs.

dardization in this area such that the application could be uniformly applied to each and every project.

The prioritization of risks for an individual project is a good starting point and could work well if it were not for the fact that most risks are interrelated. We know from tradeoff analysis that changes to a schedule can, and probably will, induce changes in cost and performance. Therefore, even though schedules have the highest priority in Figure 11-13, risk response to the schedule risk events may cause immediate evaluation of the technical performance risk events. Risks are interrelated.

The interdependencies between risks can also be seen from Table 11-6. The first column identifies certain actions that the project manager can opt for to take advantage of the opportunities in column 2. Each of these opportunities, in turn, can cause additional risks, as shown in column 3. In other words, risk mitigation strategies that are designed to take advantage of an opportunity could create another risk event that is more severe. As an example, working overtime could save you $15,000 by compressing the schedule. But if the employees make more mistakes on overtime, retesting may be required, additional materials may need to be purchased, and a schedule slippage could well occur, thus causing a loss of $100,000. Therefore, is it worth risking a loss of $100,000 to save $15,000?

To answer this question, we can use the concept of expected value, assuming we can determine the probabilities associated with mistakes being made and the cost of the mistakes. Without any knowledge of these probabilities, the actions taken to achieve the opportunities would be dependent upon the project manager's tolerance for risk.

Most project management professionals seem to agree that the most serious risks, and the ones about which we seem to know the least, are the technical risks.

Dependencies between Risks TABLE 11-6. RISK INTERDEPENDENCES


• Work overtime

• Add resources

• Arrange for parallel work

• Hire low cost resources

• Outsource critical work


• Schedule compression

• Schedule compression

• Schedule compression

• Schedule compression and lower cost

• Lower cost and schedule compression


• More mistakes; higher cost and longer schedule

• Higher cost and learning curve shift

• Rework and higher costs

• Unhappy customer and no follow-on work

• More mistakes and longer time period

• Contractor possesses critical knowledge at your expense

The worst situation is to have multiple technical risks that interact in an unpredictable or unknown manner.

As an example, assume you are managing a new product development project. Marketing has provided you with two technical characteristics that would make the product highly desirable in the marketplace. The exact relationship between these two characteristics is unknown. However, your technical subject matter experts have prepared the curve shown in Figure 11-15. According to the curve, the two characteristics may end up moving in opposite directions. In other words, maximizing one characteristic may require degradation in the second characteristic.

Working with marketing, you prepare the specification limits according to characteristic B in Figure 11-15. Because these characteristics interact in often un-

Desirable re tur a e Fe t ct duc o Pro






FIGURE 11-15. Interacting risks.


Product Feature B


FIGURE 11-15. Interacting risks.




Type of

Where Time




Is Invested

Is Invested

Are Used


• Back-end


• Senior management


and key players only




• Front-end


• Stakeholders




• Suppliers


• Customers

Value added

known ways, the specification limit on characteristic B may force characteristic A into a region that would make the product less desirable to the ultimate consumer.

Although project management methodologies provide a framework for risk management and the development of a risk management plan, it is highly unlikely that any methodology would be sophisticated enough to account for the identification of technical dependency risks. The time and cost associated with the identification, quantification, and handling of technical risk dependencies could severely tax the project financially.

Another critical interdependency is the relationship between change management and risk management, both of which are part of the singular project management methodology. Each risk management strategy can results in changes that generate additional risks. Risks and changes go hand in hand, which is one of the reasons companies usually integrate risk management and change management together into a singular methodology. Table 11-7 shows the relationship between managed and unmanaged changes. If changes are unmanaged, then more time and money is needed to perform risk management. And what makes the situation even worse is that higher salaried employees and additional time is required to assess the additional risks resulting from unmanaged changes. Managed changes, on the other hand, allows for a lower cost risk management plan to be developed.

Project management methodologies, no matter how good, cannot accurately define the dependencies between risks. It is usually the responsibility of the project team to make these determinations.



There exist four widely accepted risk response methods; assumption, reduction, transfer, and avoidance. Historically, most practitioners argue that the risk re sponse method selected is heavily biased toward the magnitude of the risk and the project manager's tolerance level for risk. While this may still be true, there are other factors that influence the risk response method selected, and many of these can be included as part of the project management methodology.

The potential rewards of selecting the appropriate risk response can influence the selection process. Figure 11-6 shows the risk-reward matrix. What is important to recognize in Figure 11-16 is that the risk-reward matrix is actually three-dimensional, with the third axis being the quality of resources required. Certain risk response actions, such as assumption or reduction, require that resources be consumed. The quality and availability of the resources required can influence the risk response selection process irrespective of the potential rewards. For example, if a company adopts a risk assumption approach on an R&D project, the rewards could be huge if patents are issued and licensing agreements follow. But this is predicated upon available, qualified resources. Without the appropriate available resources, the only response mechanisms remaining might be risk avoidance or risk transfer.

A second factor influencing the risk response method selected is the procedural documentation requirements of the project management methodology. This appears in Figure 11-17. Project management methodologies that are based on policies and procedures are very rigid. Most good methodologies today are based upon guidelines that provide the project manager with significantly more flexibility in decision-making.

This flexibility (i.e., use of guidelines) can affect the risk response method selected. Although no empirical data exists as yet to support this, there appears a

FIGURE 11-16. The risk-reward matrix.

Rigid Policies/ Procedures

Rigid Policies/ Procedures




Tolerance for Risk

FIGURE 11-17. Which method to use?

tendency for project managers to accept higher levels of risk if the project manager is given more freedom in decision-making. On the other hand, the rigidity of policies and procedures generally allows for lower levels of risk acceptance and project managers seem to prefer avoidance. As risk management grows, more research will be expected in this area.


General strategic planning is never accomplished only once. It must be reexamined over and over again as requirements change and new information appears. The same holds true for strategic planning for project management. As more and more of these problem areas are identified internally from lessons learned files and externally in published articles, some of these often overlooked problems will be corrected.

0 0

Post a comment