5.0 INTRODUCTION

Companies that have become extremely successful in project management have done so by performing strategic planning for project management. These companies are not happy with just matching the competition. Instead, they opt to exceed the performance of their competitors. To do this on a continuous basis requires processes and methodologies that promote continuous rather than sporadic success.

Figure 5-1 identifies the hexagon of excellence. The six components identified in the hexagon of excellence are the areas where the companies excellent in project management exceed their competitors. Each of these six areas is discussed in Chapters 5 to 10. We begin with integrated processes.

5.1 UNDERSTANDING INTEGRATED MANAGEMENT PROCESSES

As we discussed in Chapter 1, since 1985 several new management processes (e.g., concurrent engineering) have supported the acceptance of project management. The most important complementary management processes and the years they appeared to be integrated into project management are listed next. It should be understood that many of these processes were introduced years before they were integrated into project management processes.

• 1985: Total quality management (TQM)
• 1990: Concurrent engineering
• 1992: Employee empowerment and self-directed teams
• 1993: Reengineering
• 1994: Life-cycle costing
• 1995: Change management
• 1996: Risk management
• 1997–1998: Project offices and centers of excellence
• 1999: Colocated teams
• 2000: Multinational teams
• 2001: Maturity models
• 2002: Strategic planning for project management
• 2003: Intranet status reporting
• 2004: Capacity-planning models
• 2005: Six Sigma integration with project management
• 2006: Virtual project management teams
• 2007: Lean/agile project management
• 2008: Knowledge/best practices libraries
• 2009: Project management business process certification
• 2010: Managing complex projects
• 2011: Governance by committees
• 2012: Competing constraints including a value component
• 2013: Advances in metrics management and dashboard reporting systems
• 2014: Value-driven project management
• 2015: Global project management including the management of cultural differences
• 2016–2017: Merger and acquisition project management growth

The integration of project management with these other management processes is key to achieving sustainable excellence. Not every company uses every process all the time. Companies choose the processes that work best for them. However, whichever processes are selected, they are combined and integrated into the project management methodology. Earlier we stated that companies with world-class methodologies try to employ a single, standard methodology based on integrated processes. This includes business processes as well as project management–related processes.

As each of these integrated processes undergoes continuous improvement efforts, so does the project management methodology that uses them. Best practices libraries and knowledge repositories contain best practices on the integrated processes as well as the overall project management methodology.

The ability to integrate processes is based on which processes the company decides to implement. For example, if a company implemented a stage-gate model for project management, the company might find it an easy task to integrate new processes, such as concurrent engineering. The only precondition would be that the new processes were not treated as independent functions but were designed from the onset to be part of a project management system already in place. The four-phase model used by the General Motors Powertrain Group (Chapter 4, Section 4.22) and the PROPS model used at Ericsson Telecom AB (Chapter 4, Section 4.23) readily allow for the assimilation of additional business and management processes.

Earlier we stated that project managers today are viewed as managing part of a business rather than just a project. Therefore, project managers must understand the business and the processes to support the business as well as the processes to support the project. This chapter discusses some of the management processes listed and how the processes enhance project management. Then it looks at how some of the integrated management processes have succeeded using actual case studies.

5.2 EVOLUTION OF COMPLEMENTARY PROJECT MANAGEMENT PROCESSES

Since 1985, several new management processes have evolved in parallel with project management. Of these processes, TQM and concurrent engineering may be the most relevant. Agile and Scrum also have a significant impact and will be discussed later in this book (Chapter 15). Companies that reach excellence are the quickest to recognize the synergy among the many management options available today. Companies that reach maturity and excellence the quickest are those that recognize that certain processes feed on one another. As an example, consider the seven points listed below. Are these seven concepts part of a project management methodology?

1. Teamwork
2. Strategic integration
3. Continuous improvement
4. Respect for people
5. Customer focus
6. Management by fact
7. Structured problem solving

These seven concepts are actually the basis of Sprint’s TQM process. They could just as easily have been facets of a project management methodology.

During the 1990s, Kodak taught a course entitled “Quality Leadership.” The five principles of Kodak’s quality leadership program included:

• Customer Focus
• “We will focus on our customers, both internal and external, whose inputs drive the design of products and services. The quality of our products and services is determined solely by these customers.”

• Management Leadership
• “We will demonstrate, at all levels, visible leadership in managing by these principles.”

• Teamwork
• “We will work together, combining our ideas and skills to improve the quality of our work. We will reinforce and reward quality improvement contributions.”

• Analytical Approach
• “We will use statistical methods to control and improve our processes. Data-based analyses will direct our decisions.”

• Continuous Improvement
• “We will actively pursue quality improvement through a continuous cycle that focuses on planning, implementing, and verifying of improvements in key processes.”

Had we looked at just the left columnAU: DOES “LEFT COLUMN” REFER TO THE 5 PRINCIPLES ABOVE?"?>, we could argue that these are the principles of project management as well.

Figure 5-2 shows what happens when an organization does not integrate its processes. The result is totally uncoupled processes. Companies with separate methodologies for each process may end up with duplication of effort, possibly duplication of resources, and even duplication of facilities. Although there are several processes in Figure 5-2, we focus on project management, TQM, and concurrent engineering only.

As companies begin recognizing the synergistic effects of putting several of these processes under a single methodology, the first two processes to become partially coupled are project management and TQM, as shown in Figure 5-3. As the benefits of synergy and integration become apparent, organizations choose to integrate all of these processes, as shown in Figure 5-4.

Excellent companies are able to recognize the need for new processes and integrate them quickly into existing management structures. During the early 1990s, integrating project management with TQM and concurrent engineering was emphasized. Since the middle 1990s, two other processes have become important in addition: risk management and change management. Neither of these processes is new; it’s the emphasis that’s new.

During the late 1990s, Steve Gregerson, formerly vice president for product development at Metzeler Automotive Profile System, described the integrated processes in its methodology:

Our organization has developed a standard methodology based on global best practices within our organization and on customer requirements and expectations. This methodology also meets the requirements of ISO 9000. Our process incorporates seven gateways that require specific deliverables listed on a single sheet of paper. Some of these deliverables have a procedure and in many cases a defined format. These guidelines, checklists, forms, and procedures are the backbone of our project management structure and also serve to capture lessons learned for the next program. This methodology is incorporated into all aspects of our business systems, including risk management, concurrent engineering, advanced quality planning, feasibility analysis, design review process, and so on.¹

Another example of integrated processes was the methodology employed by Nortel. During the late 1990s, Bob Mansbridge, then vice president, supply chain management at Nortel Networks, stated:

Nortel Networks project management is integrated with the supply chain. Project management’s role in managing projects is now well understood as a series of integrated processes within the total supply chain pipeline. Total quality management (TQM) in Nortel Networks is defined by pipeline metrics. These metrics have resulted from customer and external views of “best-in-class” achievements. These metrics are layered and provide connected indicators to both the executive and the working levels. The project manager’s role is to work with all areas of the supply chain and to optimize the results to the benefit of the project at hand. With a standard process implemented globally, including the monthly review of pipeline metrics by project management and business units, the implementation of “best practices” becomes more controlled, measurable, and meaningful.²

The importance of integrating risk management is finally being recognized. According to Frank T. Anbari, professor of project management, Drexel University:

By definition, projects are risky endeavors. They aim to create new and unique products, services, and processes that did not exist in the past. Therefore, careful management of project risk is imperative to repeatable success. Quantitative methods play an important role in risk management. There is no substitute for profound knowledge of these tools.³

Risk management has been a primary focus among health care organizations for decades, for obvious reasons, as well as among financial institutions and the legal profession. Today, in organizations of all kinds, risk management keeps us from pushing our problems downstream in the hope of finding an easy solution later on or of the problem simply going away by itself. Change management as a complement to project management is used to control the adverse effects of scope creep: increased costs (sometimes double or triple the original budget) and delayed schedules. With change management processes in place as part of the overall project management system, changes in the scope of the original project can be treated as separate projects or subprojects so that the objectives of the original project are not lost.

Today, almost all companies integrate five main management processes (see Figure 5-5):

1. Project management
2. Total quality management
3. Risk management
4. Concurrent engineering
5. Change management

Self-managed work teams, employee empowerment, reengineering, and life-cycle costing are also combined with project management in some companies. We briefly discuss these less widely used processes after we discuss the more commonly used ones.

5.3 ZURICH AMERICA INSURANCE COMPANY

One of the benefits of having integrated processes is that it allows for more comprehensive and realistic contingency planning. Kathleen Cavanaugh of Zurich North America, PMO Lead, states:

As we know, simply put, the goal of all PMOs [project management offices] is to deliver projects on time and on budget. There is increased scrutiny placed on projects these days and many companies have enacted a protective governance gauntlet to help ensure the right projects come to fruition. With the time to market push/shove, it is easy for projects budgets and end dates to be estimated, even “promised” too soon much to the unease of the project manager. To help alleviate this potential heartbreak, the IT [information technology] PMO at Zurich American Insurance Company has implemented a project contingency process for both duration and dollars.

The contingency process helps to mitigate the risk of known unknowns within the scope of a project. Since we are part of the global Zurich Financial Services Group, we have a rather strict governance process that takes time and money to navigate. Once you make it through the gauntlet, you don’t really want to go back for reapprovals, date extension authorizations, etc., so, proper planning for risks and project changes is imperative.

The contingency process uses a determination matrix that considers particular risk factors such as resources and technology complexity just to name a couple. It is designed to help the project manager assign the appropriate amount of contingency needed for both dollars and duration. The concept is nothing new but is still not widely accepted as a necessity.

The goal is not only to protect us from time-consuming project governance submissions but also to move away from padding individual estimates. Before this contingency approach was introduced, some project managers buried contingency within their estimates. The major disadvantage of this is that because the contingency is “hidden,” there is no systematic process to release funds back into the project funding pool as risks lessen throughout the project. Now contingency is kept separate in the project plan so that we can have better insight into where and why original estimates were off. Only then can we find the root cause and improve on the estimating approach.

One important thing to note is that customers take part in determining the need for contingency so they have a good understanding of why it is so critical to the success of the project. The process makes contingency transparent, and once customers understand that contingency dollars cannot be used without their acknowledgment, they are more open to understanding the inherent changes that occur during the life of a project.

Contingency should be actively managed as the project progresses. Each month when project risks are reassessed and risk probability decreases, the amount of contingency should be adjusted accordingly in both budget and schedule. It is expected that contingency would be released from the project if it is determined to no longer be needed based on the updated risk assessment. This allows money to be available for other efforts in the company.

To summarize, the bullet points below are an outline of the steps taken to effectively use the contingency process.

• Plan: The IT project manager works with the business project manager and project team using the determination matrix to calculate the appropriate contingency percentage when the project is ready to go for full funding.
• Document/Communicate: The project manager updates the project plan and usage log to document and communicate the contingency figures.
• Approve: The sponsor is responsible for providing sign-off before contingency is used.
• Manage: The project manager maintains the usage log as contingency is consumed and other contingency data is updated each month along with the risk assessment.
• Release: Contingency funds are released back into the project funding pool as risks decrease.

  Overall, this process addresses the age-old problem of project work starting before everything that needs to be known is known and gives project managers a fighting chance to deliver on time and on budget in this ever-changing environment. Because, after all, change happens.

5.4 TOTAL QUALITY MANAGEMENT

During the past three decades, the concept of TQM (and then Six Sigma) has revolutionized the operations and manufacturing functions of many companies. Companies have learned quickly that project management principles and systems can be used to support and administer TQM programs and vice versa. Ultimately excellent companies have completely integrated the two complementary systems.

The emphasis in TQM is on addressing quality issues in total systems. Quality, however, is never an end goal. TQM systems run continuously and concurrently in every area in which a company does business. Their goal is to bring to market products of better and better quality and not just of the same quality as last year or the year before.

TQM was founded on the principles advocated by W. Edwards Deming, Joseph M. Juran, and Phillip B. Crosby. Deming is famous for his role in turning postwar Japan into a dominant force in the world economy. TQM processes are based on Deming’s simple plan–do–check–act cycle.

The cycle fits completely with project management principles. To fulfill the goals of any project, first you plan what you’re going to do, then you do it. Next, you check on what you did. You fix what didn’t work, and then you execute what you set out to do. But the cycle doesn’t end with the output. Deming’s cycle works as a continuous-improvement system too. When the project is complete, you examine the lessons learned in its planning and execution. Then you incorporate those lessons into the process and begin the plan–do–check–act cycle all over again on a new project.

TQM also is based on three other important elements: customer focus, process thinking, and variation reduction. Does that remind you of project management principles? It should. The plan–do–check–act cycle can be used to identify, validate, and implement best practices in project management.

In the mid-1990s, during a live videoconference on the subject titled “How to Achieve Maturity in Project Management,” Dave Kandt, then group vice president for quality and program management at Johnson Controls, commented on the reasons behind the company’s astounding success:

We came into project management a little differently than some companies. We have combined project management and TQC [total quality control] or total quality management. Our first design and development projects in the mid-1980s led us to believe that our functional departments were working pretty well separately, but we needed to have some systems to bring them together. And, of course, a lot of what project management is about is getting work to flow horizontally through the company. What we did first was to contact Dr. Norman Feigenbaum, who is the granddaddy of TQC in North America, who helped us establish some systems that linked together the whole company. Dr. Feigenbaum looked at quality in the broadest sense: quality of products, quality of systems, quality of deliverables, and, of course, the quality of projects and new product launches. A key part of these systems included project management systems that addressed product introduction and the product introduction process. Integral to this was project management training, which was required to deliver these systems.

We began with our executive office, and once we had explained the principles and philosophies of project management to these people, we moved to the management of plants, engineering managers, analysts, purchasing people, and of course project managers. Only once the foundation was laid did we proceed with actual project management and with defining the role and responsibility so that the entire company would understand their role in project management once these people began to work. Just the understanding allowed us to move to a matrix organization and eventually to a stand-alone project management department. So how well did that work? Subsequently, since the mid-1980s, we have grown from two or three projects to roughly 50 in North America and Europe. We have grown from two or three project managers to 35. I don’t believe it would have been possible to manage this growth or bring home this many projects without project management systems and procedures and people with understanding at the highest levels of the company.

In the early 1990s, we found that we were having some success in Europe, and we won our first design and development project there. And with that project, we carried to Europe not only project managers and engineering managers who understood these principles but also the systems and training we incorporated in North America. So, we had a company-wide integrated approach to project management. What we’ve learned in these last 10 years that is the most important to us, I believe, is that you begin with the systems and the understanding of what you want the various people to do in the company across all functional barriers, then bring in project management training, and last implement project management.

Of course, the people we selected for project management were absolutely critical, and we selected the right people. You mentioned the importance of project managers understanding business, and the people that we put in these positions are very carefully chosen. Typically, they have a technical background, a marketing background, and a business and financial background. It is very hard to find these people, but we find that they have the necessary cross-functional understanding to be able to be successful in this business.

At Johnson Controls, project management and TQM were developed concurrently. Kandt was asked during the same videoconference whether companies must have a solid TQM culture in place before they attempt the development of a project management program. He said:

I don’t think that is necessary. The reason why I say that is that companies like Johnson Controls are more the exception than the rule of implementing TQM and project management together. I know companies that were reasonably mature in project management and then ISO 9000 came along, and because they had project management in place in a reasonably mature fashion, it was an easier process for them to implement ISO 9000 and TQM. There is no question that having TQM in place at the same time or even first would make it a little easier, but what we’ve learned during the recession is that if you want to compete in Europe and you want to follow ISO 9000 guidelines, TQM must be implemented. And using project management as the vehicle for that implementation quite often works quite well.

There is also the question of whether successful project management can exist within the ISO 9000 environment. According to Kandt:

Not only is project management consistent with ISO 9000, a lot of the systems that ISO 9000 require are crucial to project management’s success. If you don’t have a good quality system, engineering change system, and other things that ISO requires, the project manager is going to struggle in trying to accomplish and execute that project. Further, I think it’s interesting that companies that are working to install and deploy ISO 9000, if they are being successful, are probably utilizing project management techniques. Each of the different elements of ISO requires training, and sometimes the creation of systems inside the company that can all be scheduled, teams that can be assigned, deliverables that can be established, tracked, and monitored, and reports that go to senior management. That’s exactly how we installed TQC at Johnson Controls, and I see ISO 9000 as having a very similar thrust and intent.

5.5 CONCURRENT ENGINEERING

The need to shorten product development time has always plagued U.S. companies. During favorable economic conditions, corporations have deployed massive amounts of resources to address the problem of long development times. During economic downturns, however, not only are resources scarce, but time becomes a critical constraint. Today, the principles of concurrent engineering have been almost universally adopted as the ideal solution to the problem.

Concurrent engineering requires performing the various steps and processes in managing a project in tandem rather than in sequence. This means that engineering, research and development, production, and marketing all are involved at the beginning of a project, before any work has been done. That is not always easy, and it can create risks as the project is carried through. Superior project planning is needed to avoid increasing the level of risk later in the project. The most serious risks are delays in bringing product to market and costs when rework is needed as a result of poor planning. Improved planning is essential to project management, so it is no surprise that excellent companies integrate concurrent engineering and project management systems.

Chrysler (now Fiat Chrysler) Motors used concurrent engineering with project management to go from concept to market with the Dodge Viper sports car in less than three years. Concurrent engineering may well be the strongest driving force behind the increased acceptance of modem project management.

5.6 RISK MANAGEMENT

Risk management is an organized means of identifying and measuring risk and developing, selecting, and managing options for handling those risks. Throughout this book, we have emphasized that tomorrow’s project managers will need superior business skills in assessing and managing risk. This includes both project risks and business risks. In the past, project managers were not equipped to quantify risks, respond to risks, develop contingency plans, or keep lessons-learned records. They were forced to go to senior managers for advice on what to do when risky situations developed. Now senior managers are empowering project managers to make risk-related decisions, and doing that requires project managers to have solid business skills as well as technical knowledge.

Preparing a project plan is based on history. Simply stated: What have we learned from the past? Risk management encourages us to look at the future and anticipate what can go wrong and then to develop contingency strategies to mitigate these risks.

We have performed risk management in the past, but only financial and scheduling risk management. To mitigate a financial risk, we increased the project’s budget. To mitigate a scheduling risk, we added more time to the schedule. But in the 1990s, technical risks became critical. Simply adding into the plan more time and money is not the solution to mitigate technical risks. Technical risk management addresses two primary questions:

1. Can we develop the technology within the imposed constraints?
2. If we do develop the technology, what is the risk of obsolescence, and when might we expect it to occur?

To address these technical risks, effective risk management strategies are needed based on technical forecasting. On the surface, it might seem that making risk management an integral part of project planning should be relatively easy. Just identify and address risk factors before they get out of hand. Unfortunately, the reverse is likely to be the norm, at least for the foreseeable future.

For years, companies provided lip service to risk management and adopted the attitude toward risk that it is something we should simply learn to live with. Very little was published on how to develop a structure risk management process. The disaster with the space shuttle Challenger in January 1986 was a great awakening on the importance of effective risk management.⁴

Today risk management has become so important that companies are establishing separate internal risk management organizations. However, many companies have been using risk management functional units for years, and yet this concept has gone unnoticed. An overview of the program management methodology of the risk management department of an international manufacturer headquartered in Ohio follows. This department has been in operation for approximately 25 years.

The risk management department is part of the financial discipline of the company and ultimately reports to the treasurer, who reports to the chief financial officer. The overall objective of the department is to coordinate the protection of the company’s assets. The primary means of meeting that objective is eliminating or reducing potential losses through loss prevention programs. The department works very closely with the internal environmental health and safety department. Additionally, it utilizes outside loss control experts to assist the company’s divisions in loss prevention.

One method employed by the company to insure the entire corporation’s involvement in the risk management process is to hold its divisions responsible for any specific losses up to a designated self-insured retention level. If there is a significant loss, the division must absorb it and its impact on their bottom-line profit margin. This directly involves the divisions in both loss prevention and claims management. When a claim does occur, risk management maintains regular contact with division personnel to establish protocol on the claim and reserves and ultimate resolution.

The company does purchase insurance above designated retention levels. As with the direct claims, the insurance premiums are allocated to its divisions. These premiums are calculated based upon sales volume and claim loss history, with the most significant percentage being allocated to claim loss history.

Each of the company’s locations must maintain a business continuity plan for its site. This plan is reviewed by risk management and is audited by the internal audit and environmental health and safety department.

Risk management is an integral part of the corporation’s operations as evidenced by its involvement in the due diligence process for acquisitions or divestitures. It is involved at the onset of the process, not at the end, and provides a detailed written report of findings as well as an oral presentation to group management.

Customer service is part of the company’s corporate charter. Customers served by risk management are the company’s divisions. The department’s management style with its customers is one of consensus building and not one of mandating. This is exemplified by the company’s use of several worker’s compensation third-party administrators (TPAs) in states where it is self-insured. Administratively, it would be much easier to utilize one nationwide TPA. However, using strong regional TPAs with offices in states where divisions operate provides knowledgeable assistance with specific state laws to the divisions. This approach has worked very well for this company that recognizes the need for the individual state expertise.

The importance of risk management is now apparent worldwide. The principles of risk management can be applied to all aspects of a business, not just projects. Once a company begins using risk management practices, it can always identify other applications for those processes.

For multinational companies that are project-driven, risk management takes on paramount importance. Not all companies, especially in undeveloped countries, have an understanding of risk management or its importance. These countries sometimes view risk management as an overmanagement expense on a project.

Consider the following scenario. As your organization gets better and better at project management, your customers begin giving you more and more work. You’re now getting contracts for turnkey projects or complete-solution projects. Before, all you had to do was deliver the product on time and you were through. Now you are responsible for project installation and startup as well, sometimes even for ongoing customer service. Because the customers no longer use their own resources on the project, they worry less about how you’re handling your project management system.

Alternatively, you could be working for third-world clients who haven’t yet developed their own systems. One hundred percent of the risk for such projects is yours, especially as projects grow more complex. (See Figure 5-6.) Welcome to the twenty-first century!

One subcontractor received a contract to install components in a customer’s new plant. The construction of the plant would be completed by a specific date. After construction was completed, the contractor would install the equipment, perform testing and then startup. The subcontractor would not be allowed to bill for products or services until after a successful startup. There was also a penalty clause for late delivery.

The contractor delivered the components to the customer on time, but the components were placed in a warehouse because plant construction had been delayed. The contractor now had a cash flow problem and potential penalty payments because of external dependencies that sat on the critical path. In other words, the contractor’s schedule was being controlled by actions of others. Had the project manager performed business risk management rather than just technical risk management, these risks could have been reduced.

For the global project manager, risk management takes on a new dimension. What happens if the culture in the country with which you are working neither understands risk management nor has any risk management process? What happens if employees are afraid to surface bad news or identify potential problems? What happens if the project’s constraints of time, cost, and quality/performance are meaningless to the local workers?

5.7 WÄRTSILÄ: THE NEED FOR PROACTIVE RISK MANAGEMENT⁵

Proactive Project Risk Management in Wärtsilä Power Plant Projects

At Wärtsilä, project risk management has traditionally been much about identifying and planning. We have seen that this now needs to be expanded to cover reflection and proactive action taking in today’s complex projects. Risks need to be tackled up front before they occur and potentially jeopardize project objectives. Here we briefly present what we have done in this respect.

How uncertainty and risk are handled in projects very much depends on experience. It can be said that many project managers deal with risk and uncertainty only as a result of what they are actually experiencing in their projects. Experienced project managers, however, can recognize risks far ahead before they become issues. Likewise, opportunities and positive uncertainties can be recognized more easily by experienced project managers. However, the recognition of opportunities is not only restricted to experience, since a willingness to take risks is also required. In many cases, a change of mind-set is required from project managers to be able to accomplish this.

As large projects are becoming increasingly complex to manage today, it is essential that the project manager has enough experience to have an accurate perception of what is involved. Besides the project itself, it is of huge importance to know about the location, the customer, and the environment. Failure to have the knowledge or experience about these issues in advance will cause major problems, making the project more complex and challenging than necessary. In order to avoid such pitfalls, it is important to use the combined knowledge, experience, and creativity of the whole project team. Although risk management is the project manager’s responsibility, it is not solely his or her task. The whole project team needs to share this responsibility.

This brings us to the importance of having a lessons-learned database with information that has been shared among the project teams. Such a database is an important resource for a new project manager or other team member joining the force. Likewise, when a project team accepts a new project type or a project in a totally new location, it is beneficial to be able to access the knowledge about similar cases. In light of this, a lessons-learned database is being implemented where all this knowledge and experience can be shared.

We have seen that knowledge and experience play an important role in managing risk, uncertainty, and other factors in projects. However, proactive risk management is not always easy to implement, since it depends on so many people’s different perceptions of it. A lot of communication is needed in order to gain a common understanding of what the organization needs regarding risk and uncertainty as well as a clear understanding of the potential benefits they bring into the organization. Proactive risk management is not only about identifying, qualifying, and quantifying the risks; it is much more. The utilization of the risk management process is all about having the maturity to use the previously learned experience and knowledge to prevent risks from occurring in the first place, as well as the confidence to take the necessary actions to encourage positive opportunities to develop.

A project team needs a tool for project risk management where upcoming events, both foreseen and unforeseen, can be continuously followed. A risk management process tool does not need to be complex. The most important aspect is the way it is utilized in the organization. We see that in this case, the statement “The simpler the better” describes quite well what is needed.

The proactive risk management process taken into use at Wärtsilä consists of three different phases. (See Figure 5-7.) First a project classification should be done to define the complexity of the project. Thereafter, the risk process itself will be managed as a continuous process throughout the whole project life cycle. In addition, lessons learned should be recorded on risks where the actions taken significantly differed from the planned response. At Wärtsilä we have implemented this entire process in one common project management tool used by all project management teams and management.

The classification process will provide important information for the risk identification steps. The intent of the process is to encourage project managers to think about the project and define where project complexity is situated and provide an input for the risk management process identification. It must describe the project from an objective point of view. One of the core added values that project classification brings to project management is defining needed resources for resource allocation.

The risk management process basically also is one continuous process. All the same elements that were used in the classification process are implemented in this process. The traditional risk management process described in PMBOK Guide (2008) has been used as the basis for the new risk management process.

In order for a proactive risk management process to be successful, it is vital that the project team makes full use of it. Ignorance of risks and uncertainties will cause large problems within project management when they materialize unexpectedly and become harmful issues.

A good communication system needs to be created in order for the project teams to implement a uniform risk management process. In addition, training should be given on how to use the risk management process in order to improve the understanding of how the proactive risk process can be utilized and to gain an appreciation as to why it is so important.

5.8 INDRA: WHEN A RISK BECOMES REALITY (ISSUE MANAGEMENT)⁶

In a company like Indra, with thousands of active projects geographically distributed, a solid and continuous risk management practice is vital. This is shown in Figure 5-8. Actions that might contain the impact that risks can have on the results of the project are planned and monitored throughout the project life cycle.

The percentage of projects with risk plans and risk registers is very high in Indra. However, we at the corporate project management office (PMO) noted that these high figures didn’t prevent some risks from happening; even worse, other unknown-unknown risks showed up as issues that project managers haven’t been able to identify in their plans.

However, an issue is not in the future; it is now already affecting project milestones or schedule, or certain work breakdown structure elements, or the committed budget, or the quality level of the project. For that reason, an issue usually demands immediate response, and it must be resolved as quickly and effectively as possible to avoid affecting other areas of the project.

We think that analyzing the relationship between risks and issues is essential for an integrated approach to risk management. By a premortem review of risks and their related issues, by sorting and classifying them, and by analyzing why those risks were not well addressed in earlier planning stages, we seek to understand what caused those risks and to determine earlier risk screening criteria.

In a second stage, we need to know the actual effects on the project of the risk and whether the solutions proposed to contain the effects have been effective. That will allow us to create a database and to identify some lessons learned to help us to identify issue-prone risks early on and prevent them from appearing in future projects.

Not all issues are equal or affect the organization in the same way. Their impacts depend on the project size or volume, its internal or external visibility, project complexity, variances on initial economic forecast, time needed to put the project on track, or the issues’ impact on the image of the company.

Having all those considerations up front, we have decided to focus our efforts on the projects with more critic issues. Those are considered projects that require close surveillance, and for those projects, key points are identifying the source of the issue, its immediate effects, and the follow-up of the action plan. To allow this we created a new functionality in our project management information system (PMIS) called issue registry. This is embedded within our PMIS issue management module.

The issue registry works like this: When a project management office or a user responsible for project control analyzes a project and detects it is having serious problems, the project manager is required to complete detailed information in the Issue Registry module. This can be triggered automatically through a red alert in the PMIS.(See Figure 5-9.)

The project manager must describe existing issues in the project, the action plans to cope with them, and the recovery target that must be obtained to get the project back on track. Once fulfilled, and to avoid this being a static snapshot of the project, the project manager is expected to update the information every reporting period from that moment on, indicating action plan updates and project status with regard to the initial targets.

What we intend to achieve with the Issue Registry? We want to focus our attention and our efforts on:

• Detecting which problems and issues have emerged from previously identified risks and which have not
• Getting a homogeneous classification and typification of projects that were seriously affected by issues
• Tracking the effectiveness of the issue action plans
• Automated and systematic reporting to business management on those issues and their projects from different perspectives (business unit, solution, type of project, geographic location, etc.)

Historically the efforts of our organization had been focused on the management of risks, leaving the management of issues and problems as a secondary process, not connected with risk management. Issue management was more dependent on the involvement and proactiveness of the project manager; for that reason, it was approached heterogeneously, usually in an internal project context and without a close monitoring and follow-up by the organization, as it was the case with risk management.

The registration and follow-up of projects and the traceability between risks and issues can be made from the PMIS. To reverse actual dynamics, we will take a first step by learning from issues and problems that have already occurred; based on that analysis, in a second stage we will focus on prevention of recurrent issues—those that have been registered, diagnosed, and solved by other projects managers. This invaluable information will enable project managers to learn from others’ experiences.

Inside the problem is the solution. Only by knowing the problem can we solve and avoid it.

5.9 THE FAILURE OF RISK MANAGEMENT

There are numerous reasons why risk management can fail. Typical reasons might include:

• The inability to
  • perform risk management effectively
  • identify the risks
  • measure the uncertainty of occurrence
  • predict the impact, whether favorable or unfavorable
• Having an insufficient budget for risk management work
• Having team members who do not understand the importance of risk management
• Fear that identification of the true risks could result in project cancellation
• Fear that whoever identifies critical risks will get unfavorable recognition
• Peer pressure from colleagues and superiors who want to see a project completed regardless of the risks

All of these failures occur during project execution. We seem to understand these failures and can correct them with proper education and budget allocations for risk management activities. But perhaps the worst failures occur when people refuse to even consider risk management because of some preconceived notion about its usefulness or importance to the project. David Dunham discusses some of the reasons why people avoid risk management on new product development (NPD) projects.

Discussing risk in new product development certainly seems to be a difficult thing to do. Despite the fact that the high-risk nature of new product development is built into the corporate psyche, many corporations still take a fatalistic approach toward managing the risk. Reasons for not being anxious to dwell on risk differ depending on the chair in which you are sitting.

Program Manager

• Spending time on risk assessment and management is counter to the action culture of many corporations. “Risk management does not create an asset,” to quote one executive.
• Management feels that the learning can/should be done in the market.

Project Manager

• There is a natural aversion among developers to focusing on the downside.
• Highlighting risk is counterintuitive for development teams who want to promote the opportunity when competing for NPD funding.⁷

5.10 DEFINING MATURITY USING RISK MANAGEMENT

For years, project management maturity was measured by how frequently we were able to meet a project’s triple constraints of time, cost, and performance or scope. Today, we are beginning to measure maturity in components, such as the areas of knowledge in the PMBOK Guide. Maturity is now measured in stages and components, such as how well we perform scope management, time management, risk management, and other areas of knowledge. Gregory Githens believes that the way we handle risk management can be an indicator of organizational maturity.

Some firms have more capability to manage risk well, and these firms are the most consistent in their growth and profitability. Perhaps the simplest test for examining risk management maturity is to examine the level of authority given to the NPD program [project] manager: If authority is high, then the organization is probably positioning itself well to manage risks, but if authority is low, then the blinders may be on. Another test is the use of checklists: if ticking off a checklist is the sole company response to risk, then organizational maturity is low. Risk management provides an excellent lens by which to evaluate a firm’s ability to integrate and balance strategic intent with operations.

Many firms ignore risk management because they have not seen the need for it. They perceive their industry as stable and mostly focus on their competitive rivals and operational challenges. . . . By addressing risk at the project level, you encourage the organization to surface additional strategic concerns.

Top NPD firms have a sophisticated capability for risk management, and they will “book” a project plan, pay attention to the details of product scope and project scope, use risk management tools such as computer simulations and principle-based negotiation, and document their plans and assumptions. These more mature firms are the ones that will consider risk in establishing project baselines and contracts. For example, Nortel uses a concept called “out of bounds” that provides the NPD program managers with the freedom to make trade-offs in time, performance, cost and other factors. Risk analysis and management is an important tool.

Less mature firms typically establish a due date and pay attention to little else (and in my experience, this is the majority of firms). Firms that use the decision rule “Hit the launch date” default to passive acceptance—hiding the risk instead of managing it. Firefighting and crisis management characterize their organizational culture, and their strategic performance is inconsistent. These firms are like the mythological character Icarus: They fly high but come crashing down because they ignored easily recognizable risk events.⁸

5.11 BOEING AIRCRAFT COMPANY

As companies become successful in project management, risk management becomes a structured process that is performed continuously throughout the life cycle of the project. The two most common factors supporting the need for continuous risk management are how long the project lasts and how much money is at stake. For example, consider Boeing’s aircraft projects. Designing and delivering a new plane might require 10 years and a financial investment of more than $15 billion.

From an academic perspective, Table 5-1 shows the characteristics of risks at the Boeing Aircraft Company. (The table does not mean to imply that risks are mutually exclusive of each other, nor does it imply that these are the only risks.) New technologies can appease customers, but production risks increase because the learning curve is lengthened with new technology compared to accepted technology. The learning curve can be lengthened further when features are custom designed for individual customers. In addition, the loss of suppliers over the life of a plane can affect the level of technical and production risk. The relationships among these risks require the use of a risk management matrix and continued risk assessment.

5.12 CHANGE MANAGEMENT

Companies use change management to control both internally generated changes and customer-driven changes in the scope of projects. Most companies establish a configuration control board or change control board to regulate changes. For customer-driven changes, the customer participates as a member of the configuration control board. The configuration control board addresses these four questions at a minimum:

1. What is the cost of the change?
2. What is the impact of the change on project schedules?
3. What added value does the change represent for the customer or end user?
4. What are the risks?

The benefit of developing a change management process is that it allows you to manage your customer. When your customer initiates a change request, you must be able to predict immediately the impact of the change on schedule, safety, cost, and technical performance. This information must be transmitted to the customer immediately, especially if your methodology is such that no further changes are possible because of the life-cycle phase you have entered. Educating your customer as to how your methodology works is critical in getting customer buy-in for your recommendations during the scope change process.

Risk management and change management function together. Risks generate changes that, in turn, create new risks. For example, consider a company in which the project manager is given the responsibility for developing a new product. Management usually establishes a launch date even before the project is started. Management wants the income stream from the project to begin on a certain date to offset development costs. Project managers view executives as their customers during new project development, but executives view the stockholders who expect a revenue stream from the new product as their customers. When the launch date is not met, surprises result in heads rolling, usually executive heads first.

In a previous edition of this book, we stated that Asea Brown Boveri had developed excellent processes for risk management, so it is understandable that it also has structured change management processes. In companies excellent in project management, risk management and change management occur continuously throughout the project life cycle. The impact on product quality, cost, and timing is continuously updated and reported to management as quickly as possible. The goal is always to minimize the number and extent of surprises.

5.13 OTHER MANAGEMENT PROCESSES

Employee empowerment and self-directed work teams took the business world by storm during the early 1990s. With growing emphasis on customer satisfaction, it made sense to empower those closest to the customer—the order service people, nurses, clerks, and so on—to take action in resolving customers’ complaints. A logical extension of employee empowerment is the self-managed work team. A self-directed work team is a group of employees with given day-to-day responsibility for managing themselves and the work they perform. This includes the responsibility for handling resources and solving problems.

Some call empowerment a basis for the next industrial revolution, and it is true that many internationally known corporations have established self-directed work teams. Such corporations include Lockheed-Martin, Honeywell, and Weyerhauser. Time will tell whether these concepts turn out to be a trend or only a fad.

Reengineering a corporation is another term for downsizing the organization with the (often unfortunate) belief that the same amount of work can be performed with fewer people, at lower cost, and in a shorter period of time. Because project management proposes getting more done in less time with fewer people, it seems only practical to implement project management as part of reengineering. It still is not certain that downsizing executed at the same time as the implementation of project management works, but project-driven organizations seem to consider it successful.

Life-cycle costing was first used in military organizations. Simply stated, life-cycle costing requires that decisions made during the research and development process be evaluated against the total life-cycle cost of the system. Life-cycle costs are the total cost of the organization for the ownership and acquisition of the product over its full life.