4.0 INTRODUCTION

In Chapter 1 we described the life-cycle phases for achieving maturity in project management. The fourth phase was the growth phase, which included the following:

• Establish life-cycle phases.
• Develop a project management methodology.
• Base the methodology upon effective planning.
• Minimize scope changes and scope creep.
• Select the appropriate software to support the methodology.

The importance of a good methodology cannot be overstated. Not only will it improve performance during project execution, but it will also allow for better customer relations and customer confidence. Good methodologies can also lead to sole-source or single-source procurement contracts.

Creating a workable methodology for project management is no easy task. One of the biggest mistakes made is developing a different methodology for each type of project. Another is failing to integrate the project management methodology and project management tools into a single process, if possible. When companies develop project management methodologies and tools in tandem, two benefits emerge: First, the work is accomplished with fewer scope changes. Second, the processes are designed to create minimal disturbance to ongoing business operations.

This chapter discusses the components of a project management methodology and some of the most widely used project management tools. Detailed examples of methodologies at work are also included.

4.1 EXCELLENCE DEFINED

Excellence in project management is often regarded as a continuous stream of successfully managed projects. Without a project management methodology, repetitive successfully completed projects may be difficult to achieve.

Today, everyone seems to agree somewhat on the necessity for a project management methodology. However, there is still disagreement on the definition of excellence in project management, the same way that companies have different definitions for project success. In this section, we discuss some of the different definitions of excellence in project management.

Some definitions of excellence can be quite simple and achieve the same purpose as complex definitions. According to a spokesperson from Motorola:

Excellence in project management can be defined as:

• Strict adherence to scheduling practices
• Regular senior management oversight
• Formal requirements change control
• Formal issue and risk tracking
• Formal resource tracking
• Formal cost tracking

A spokesperson from AT&T defined excellence in this way:

Excellence [in project management] is defined as a consistent Project Management Methodology applied to all projects across the organization, continued recognition by our customers, and high customer satisfaction. Also, our project management excellence is a key selling factor for our sales teams. This results in repeat business from our customers. In addition, there is internal acknowledgement that project management is value-added and a must have.

Doug Bolzman, Consultant Architect, PMP, ITIL expert at Hewlett-Packard, discusses his view of excellence in project management:

Excellence is rated, not by managing the pieces, but by understanding how the pieces fit together, support each other’s dependencies, and provide value to the business. If project management only does what it is asked to do, such as manage 300 individual projects in the next quarter, it is providing a low value-added function that basically is the “pack mule” that is needed, but only does what it is asked—and no more. Figures 4-1 and 4-2 demonstrate that if mapping project management to a company’s overall release management framework, each project is managed independently with the characteristics shown.

Using the same release framework and the same client requests, project management disciplines can understand the nature of the requirements and provide a valuable service to bundle the same types of requests (projects) to generate a forecast of the work, which will assist the company in balancing its financials, expectations, and resources. This function can be done within the PMO.

4.2 RECOGNIZING THE NEED FOR METHODOLOGY DEVELOPMENT

Simply having a project management methodology and following it do not lead to success and excellence in project management. The need for improvements in the system may be critical. External factors can have a strong influence on the success or failure of a company’s project management methodology. Change is a given in the current business climate, and there is no sign that the future will be any different. The rapid changes in technology that have driven changes in project management over the past two decades are not likely to subside. Another trend, the increasing sophistication of consumers and clients, is likely to continue, not go away. Cost and quality control have become virtually the same issue in many industries. Other external factors include rapid mergers and acquisitions and real-time communications.

Project management methodologies are organic processes and need to change as the organization changes in response to the ever-evolving business climate. Such changes, however, require that managers on all levels be committed to them and have a vision that calls for the development of project management systems along with the rest of the organization’s other business systems.

Today, companies are managing their business by projects. This is true for both non–project-driven and project-driven organizations. Virtually all activities in an organization can be treated as some sort of project. Therefore, it is only fitting that well-managed companies regard a project management methodology as a way to manage the entire business rather than just projects. Business processes and project management processes will be merged together as the project manager is viewed as the manager of part of a business rather than just the manager of a project.

Developing a standard project management methodology is not for every company. For companies with small or short-term projects, such formal systems may not be cost-effective or appropriate. However, for companies with large or ongoing projects, developing a workable project management system is mandatory.

For example, a company that manufactures home fixtures had several project development protocols in place. When it decided to begin using project management systematically, the complexity of the company’s current methods became apparent. The company had multiple system development methodologies based on the type of project. This became awkward for employees who had to struggle with a different methodology for each project. The company then opted to create a general, all-purpose methodology for all projects. The new methodology had flexibility built into it. According to one spokesman for the company:

Our project management approach, by design, is not linked to a specific systems development methodology. Because we believe that it is better to use a (standard) systems development methodology than to decide which one to use, we have begun development of a guideline systems development methodology specific for our organization. We have now developed prerequisites for project success. These include:

• A well-patterned methodology
• A clear set of objectives
• Well-understood expectations
• Thorough problem definition

During the late 1980s, merger mania hit the banking community. With the lowering of costs due to economies of scale and the resulting increased competitiveness, the banking community recognized the importance of using project management for mergers and acquisitions. The quicker the combined cultures became one, the less the impact on the corporation’s bottom line.

The need for a good methodology became apparent, according to a spokesperson at one bank:

The intent of this methodology is to make the process of managing projects more effective: from proposal to prioritization to approval through implementation. This methodology is not tailored to specific types or classifications of projects, such as system development efforts or hardware installations. Instead, it is a commonsense approach to assist in prioritizing and implementing successful efforts of any jurisdiction.

In 1996, the information services (IS) division of one bank formed an IS reengineering team to focus on developing and deploying processes and tools associated with project management and system development. The mission of the IS reengineering team was to improve performance of IS projects, resulting in increased productivity and improved cycle time, quality, and satisfaction of project customers.

According to a spokesperson at the bank, the process began as follows:

Information from both current and previous methodologies used by the bank was reviewed, and the best practices of all these previous efforts were incorporated into this document. Regardless of the source, project methodology phases are somewhat standard fare. All projects follow the same steps, with the complexity, size, and type of project dictating to what extent the methodology must be followed. What this methodology emphasizes are project controls and the tie of deliverables and controls to accomplishing the goals.

To determine the weaknesses associated with past project management methodologies, the IS reengineering team conducted various focus groups. These focus groups concluded that the following had been lacking from previous methodologies:

• Management commitment
• A feedback mechanism for project managers to determine the updates and revisions needed to the methodology
• Adaptable methodologies for the organization
• A training curriculum for project managers on the methodology
• Focus on consistent and periodic communication on the methodology deployment progress
• Focus on the project management tools and techniques

Based on this feedback, the IS reengineering team successfully developed and deployed a project management and system development methodology. Beginning June 1996 through December 1996, the target audience of 300 project managers became aware and applied a project management methodology and standard tool (MS Project).

The bank did an outstanding job of creating a methodology that reflects guidelines rather than policies and provides procedures that can easily be adapted on any project in the bank. Up to 2017, the bank had continuously added flexibility into its project management approach, making it easier to manage all types of projects. Some of the selected components of the project management methodology are discussed next.

4.3 ENTERPRISE PROJECT MANAGEMENT METHODOLOGIES

Most companies today seem to recognize the need for one or more project management methodologies but either create the wrong methodologies or misuse these that have been created. Many times, companies rush into the development or purchasing of a methodology without any understanding of the need for one other than the fact that their competitors have a methodology. According to Jason Charvat:

Using project management methodologies is a business strategy allowing companies to maximize the project’s value to the organization. The methodologies must evolve and be “tweaked” to accommodate a company’s changing focus or direction. It is almost a mind-set, a way that reshapes entire organizational processes: sales and marketing, product design, planning, deployment, recruitment, finance, and operations support. It presents a radical cultural shift for many organizations. As industries and companies change, so must their methodologies. If not, they’re losing the point.¹

Methodologies are a set of forms, guidelines, templates, and checklists that can be applied to a specific project or situation. It may not be possible to create a single enterprise-wide methodology that can be applied to each and every project. Some companies have been successful doing this, but there are still many companies that successfully maintain more than one methodology. Unless the project manager is capable of tailoring the EPM methodology to his or her needs, more than one methodology may be necessary.

There are several reasons why good intentions often go astray. At the executive levels, methodologies can fail if the executives have a poor understanding of what a methodology is and believe that a methodology is:

• A quick fix
• A silver bullet
• A temporary solution
• A cookbook approach for project success²

At the working levels, methodologies can also fail if they:

• Are abstract and high level
• Contain insufficient narratives to support these methodologies
• Are not functional or do not address crucial areas
• Ignore the industry standards and best practices
• Look impressive but lack real integration into the business
• Use nonstandard project conventions and terminology
• Compete for similar resources without addressing this problem
• Don’t have any performance metrics
• Take too long to complete because of bureaucracy and administration³

Deciding on the type of methodology is not an easy task. There are many factors to consider, such as:

• The overall company strategy—how competitive are we as a company?
• The size of the project team and/or scope to be managed
• The priority of the project
• How critical the project is to the company
• How flexible the methodology and its components are⁴

Project management methodologies are created around the project management maturity level of the company and the corporate culture. If the company is reasonably mature in project management and has a culture that fosters cooperation, effective communications, teamwork, and trust, then a highly flexible methodology can be created based on guidelines, forms, checklists, and templates. Project managers can pick and choose the parts of the methodology that are appropriate for a particular client. Organizations that do not possess either of these two characteristics rely heavily on methodologies constructed with rigid policies and procedures, thus creating significant paperwork requirements with accompanying cost increases and removing the flexibility that the project manager needs for adapting the methodology to the needs of a specific client.

Charvat describes these two types as light methodologies and heavy methodologies.⁵

4.4 BENEFITS OF A STANDARD METHODOLOGY

For companies that understand the importance of a standard methodology, the benefits are numerous. These benefits can be classified as both short- and long-term benefits. Short-term benefits were described by one company as:

• Decreased cycle time and lower costs
• Realistic plans with greater possibilities of meeting time frames
• Better communications as to “what” is expected from groups and “when”
• Feedback: lessons learned

These short-term benefits focus on key performance indicators (KPIs) or, simply stated, the execution of project management. Long-term benefits seem to focus more upon critical success factors and customer satisfaction. Long-term benefits of development and execution of a world-class methodology include:

• Faster time to market through better scope control
• Lower overall program risk
• Better risk management, which leads to better decision making
• Greater customer satisfaction and trust, which lead to increased business and expanded responsibilities for the tier 1 suppliers
• Emphasis on customer satisfaction and value-added rather than internal competition between functional groups
• Customer treating the contractor as a partner rather than as a commodity
• Contractor assisting the customer during strategic planning activities

Perhaps the largest benefit of a world-class methodology is the acceptance and recognition by customers. If one of your critically important customers develops its own methodology, that customer could “force” you to accept it and use it in order to remain a supplier. But if you can show that your methodology is superior or equal to the customer’s, your methodology will be accepted, and an atmosphere of trust will prevail.

One contractor recently found that a customer had so much faith in and respect for its methodology that the contractor was invited to participate in the customer’s strategic planning activities. The contractor found itself treated as a partner rather than as a commodity or just another supplier. This resulted in sole-source procurement contracts for the contractor.

Developing a standard methodology that encompasses the majority of a company’s projects and is accepted by the entire organization is a difficult undertaking. The hardest part might very well be making sure that the methodology supports both the corporate culture and the goals and objectives set forth by management. Methodologies that require changes to a corporate culture may not be well accepted by the organization. Nonsupportive cultures can destroy even seemingly good project management methodologies.

During the 1980s and 1990s, several consulting companies developed their own project management methodologies, most frequently for information systems projects, and then pressured clients into purchasing the methodology rather than helping them develop a methodology more suited to their own needs. Although there may have been some successes, there appeared to be significantly more failures than successes. A hospital purchased a $130,000 project management methodology with the belief that this would be the solution to its information system needs. Unfortunately, senior management made the purchasing decision without consulting the workers who would be using the system. In the end, the package was never used.

Another company purchased a similar package, discovering too late that the package was inflexible and the organization, specifically the corporate culture, would need to change to use the methodology effectively. The vendor later admitted that the best results would occur if no changes were made to the methodology.

These types of methodologies are extremely rigid and based on policies and procedures. The ability to custom design the methodology to specific projects and cultures was nonexistent, and eventually these methodologies fell by the wayside—but after the vendors made significant profits. Good methodologies must be flexible.

4.5 CRITICAL COMPONENTS

It is almost impossible to become a world-class company with regard to project management without having a world-class methodology. Years ago, perhaps only a few companies really had world-class methodologies. Today, because of the need for survival and stiffening competition, numerous companies have good methodologies.

The characteristics of a world-class methodology include:

• Maximum of six life-cycle phases
• Life-cycle phases overlap
• End-of-phase gate reviews
• Integration with other processes
• Continuous improvement (i.e., hear the voice of the customer)
• Customer oriented (interface with customer’s methodology)
• Companywide acceptance
• Use of templates (level 3 WBS)
• Critical path scheduling (level 3 WBS)
• Simplistic, standard bar chart reporting (standard software)
• Minimization of paperwork

Generally speaking, each life-cycle phase of a project management methodology requires paperwork, control points, and perhaps special administrative requirements. Having too few life-cycle phases is an invitation for disaster, and having too many life-cycle phases may drive up administrative and control costs. Most companies prefer a maximum of six life-cycle phases.

Historically, life-cycle phases were sequential in nature. However, because of the necessity for schedule compression, life-cycle phases today will overlap. The amount of overlap will be dependent on the magnitude of the risks the project manager will take. The more the overlap, the greater the risk. Mistakes made during overlapping activities are usually more costly to correct than mistakes during sequential activities. Overlapping life-cycle phases requires excellent up-front planning.

End-of-phase gate reviews are critical for control purposes and verification of interim milestones. With overlapping life-cycle phases, there are still gate reviews at the end of each phase, but they are supported by intermediate reviews during the life-cycle phases.

World-class project management methodologies are integrated with other management processes, such as change management, risk management, total quality management, and concurrent engineering. This produces a synergistic effect, which minimizes paperwork, minimizes the total number of resources committed to the project, and allows the organization to perform capacity planning to determine the maximum workload that the organization can support.

World-class methodologies are continuously enhanced through KPI reviews, lessons-learned updates, benchmarking, and customer recommendations. The methodology itself could become the channel of communication between customer and contractor. Effective methodologies foster customer trust and minimize customer interference in the project.

Project management methodologies must be easy for workers to use as well as covering most of the situations that can arise on a project. Perhaps the best way is to have the methodology placed in a manual that is user friendly.

Excellent methodologies try to make it easier to plan and schedule projects. This is accomplished by using templates for the top three levels of the WBS. Simply stated, using WBS level 3 templates, standardized reporting with standardized terminology exists. The differences between projects will appear at the lower levels (i.e., levels 4 to 6) of the WBS. This also leads to a minimization of paperwork.

Today, companies seem to be promoting the use of the project charter concept as a component of a methodology, but not all companies create the project charter at the same point in the project life cycle, as shown in Figure 4-3. The three triangles in the figure show possible locations where the charter can be prepared:

• In the first triangle, the charter is prepared immediately after the feasibility study is completed. At this point, the charter contains the results of the feasibility study as well as documentation of any assumptions and constraints that were considered. The charter is then revisited and updated once this project is selected.
• In the second triangle, which seems to be the preferred method, the charter is prepared after the project is selected and the project manager has been assigned. The charter includes the authority granted to the project manager, but for this project only.
• In the third method, the charter is prepared after detail planning is completed. The charter contains the detailed plan. Management will not sign the charter until after detail planning is approved by senior management. Then, and only then, does the company officially sanction the project. Once management signs the charter, the charter becomes a legal agreement between the project manager and all involved line managers as to what deliverables will be met and when.

4.6 AIRBUS SPACE AND DEFENCE: INTEGRATION OF THE APQP METHODOLOGY WITHIN PROJECT LIFE CYCLE⁸

The Advanced Product Quality Planning (APQP) is a project management tool that provides effective early warning by monitoring on-quality and on-time delivery of key deliverables from the planning phase until the delivery/serial production with the objective to avoid costly issues and reworks due to immature deliverables and to increase our internal and external customers’ satisfaction. These key deliverables are called “critical to quality” (CTQ).

This section provides an integration of this methodology within project life cycle through the definition of standard milestones, or gate reviews, where the project is assessed to ensure the maturity to go to the next phase. The project life cycle defines every stage of a project, providing visibility on the predecessor steps, on what will be the upcoming steps, on what other functions shall be involved, on what interfaces are to be delivered, on what results are already achieved and by whom, and on what results are to be created or developed by the next phase. Gate reviews are held at key milestones within all campaigns, programs, and projects. Gates reviews provide an objective assessment of progress against key success criteria agreed for the phase and acceptability of the forward plan and the readiness to proceed to the next phase with the objective to prevent further problems due to immature status. A customer review is not a substitute for a ate review. The main principles of gate reviews are:

• Ensuring the maturity of the project vis-à-vis the specified objectives and the availability of resources. Confirming the availability of resources, tools, and facilities as well as potential obsolescence and process issues. Facilitating the identification and utilization of applicable lessons learned.
• Gate reviews are arranged only when other related reviews have already passed (e.g., sales, commercial and engineering/technical, and other reviews); in order to avoid duplication of effort, gate reviews take into account the findings and actions of other related reviews. To further facilitate the cross-functional integration of project key stakeholders (e.g., operations; corporate functions like security, commercial, finance and legal, quality, engineering, support and service, etc.).
• Provide top management with a structured and independent assessment of program/project status; assess the program/project based on “Four Eyes Principle,” where the person who assesses the program/project is not the same one who is currently leading or performing the program/project itself. Provide transparency and unbiased opinion with respect to complex programs/projects, and provide value-add from expert reviews of the project.

The integration of APQP within project life cycle is performing through the matching of APQP phases with gate reviews, as described in Figure 4-4. Respectively, each assessment criteria of each gate review contains the expected output and associated critical-to-quality deliverable to be assessed.

Table 4-1 shows an example of a criteria assessment for the gate review.

4.7 PROJECT QUALITY GATES—STRUCTURED APPROACH TO ENSURE PROJECT SUCCESS⁹

Project quality is paramount in delivery of SAP projects; this fact is reflected in structured approach to quality management for SAP solution delivery—Quality Built In. The staple of the quality approach in SAP projects is the execution of formal project quality gates. The quality gates are defined in the ASAP (Accelerated SAP project delivery methodology) project delivery methodology that SAP and its customers and partners use for project planning, management, and delivery. Each project type has predetermined number of quality gates (Q-Gates) executed at key milestones of the project, as shown in Figure 4-5.

SAP believes that the quality gates are essential for success of any project regardless of deployment strategy—like traditional or agile. The quality gates are integrated not only into our delivery methodology, but they are also coded into our delivery policies and internal systems. The results of each quality gate are recorded in the corporate project management information system and are regularly reviewed and reported on. A dedicated quality team in SAP has accountability for management of the quality gates, review of project health and follow-up with project manager, stakeholders and leadership.

The project quality gates in the ASAP methodology provide clear guidance to project managers, stakeholders, and project teams on how to structure and perform the quality gate review. During each quality gate, the quality assurance manager assesses completeness and quality of each deliverable produced in the project according to predefined quality gate checklist, which includes not only deliverable name but also detailed acceptance criteria. Each deliverable in the checklist is marked as either mandatory or optional for completion of the quality gate. Upon completion of the quality gate, the QA manager assesses pass/fail score for the quality gateand proposes follow-up plans to take corrective actions to address deficiencies identified in this process.

The formal quality built-in process has been shown to have positive impacts on customer satisfaction and improved overall project portfolio health, and it has positively impacted revenue.

ASAP Methodology

The ASAP methodology is a structured, repeatable, prescriptive way to deliver SAP projects and innovate project delivery. SAP delivery projects follow structured, repeatable, and prescriptive methodology for implementation. The ASAP methodology for implementation is SAP’s content-rich methodology for assisting with the implementation and/or upgrade of SAP solutions across industries and customer environments. Built on experience from thousands of SAP projects, ASAP provides content, tools, and best practices that help consultants to deliver consistent and successful results across industries and customer environments.

The six phases of ASAP provide support throughout the life cycle of SAP solutions. Underlying these phases is a series of value delivery checks to make sure that the solution, as implemented, delivers the expected value. Figure 4-6 illustrates the phases of ASAP.

The methodology covers key aspects of SAP implementation from project management guidance structured around the PMI PMBOK® Guide¹⁰ through business process design, business value management, application life-cycle management, organizational change management, technical solution management, data management, and other topics important for delivery of SAP solutions.

The ASAP methodology is not pure project management methodology, but instead it combines all key elements the project team needs to cover in order to deliver successful projects. This approach is shown in Figure 4-7.

The ASAP methodology is designed in a way that enables flexibility and scalability from smaller projects, such as single consulting services delivery, to more complex delivery of global deployments in multinational corporations. This flexible design allows us to use the methodology as a foundation for creation of all consulting services. Each engineered service leverages the common WBS of the ASAP methodology to define clearly the work that is performed, roles and skills that are required to deliver service, and also details about sourcing of the roles from within the organization.

This approach helps us achieve commonality between the services in areas that are not core expertise of service owners (like project management). It also lowers the cost of service creation and simplifies the adoption process.

Thanks to the use of common taxonomy based on ASAP in the creation of services, the SAP projects can be assembled from individual engineered services and delivered in assembled-to-order approach rather than designed from scratch. SAP was recognized by the Technology Services Industry Association in 2012 for its innovative approach in services delivery with the SAP Advanced Delivery Management approach that is built on principles of common modular services that can be assembled and reused in different projects. (See Figure 4-8.)

With this approach, SAP customers take advantage of prebuild services and content and lower the cost of deployment and complexity of projects and minimize the risk of deployment projects. The engineered services and rapid deployment solutions are used in early stages of the project to establish a baseline solution that is later enhanced in a series of iterative incremental builds using agile techniques. This innovative approach to project delivery has significantly changed the delivery of projects and requires our project managers to adopt their skills to this innovative way of project execution. One example is that project managers need to learn how to structure and run projects with the iterative agile techniques to design, configure, or develop customer-specific extensions, which is substantially different from traditional management of projects where solutions are built from scratch.

The common methodology and its taxonomy are not only great enablers for project delivery, but they have also helped SAP innovate the way solutions are delivered and deployed.

4.8 AIRBUS SPACE AND DEFENCE: INTEGRATED MULTILEVEL SCHEDULES¹¹

Perhaps the single most important benefit of a good methodology is the ability to create integrated multilevel schedules for all stakeholders.

Why Integrated Multilevel Schedules?

The Integrated Multilevel Scheduling practice is aimed at providing each level of management of the project, from the Customer and/or the Company management, down to the Project Management, and down to the Work Package management, with consistent schedule baselines, consistent progress measurement, and consistent estimates to completion.

This practice is widely used for large and complex projects.

Definition of Integrated Multilevel Schedules

Project-integrated multilevel scheduling is aimed divided into three levels of management:

• Master schedule (Level 1): Customer and/or the company management
• Project summary schedule (Level 2): Project management
• Detailed schedule (Level 3): Work package management

By default, the different levels of schedules are self-sufficient, reflecting the delegation of management responsibility in the project:

• Master schedule is owned by the project manager.
• Project summary schedule is owned by the project manager (for large project, the project manager may be supported by the project management office).
• Detailed schedules are owned by work package managers.

In addition, to deliver and maintain a multilevel project schedule, links shall be performed between the different levels to provide an integrated multilevel project schedule.

Prerequisites to Prepare and to Deliver Integrated Multilevel Schedules

Before developing integrated multilevel schedules, the following deliverables shall be completed and performed:

Define the Project Scope

• Collect the requirements.
• Define the product breakdown structure with all internal and external deliverables.
• Develop the work breakdown structure—think deliverables.
• Specify work packages with a special focus on inputs needed and outputs expected including acceptance criteria of the deliverables.
• Plan a review of all the work packages descriptions with all main stakeholders of the project, the objective is to share and control the consistency between inputs and outputs of the different work packages.
• Estimate target duration, work, cost and skills for each work package.
• Manage risks and opportunities to define and plan mitigation actions and to identify where buffers shall be added in the plans.

Principles of Integrated Multilevel Schedules

The following principles shall be followed to ensure a success Integrated Multilevel Schedules:

• The master schedule (also called Level 1 Plan) shall deliver a synthetic view (one page) on the project schedule reflecting the major milestones (contractual milestones, major customer furnished items or equipment [CFI/CFE] with critical impact on contractual deliverables), the dependencies between major milestones and summaries of the main phases, the contractual dates (contract commitments), and the current contract status (major milestones passed and current progress with forecasted dates).
• The project summary schedule (also called Level 2 Plan) shall cover the complete WBS of the project and shall be organized according to the WBS structure. It shall provide the dependencies between all the WP of the project and the dependencies between the WP deliverables and the major milestones of the project.
• The detailed schedule (also called Level 3 Plan) shall deliver the detailed schedule of each work package, which shall be broken down in activities; each activity shall conduct to a deliverable and shall be broken down in elementary tasks with resources assigned.

In addition, between the different levels, multilevel schedule links shall be implemented (see Figure 4-9):

• Between the Level 1 Plan and the Level 2 Plan, links should be defined to follow the adherence to the contractual milestones dates (customer commitments) and other key milestones dates. Thereof, all major milestones (MM) reported in the Level 1 Plan shall be linked to corresponding MM in the Level 2 Plan.
• Between the Level 2 Plan and the Level 3 Plan, links should be defined to follow the adherence to the project dates (project target dates), where each WP, the input(s) and output(s) defined in the Level 2 Plan should be linked to corresponding input(s) and output(s) of the Level 3 Plan.
• Two types of links should be used:
  • Hard links (also called driving links) for inputs in order to align automatically the date of availability of the corresponding input in the lower level.
  • Soft links for outputs to inform on the forecasted date in the lower level of the output without impacting automatically the date defined in the upper level.

Monitor and Control of Integrated Multilevel Schedules

The monitoring and controlling of the different levels of schedule, including the consistency, should be performed within one month according to the following scheme:

1. Update of Level 3 schedules by each work package manager based on current actual and new forecast according to ongoing work package progress.
2. Multilevel consistency checking by the project management office including the deviations and the identification of the impact over key milestones.
3. Schedule review among project management office, engineering authority, and work package managers in order to identify actions plan to recover target dates.

Validation by the project manager with the update of Level 3 and Level 2 schedules based on the decisions taken and update performance baseline if needed.

4.9 TÉCNICAS REUNIDAS¹²

Material in this section has been provided by Felipe Revenga López, the chief operations officer of Técnicas Reunidas since September 2008. He joined Técnicas Reunidas in 2002 as project director and then as project sponsor of a group of international strategic projects. He has large experience in EPC-LSTK and OBE-LSTK projects in the Oil & Gas Production Units, Refining, Petrochemical, and Power Sector worldwide. He is an Industrial Engineer (specialty Chemicals) by the School of Industrial Engineers and currently is finishing the doctoral program in Engineering of Chemical and Biochemical Processes at the Polytechnic University of Madrid.

*   *   *

Introduction

Open Book Estimate as a Successful Contract Alternative to Execute Projects in the Oil and Gas Sector

As a result of the projected rate of energy demand growth, the oil and gas industry has a wide range of challenges and opportunities across different areas. For that reason, for a number of years the sector has been developing new facilities, which in many cases are megaprojects.

The typical complete life cycle of a capital project in the oil and gas sector is focused in the overall stages that are shown in Figure 4-10. Understanding and managing these stages is crucial on the long-term success of the project.

Lump-sum turnkey (LSTK) and cost-plus contracting are both very prevalent types of contracts within projects in the oil and gas industry. The level of risk the client of a project is willing to accept, budget constraints, and the client’s organization core competencies determine which method is best for a project.

A large number of projects in this sector are performed under engineering, procurement, and construction (EPC)–LSTK contracts; The major experience of Técnicas Reunidas (TR) is based mainly in this type of projects, which in general means managing the whole project and carrying out the detailed engineering (in some cases it is included the basic engineering or front-end engineering design (FEED) in the scope of work); procuring all the equipment and materials required; and then constructing, precommissioning, and starting up to deliver a functioning facility ready to operate. LSTK contracting tends to be riskiest, and all risks are assumed by the EPC contractor.

The open book estimate (OBE) or open book cost estimate (OBCE) is an alternative way to execute EPC projects. With this type of contract, the final purpose of the work is to define the total price of the project in collaboration with the client; the global costs of the project are established in a transparent manner (open book).

The Open Book Estimate

The main purpose of the OBE methodology is to build up an accurate EPC price by applying some parameters previously agreed on (between client and the contractor), the base cost through an OBE, the development of an extended front-end engineering effort and in some cases the placement of purchase orders for selected long lead and critical items to ensure the overall schedule of the project. The OBE will fix the project base cost and will become the basis for determining the lump-sum EPC price for the project.

During an OBE phase, the contractor develops a FEED and/or part of the detailed engineering under a reimbursable basis or lump-sum price or alternatives, including a complete and open cost estimate of the plant. After an agreed period (usually between 6 to 12 months, mainly dependent on the accuracy grade, schedule, and other factors required by client) of engineering development and after the client and contractor agree on the base cost, the contract is changed or converted to an EPC LSTK contract applying previously agreed-on multiplying factors.

Cost Estimate Methodology

Principal Cost Elements and Pricing Categories

The OBE usually is based on sufficient engineering development in accordance with the deliverables identified in OBE contract. These deliverables are developed as much as possible in the normal progress of the project. Required deliverables are prepared and submitted to the client prior to completion of the conversion phase.

The principal cost elements, as seen in Figure 4-11, that comprise the OBE are addressed below. The OBE cost estimate shall include the total scope of work:

1. Detailed engineering, procurement, and construction services
2. Supply of equipment, bulk materials, and spare parts
3. Transport to construction site
4. Customs clearance
5. Construction and erection at site
6. Provision of subcontractors’ temporary construction facilities and services
7. Construction and precommissioning services
8. Commissioning and start-up services
9. Training services and vendor’s assistance
10. Bonds, insurances, hedging charges
11. Other costs, including third-party inspection and contractor insurance
12. Others

Cost Base

• An OBE procedure is developed during the contract stage and implemented during the project’s OBE phase. All details on how to prepare an OBE have to be agreed and included as an annex in the contract.
• Preagreement of allowances, growth, conditioning, technical design allowances, surplus, and cut and waste.
• Material take-offs (MTOs) based on PDS software, measured in process and instrument diagrams (P&ID) and plot plans and estimates. All details on procedures are to be agreed on before OBE contract signature.

In executing projects under convertible basis, TR develops the OBE in parallel with the normal project execution, ensuring that both activities can flow smoothly without interference. During the OBE phase, in certain cases and if agreed with the client, TR can advance the procurement of the main equipment and initiate negotiations for construction subcontractors. The execution of these activities in advance facilitates the fulfillment of project schedule requirements.

This OBE phase of the project is jointly developed between the client and TR. The OBE is fully transparent to client and the conversion to LSTK is made once the risk/reward element is fixed.

In Figure 4-12, we see the main steps and activities that are developed to achieve OBE goals and to convert to next phase of the project.

During the OBE phase, cost-saving ideas are developed in order to adjust the final cost estimate; to do so, a special team of engineering specialists is appointed to work with both the engineering manager and the estimating manager, with the purpose to determine those areas where potential savings can be achieved by optimizing the design, without jeopardizing safety, quality, or schedule. Any of these changes that could lead to cost savings are carefully evaluated from a technical point of view. If the feasibility of the potential change is proven, the alternative solution, together with the cost-saving impact evaluation, will be forwarded to the clients for consideration.

The EPC contract price is the result of the base cost multiplied by fixed percentages for fee and markups related to equipment, bulk materials, construction, and ancillary costs agreed to by the client and contractor. During the conversion phase, this price is converted to lump-sum price and thereafter remains fixed during the EPC-LSTK phase.

Contracts

There are two typical models of contracts under this OBE alternative:

1. One contract, two parts: OBE and EPC. The price for the EPC part is to be included at conversion.
2. Two contracts, one OBE and the other EPC. Both may be signed at the beginning or one at the beginning and the other at conversion.

The methodology of the OBE is included in the contract.

In the case of no conversion:

• The contractual relationship disappears, and both client and contractor break their commitment. The client may break the contract if it is not interested. Consequences:
  • Six months for a new LSTK offer. Two to three months plus evaluating the offers
  • Repeat FEED with different contractor.
• Contract provides mechanisms in the case of no agreement.
  • Continue contract on a service base (better LS contract).
  • Agree on partial conversion.
  • Other actions as per contract agreement.

Advantages

An OBE phase followed by an LSTK contract could optimize all project execution, especially in cost and schedule.

• In terms of cost, the client and contractor could together determine the project cost through an OBCE because an estimation methodology, conversion conditions such as multiplying factors are agreed upon, etc. Both the client and the contractor determine by mutual agreement the final price of the contract, sharing all information. This will generate a feeling of trust between both companies. This model results in an accurate cost because unnecessary contingencies are avoided.
• However, this model results in schedule advantages because the bidding period is shortened or replaced by a conversion negotiation phase; an EPC stage is shortened because all the work is developed during the extended feed and conversion stage. A representation of the schedule advantage is shown in Figure 4-13.

In summary, the advantages in cost and schedule are shown in Table 4-2.

Cost

Schedule Reduction

Develops an EPC estimate during 6 to 12 months. This provides a much more accurate costs. Accurate prices based on real offers and an agreed conversion factor assures fairness to client and contractor. There is enough time to develop the project and to avoid unnecessary contingencies. Application of cost saving to match project cost to client’s budget. Facilitates the possibility of funding, because a more accurate estimation. Risk are reduced and better controlled to the benefit of both client and contractor

Short bidding period, as cost estimate does not need to be as detailed in an EPC-LSTK common bidding process Shortening of the overall project schedule: time for extended FEED and EPC bidding is shortened dramatically. Contract award procedure is much easier and shorter. Some long-lead Items and critical equipment could be awarded or negotiated.

Close-out

The OBE has been demonstrated to be a successful contract alternative for executing projects in the oil and gas sector because it aligns clients and contractors with the project’s goals. Both are motivated to pursue the best cost estimation or project target cost, and at the same time the schedule is optimized.

As mentioned in the introduction to this section, in the oil and gas sector, most current projects can be considered megaprojects, where there are many risks with a high workload from suppliers, contractors, subcontractors, and others. Through an OBE alternative, clients can better manage risks through a more cooperative and agreed-on approach, where the risks are reduced during an accurate estimate and then embraced rather than totally transferred to contractors. In this way, project outcomes can be improved.

TR has converted successfully 100 percent from OBE to EPC-LSTK projects.

Definitions

• Client: The owner of the oil and gas company
• Contractor: Affiliated company responsible for performing the engineering, procurement and construction services
• EPC: Engineering, procurement, and construction. Type of contract typical of industrial plant construction sector, comprising the provision of engineering services, procurement of materials, and construction.
• FEED: Front-end engineering design. This refers to basic engineering conducted after completion of the conceptual design or feasibility study. At this stage, before the start of EPC, various studies take place to figure out technical issues and estimate rough investment cost.
• LS contract: Lump-sum contract. In a lump-sum contract, the contractor agrees to do a specific project for a fixed price
• LSTK contract: lump-sum contract. In a lump-sum turnkey contract, all systems are delivered to the client ready for operations.
• MTOS: Material take-offs. This refers to piping, electrical, and instrumentation.
• OBE: Open book estimate or open book cost estimate (OBCE)
• PDS: Plant design system. Software used for designing industrial plants through a multidisciplinary engineering activity
• P&ID: Process and instrument diagrams
• TR: Técnicas Reunidas

4.10 YANFENG GLOBAL AUTOMOTIVE INTERIOR SYSTEMS CO. LTD.¹³

The Product Realization Process (PRP) project was a global initiative to develop a common launch process to enable consistent execution across all regions within the organization. The project team of regional subject matter experts in all functions worked collaboratively to develop a standard set of deliverables and timing objectives for every program launch. Training was also developed to support the roll-out of the process. The PRP project charter, approved by the organization leadership, allowed the project team to develop a common launch process that would be applied globally. An aggressive target required the process to be ready to support implementation on programs, in a pilot phase, within six months. PRP enables our new company to “speak one language” regarding program development and launch.

The PRP project team succeeded in developing the new process within the targeted six-month period and made the process available for release into internal systems by October 2016. The core PRP Project team consisted of experienced subject matter experts from each region and each functional group. In total, this was over 30 members.

Initial project development activity began with Workshop #1 in August 2016 in Holland, Michigan, and completed five months later in Shanghai with Workshop #4 in December 2016. Functional experts from North America, Europe, and Asia Pacific regions participated in multiple workshop activities, in addition to their regular work duties. Significant effort was also extended between workshops to continue collaboration and help ensure global alignment on functional deliverable requirements.

The PRP team members also helped develop functional training material to support PRP Pilot phase activity. Training was provided in e-learning, video, and classroom style. Pilot phase team training was kicked off in February 2016. Over 200 team members across the three global regions participated in PRP training for their pilot programs. Over 30 PRP pilot teams used the PRP launch process.

Through the course of the workshop activity and cross-functional collaboration, over 100 process documents were developed and released.

The result of this tremendous effort by a global team is the availability of a common process that will enable consistent launch execution in all regions and allow for seamless execution of global programs. The PRP project team achieved the requirements established in the project charter.

The PRP project team demonstrated all of the organization’s values over the course of the six-month project. The process, created by the team, will positively impact future programs for many years.

This project required that an experienced cross-functional team worked together across different regions, cultures, and time zones. The team was united by one vision to create a new common process based on prior JCI-PLUS and YF-IDS launch processes. Each functional group demonstrated exceptional teamwork working collaboratively with regional peer groups. Team collaboration was highly visible within working groups as they focused on understanding unique regional requirements.

Team members assumed this activity and additional responsibilities beyond their normal work activities. This required extensive travel and additional support that exceeded normal working hours. Each team member stayed focused and fully committed to meet project deliverables. The multicultural team remained patient and open to learning from each other and developing a world-class launch process.

Functional group leaders and individuals consistently demonstrated personal initiative, accountability, and a passion for excellence. Action plans were developed and executed to accomplish the overall project objectives and timeline. Each team member recognized the significance of this project and the long-term benefit to Yanfeng Global Automotive Interior Systems (YFAI).

Facilitating a standard process for launching programs is only one element within the realm of responsibility for the program management office. The governance of process and compliance along with the development of program team members are the other two areas that are the focus for the project management office (see Figure 4-14).

The true best practice of developing and institutionalizing the new PRP is that it was managed as an actual project using the typical methods of project management. The project timing was managed by the use of a standard timeline and Gantt charts. All of the PMBOK knowledge areas were integrated, and project success was enabled by utilizing the processes of initiation, planning, execution, monitoring, and closing.

4.11 SONY CORPORATION AND EARNED VALUE MANAGEMENT¹⁴

Earned value management (EVM) is one of the most commonly used tools in project management. When it is used correctly, EVM becomes a best practice and allows managers and executives to have a much clearer picture as to the true health of a project. EVM can also lead to significant continuous improvement efforts. Such was the case at Sony.

Sony suffered from some of the same problems that were common in other companies. Because project planning at Sony often did not have desired level of detail, Sony viewed itself as operating in a “negative cycle,” as shown in Figure 4-15. Sony’s challenge was to come up with effective and sustainable ways to break out of this negative cycle.

Sony’s basic idea or assumption was that unless people recognize the need for change and want to get involved, nothing will happen, let alone further improvements. Sony realized that, at the beginning of the EVM implementation process, it might need to sacrifice accuracy of the information.

Sony sought the easiest possible or the most elementary way for project managers and team members to implement progress monitoring continuously.

Sony started by:

1. Using information on a list of final deliverables together with a completion date for each final deliverable. Team members did not have to make an extra effort to produce this level of information because it was being provided to them.
2. Selecting the fixed ratio method, among several EVM methods, such as the weighted milestone method, percentage-complete method, and criteria achievement method for reporting progress. The fixed ratio method required the least effort from project managers and team members.
3. Visualizing project progress and monitoring process using various graphs, such as Figures 4-16 and 4-17 for Schedule Performance Index (SPI) reporting.

Shortly after people started to practice this elementary method of progress monitoring and reporting, we began to observe the following improvements:

1. Increased awareness by project managers and team members that forecasting, early alerts, and taking countermeasures earlier improve productivity (i.e., SPI).
2. Increased awareness by project managers and team members that reviewing and creating more detailed plans were critical to further improve productivity (i.e., SPI).

Visualization or performance certainly helped the project teams to easily understand how important and beneficial practicing project progress monitoring was.

Project managers and team members began to take initiatives to improve project progress monitoring and reporting, as shown in Figure 4-18. For example, team members noted that delays in progress were difficult to detect when data accuracy was poor or not detailed enough. Team members started to improve data accuracy by:

1. Dividing a month into three parts. Previously, data was given on a monthly basis.
2. Making changes to the fixed ratio method. Previously, the 1/100 rule had been applied but now the 20/80 rule was used.
3. Adding intermediate deliverables. Intermediate deliverables were reported in addition to final deliverables

In summary, as an effective first step toward implementing progress monitoring, it is important to start by using as data whatever deliverables are already available in your organization.

By visualizing progress monitoring and through forecasting, ensure sure that correct countermeasures are taken to solve problems.

Accuracy will be improved once people become aware of the effectiveness of project progress monitoring.

Reference Documents

Nagachi, Koichi. 2006. “PM Techniques Applied in Nile Firmware Development: An Attempt to Visualize Progress by EVM.” Paper presented at the PMI Tokyo Forum.

Nagachi, Koichi, and Jun Makino. 2012. “Practicing Three Earned Value Measurement Methods.” Paper presented at the PMI Japan Forum.

Tominaga, Akira. August 20, 2003. EVM: Earned Value Management for Japan. Society of Project Management.

Yamato, Shoso, and Koichi Nagachi. April 20, 2009. “IT Project Management by WBS/EVM,” Soft Research Center Inc.

4.12 PROJECT MANAGEMENT TOOLS AND SOCIALIZED PROJECT MANAGEMENT

In the early years of project management, EVM was the only tool used by many companies. Customers such as the Department of Defense created standardized forms that every contractor was expected to complete for performance reporting. Some companies had additional tools, but these were for internal use only and not to be shared with the customers.

As project management evolved, companies created enterprise project management (EPM) methodologies that were composed of multiple tools displayed as forms, guidelines, templates, and checklists. The tools were designed to increase the chances of repeatable project success and designed such that they could be used on multiple projects. Ideas for the additional tools often came from an analysis of best practices and lessons learned captured at the end of each project. Many of the new tools came from best practices learned from project mistakes such that the mistakes would not be repeated on future projects. Project teams now could have as many as 50 different tools to be used. Some tools were used for:

• Defining project success since the definition could change from project to project
• Capturing best practices and lessons learned throughout the project life cycle rather than just at project completion
• Advances in project performance reporting techniques
• Capturing benefits and value throughout the life cycle of the project
• Measuring customer satisfaction throughout the life cycle of the project
• Handing off project work to other functional groups

As project management continued to evolve, companies moved away from co-located teams to distributed or virtual teams. Now additional tools were needed to help support the new forms of project communications that would be required. Project managers were now expected to communicate with everyone, including stakeholders, rather than just project team members. Some people referred to this as PM 2.0, where the emphasis was on social project management practices.

Advances in technology led to a growth in collaborative software, such as Facebook, and Twitter, as well as collaborative communications, platforms such as company intranets. New project management tools, such as dashboard reporting systems, would be needed. Project management was undergoing a philosophical shift away from centralized command and control to socialized project management, and additional tools were needed for effective communications. These new tools are allowing for a more rigorous form of project management to occur accompanied by more accurate performance reporting. The new tools also allow for decision making based on facts and evidence rather than guesses.

4.13 ARTIFICIAL INTELLIGENCE AND PROJECT MANAGEMENT

It appears that the world of artificial intelligence (AI) is now entering the project management community of practice, and there is significant interest in this topic. Whether AI will cause an increase or decrease in project management tools is uncertain, but an impact is expected.

A common definition of AI is intelligence exhibited by machines.¹⁵ From a project management perspective, could a machine eventually mimic the cognitive functions associated with the mind of a project manager such as decision making and problem solving? The principles of AI are already being used in speech recognition systems and search engines, such as Google Search and Siri. Self-driving cars use AI concepts as do military simulation exercises and content delivery networks. Computers can now defeat most people in strategy games such as chess. It is just a matter of time before we see AI techniques involved in project management.

The overall purpose of AI is to create computers and machinery that can function in an intelligent manner. Doing this requires the use of statistical methods, computational intelligence, and optimization techniques. The programming for such AI techniques requires not only an understanding of technology but also an understanding of psychology, linguistics, neuroscience, and many other knowledge areas.

The question regarding the use of AI is whether the mind of a project manager can be described so precisely that it can be simulated using the techniques just described. Perhaps there is no simple logic that will accomplish this in the near term, but there is hope because of faster computers, the use of cloud computing, and increases in machine learning technology. However, there are some applications of AI that could assist project managers in the near term:

• The growth in the use of competing constraints rather than the traditional triple constraints will make it more difficult to perform trade-off analyses. The use of AI concepts could make life easier for project managers.
• We tend to take it for granted that the assumptions and constraints given to us at the onset of the project will remain intact throughout the project’s life cycle. Today, we know that this is not true and that all assumptions and constraints must be tracked throughout the life cycle. AI could help us in this area.
• Executives quite often do not know when to intervene in a project. Many companies today are using crises dashboards. When an executive looks at the crises dashboard on the computer, the display identifies only those projects that may have issues, which metrics are out of the acceptable target range, and perhaps even the degree of criticality. AI practices could identify immediate actions that could be taken and thus shorten response time to out-of-tolerance situations.
• Management does not know how much additional work can be added to the queue without overburdening the labor force. For that reason, projects are often added to the queue with little regard for (1) resource availability, (2) skill level of the resources needed, and (3) the level of technology needed. AI practices could allow for the creation of a portfolio of projects that has the best chance to maximize the business value the firm will receive while considering effective resource management practices.
• Although some software algorithms already exist for project schedule optimization, practices still seem to be a manual activity using trial-and-error techniques. Effective AI practices could make schedule optimization significantly more effective by considering all present and future projects in the company rather than just individual projects.

Project managers are often pressured to make rapid decisions based on intuition rather than by step-by-step deduction used by computers. Nothing is simply true or false because we must make assumptions. Generally speaking, the more information we have available, the fewer the assumptions that must be made. With a sufficient database of information, AI tools could perform reasoning and problem solving based on possibly incomplete or partial information. AI can visualize the future and provide us with choices that can maximize the value of the decision.

If AI practices are to be beneficial to the project management community of practice, then pockets of project management knowledge that existed in the past must be consolidated into a corporate-wide knowledge management system that includes all of the firm’s intellectual property, as shown in Figure 4-19.

The more information available to the AI tools, the greater the value of the outcome. Therefore, the starting point must be a consolidation of project management intellectual property, and the AI tools must have access to this information. PMOs will most likely have this responsibility.

While all of this sounds workable, there are still some downside risks based on to which area of knowledge in the PMBOK^® Guide we apply the AI tools. As an example, using the Human Resources Knowledge Area, can AI measure and even demonstrate empathy in dealing with people? In the Integration Management Knowledge Area, can AI add in additional assumptions and constraints that were not included in the business case when the project was approved? In the Stakeholder Management Knowledge Area, can the AI tools identify the power and authority relationships of each stakeholder? And with regard to machine ethics, can an AI tool be made to follow or adhere to PMI’s Code of Ethics and Professional Responsibility when making a decision?

While all of this seems challenging and futuristic to some, AI is closer than you think. Amazon, Google, Facebook, IBM, and Microsoft have established a nonprofit partnership to formulate best practices on AI technologies, advance the public’s understanding, and serve as a platform about AI.¹⁶ In a joint statement, the companies stated: “This partnership on AI will conduct research, organize discussions, provide thought leadership, consult with relevant third parties, respond to questions from the public and media, and create educational material that advance the understanding of AI technologies including machine perception, learning, and automated reasoning.”¹⁷ Though not one of the original members in 2016, Apple joined other tech companies as a founding member of the Partnership on AI in January 2017.¹⁸ The corporate members will make financial and research contributions to the group, while engaging with the scientific community to bring academics onto the board.¹⁹

Given the fact that Amazon, Google, Facebook, IBM, Microsoft, and Apple are all heavy users of project management, and by some are considered to have world-class project practices, how long do you think it will be before they develop AI practices for their own project management community of practice? The implementation of AI practices to project management may very well be right around the corner.

4.14 LIFE-CYCLE PHASES

When developing a project management methodology, determining the best number of life-cycle phases can be difficult. As an example, let’s consider IT. During the 1980s, with the explosion in software, many IT consulting companies came on the scene with the development of IT methodologies using systems development life-cycle phases. The consultants promised clients phenomenal results if clients purchased the package along with the accompanying training and consulting. Then, after spending hundreds of thousands of dollars, clients read the fine print that stated that the methodology must be used as is, and no customization of the methodology would take place. In other words, clients would have to change their company to fit the methodology rather than vice versa. Most of the IT consultancies that adopted this approach no longer exist.

For an individual company, agreeing on the number of life-cycle phases may be difficult at first. But when an agreement is finally reached, all employees should live by the same phases. However, for today’s IT consulting companies, the concept of one-package-fits-all will not work. Whatever methodology they create must have flexibility in it so that client customization is possible. In doing so, it may be better to focus on processes rather than phases, or possibly a framework approach that combines the best features of each.

4.15 EXPANDING LIFE-CYCLE PHASES

Historically, we defined the first phase of a project as the initiation phase. This phase included bringing project managers on board, handing them a budget and a schedule, and telling them to begin project execution. Today, there is a preinitiation phase, which Russ Archibald and his colleagues refer to as the Project Incubation/Feasibility Phase.²⁰ In this phase, we look at the benefits of the project, the value expected at completion, whether sufficient and qualified resources are available, and the relative importance of the project compared to other projects that may be in the queue. It is possible that the project may never reach the Initiation Phase.

In the past, project management was expected to commence at the initiation phase because it was in this phase that the project manager was assigned. Today, project managers are expected to possess a much greater understanding of the business as a whole, and companies have found it beneficial to bring project managers on board earlier than the initiation phase to assist in making business decisions rather than purely project decisions.

In the same context, we traditionally viewed the last life-cycle phase as project closure, which includes the implementation of contractual closure, administrative closure, and financial closure. After closure, the project manager would be reassigned to another project.

Today, we are including a post-project evaluation phase. Some companies refer to this as a customer satisfaction management phase. In this phase, selected members of the project team and sales/marketing personnel, as well as members from the governance committee, meet with the client to see what changes can be made to the methodology or processes used to execute the project and what can be done differently on future projects for this client to further improve the working relationship among client, contractor, and stakeholders.

4.16 CHURCHILL DOWNS INCORPORATED

Churchill Downs Incorporated has created a project management methodology that clearly reflects its organization. According to Chuck Millhollan, director of program management:

While we based our methodology on professional standards, we developed a graphic (and used terminology) understood by our industry to help with understanding and acceptance. For example, we have a structured investment request, approval and prioritization process. (See Figure 4-20.) We used the analogy of bringing the Thoroughbred into the paddock prior to race and then into the starting gate. The project, or race, is not run until the Thoroughbred has entered the starting gate (approved business case and project prioritization).

4.17 INDRA: THE NEED FOR A METHODOLOGY

As mentioned in Chapter 3, the quest for excellence in project management is almost always accompanied by the development of a project management methodology. Such was the case at Indra. Indra defines excellence in project management as follows: “Excellence in project management is achieved by being able of repeatedly reaching the project targets, creating business opportunities, and improving the management process itself when managing the assigned projects.” Enrique Sevilla Molina, PMP, formerly corporate PMO director, discusses the journey to excellence:

A project management methodology was formally defined in the mid-’90s based upon the experience gained in our major international contracts. The main problems we faced were related to the definition of the scope, the limits of the methodology, and the adoption of the correct strategy to spread this knowledge throughout the company. To solve these issues, our management chose to hire an external consulting company to act as a dynamic factor that boosted and drove the cultural change.

Yes, the process was carefully sponsored from the beginning by senior executives and closely followed up until its complete deployment in all areas of the company.

The major milestones of the process have roughly been:

1. Project management strategy decision: mid-1990s
2. Methodology definition and documentation: mid- late 1990s
3. Tools definition and preparation: late 1990s
4. Training process start: 2000
5. Risk management at department level: 2002
6. PMP^® certification²¹ training start: 2004
7. Risk management process defined at corporate level: 2007
8. Program and portfolio management processes definition start: 2008

A PM methodology was developed in the early ‘90s and formalized during that decade. It eventually was updated to cope with the company and the industry evolution. It is being used as a framework to develop and maintain the PMIS [project management information system], and to train the PMs throughout the company.

It is based on the project life cycle and structured in two stages and six phases, as shown in Figure 4-21:

Precontractual Stage

Phase 1. Initiation

Phase 2. Concept development, creation of offers and proposals

Phase 3. Offer negotiation

Contractual Stage

Phase 4. Project planning

Phase 5. Execution, monitoring, and control

Phase 6. Closure

The precontractual and contractual stages are both part of the project and its life cycle. Most problems that appear during a project’s life span originate during its definition and in the negotiation of its objectives, contents, and scope with the customers. A proper management of the precontractual stage is the best way to prevent problems later on.

At the end of each phase there is a specific result that will allow a key decision to be made, focusing and directing the actions of the next phase and thereby reducing the initial risks and uncertainties of the project.

The decision on the stages and phases was a decision mainly based on the needs of our standard cycle of a project conception and development, and based on the most significant types of projects we were involved with.

Risk management processes are integrated into the methodology and into the corporate PM tools. An initial risk identification process is performed during the proposal phase, followed by a full risk management plan during the planning phase of the contract stage, and the subsequent monitoring processes during the execution phase of the project. QA [quality assurance] and change control processes are considered main support processes in the methodology.

4.18 IMPLEMENTING THE METHODOLOGY

Just because a methodology exists does not mean that it is a world-class methodology. Methodologies are nothing more than pieces of paper. What converts a standard methodology into a world-class one is the culture of the organization and the way the methodology is implemented.

The existence of a world-class methodology does not by itself constitute excellence in project management. Its corporate-wide acceptance and use do lead to excellence. It is through excellence in execution that an average methodology becomes a world-class methodology.

One company developed an outstanding methodology for project management. About one-third of the company used the methodology and recognized its true long-term benefits. The other two-thirds of the company would not support the methodology. The president eventually restructured the organization and mandated the use of the methodology.

The importance of execution cannot be overestimated. One characteristic of companies with world-class project management methodologies is that they have world-class managers throughout their organization.

Rapid development of a world-class methodology mandates an executive champion, not merely an executive sponsor. Executive sponsors generally are on an as-needed basis. Executive champions, in contrast, are hands-on executives who drive the development and implementation of the methodology from the top down. Most companies recognize the need for the executive champion. However, many companies fail to recognize that the executive champion position is lifelong. One Detroit company reassigned its executive champion after a few successes were realized using the methodology. As a result, no one was promoting continuous improvement to the methodology.

Good project management methodologies allow you to manage your customers and their expectations. If customers believe in your methodology, then they usually understand it when you tell them that no further scope changes are possible once you enter a specific life-cycle phase. One automotive subcontractor carried the concept of trust to its extreme by inviting customers to attend its end-of-phase review meetings. This fostered extreme trust between the customer and the contractor. The contractor did ask the customer to leave during the last 15 minutes of the end-of-phase review meetings, when project finances were being discussed.

Project management methodologies are an “organic” process, which implies that they are subject to changes and improvements. Typical areas of methodology improvement might include:

• Improved interfacing with suppliers
• Improved interfacing with customers
• Better explanation of subprocesses
• Clearer definition of milestones
• Clearer role delineation of senior management
• Recognition of the need for additional templates
• Recognition of the need for additional metrics
• Template development for steering committee involvement
• Enhancement of the project management guidebook
• Ways to educate customers on how the methodology works
• Ways of shortening baseline review meetings

4.19 IMPLEMENTATION BLUNDERS

Even though companies recognize the driving forces that indicate a need for project management improvement, the actual decision to make an investment to do it may not happen until some crisis occurs or a significant amount of red ink appears on the company’s balance sheet. Recognizing a need is a lot easier than doing something about it because doing it requires time and money. Too often, executives procrastinate giving the go-ahead in hopes that a miracle will occur and project management improvements will not be necessary. And while they procrastinate, the situation often deteriorates further. Consider the following comments from Carl Manello, PMP, vice president of IT at Ameritas Insurance:

I find that the greatest motivation for my clients to invest in improvements is how they view the impact of project management on their initiatives. When their track record at driving large scale business initiatives is less than stellar (lacking sufficient process, methods, tools or skills), they begin to understand the need to invest. Unrealized project implementations, blown budgets and poor quality all speak loudly and capture the attention of senior executive management. The challenge is instead to arrest executive attention before millions of dollars are squandered.

At first, many corporations are unlikely to want to invest in improving PM infrastructure like the PMf [project management foundations]. “There are real projects with hard-core benefits to be realized instead.” However, after these same organizations begin to struggle, understand their weaknesses and the need for improvement in basic project management, they begin to focus on those improvements.

Delayed investment in project management capabilities is just one of many blunders. Another common blunder, which can occur in even the best companies, is the failure to treat project management as a profession. In some companies, project management is a part-time activity to be accomplished in addition to one’s primary role. The career path opportunities come from the primary role, not through project management. In other companies, project management may be regarded merely as a specialized skill in the use of scheduling tools. Carl Manello continues:

While the PMI has done a super job, especially in the last 10 years, advocating project management as a specialized skill that should be left to the professionals, I find that many companies still believe project management is a skill, not a profession. Whether in marketing or engineering organizations, someone is often randomly assigned to be the project manager, regardless of their training, demonstrated skill level or capabilities as a project manager. This lack of attention to project management as a profession may be one of the contributing factors to projects around the world which continue to perform poorly. Too many projects do not have qualified experienced project managers at the helm.

4.20 OVERCOMING DEVELOPMENT AND IMPLEMENTATION BARRIERS

Making the decision that the company needs a project management methodology is a lot easier than actually implementing it. Several barriers and problems surface well after the design and implementation team begins their quest. Typical problem areas include:

• Should we develop our own methodology or benchmark best practices from other companies and try to use their methodology in our company?
• Can we get the entire organization to agree on a singular methodology for all types of projects or must we have multiple methodologies?
• If we develop multiple methodologies, how easy or difficult will it be for continuous improvement efforts to take place?
• How should we handle a situation where only part of the company sees a benefit in using this methodology and the rest of the company wants to do its own thing?
• How do we convince employees that project management is a strategic competency and the project management methodology is a process to support this strategic competency?
• For multinational companies, how do we get all worldwide organizations to use the same methodology? Must it be intranet based?

These are typical questions that plague companies during the methodology development process. These challenges can be overcome, and with great success, as illustrated by the companies identified in the next sections.

4.21 WÄRTSILÄ: RECOGNIZING THE NEED FOR SUPPORTING TOOLS²²

Although we have always had a strong passion for engines at Wärtsilä, we are now much more than an engine company. Today, professional project management has become essential for our continuing success due to the bigger and more complex marine and power plant projects we deliver.

4.22 GENERAL MOTORS POWERTRAIN GROUP

For companies with small or short-term projects, project management methodologies may not be cost-effective or appropriate. For companies with large projects, however, a workable methodology is mandatory. General Motors (GM) Powertrain Group is another example of a large company achieving excellence in project management. The company’s business is based primarily on internal projects, although some contract projects are taken on for external customers. The size of the group’s projects ranges from $100 million to $1.5 billion or greater. Based in Pontiac, Michigan, the GM Powertrain Group developed and implemented a four-phase project management methodology that has become the core process for its business. The company decided to go to project management in order to get its products out to the market faster. According to Michael Mutchler, former vice president and group executive:

The primary expectation I have from a product-focused organization is effective execution. This comprehends disciplined and effective product program development, implementation, and day-to-day operations. Product teams were formed to create an environment in which leaders could gain a better understanding of market and customer needs; to foster systems thinking and cross-functional, interdependent behavior; and to enable all employees to understand their role in executing GM Powertrain strategies and delivering outstanding products. This organizational strategy is aimed at enabling a large organization to be responsive and to deliver quality products that customers want and can afford.

The program management process at GM Powertrain was based on common templates, checklists, and systems. Several elements that were common across all GM Powertrain programs during the 1990s are listed next.

• Charter and contract
• Program team organizational structure with defined roles and responsibilities
• Program plans, timing schedules, and logic networks
• Program-level and part-level tracking systems
• Four-phase product development process
• Change management process

Two critical elements of the GM Powertrain methodology were the program charter and program contract. The program charter defined the scope of the program with measurable objectives, including:

• Business purpose
• Strategic objective
• Results sought from the program
• Engineering and capital budget
• Program timing

The program contract specifies how the program will fulfill the charter. The contract became a shared understanding of what the program team will deliver and what the GM Powertrain staff will provide to the team in terms of resources, support, and so on.

Although the information here on GM Powertrain may appear somewhat dated, it shows that GM was several years ahead of most companies in the development of an EPM methodology. GM has made significant changes to its methodology since then. Many companies are just beginning to develop what GM accomplished more than a decade ago. Today, GM uses the above-mentioned methodology for new product development and has a second methodology for software projects.

4.23 ERICSSON TELECOM AB

General Motors Corporation and the bank (discussed in section ) were examples of project management methodologies that were internal to the organization (i.e., internal customers). For Ericsson Telecom AB, the problem is more complicated. The majority of Ericsson’s projects were for external customers, and Ericsson had divisions all over the world. Can a methodology be developed to satisfy these worldwide constraints?

In 1989, Ericsson Telecom AB developed a project management methodology called PROPS.²³ Although it was initially intended for use at Business Area Public Telecommunications for technical development projects, it has been applied and appreciated throughout Ericsson worldwide, in all kinds of projects. In the author’s opinion, PROPS is one of the most successful methodologies in the world.

New users and new fields of applications have increased the demands on PROPS. Users provide lessons-learned feedback so that their shared experiences can be used to update PROPS. In 1994, a second generation of PROPS was developed, including applications for small projects, concurrent engineering projects, and cross-functional projects and featuring improvements intended to increase quality on projects.

PROPS is generic in nature and could be used in all types of organizations, which strengthened Ericsson’s ability to run projects successfully throughout the world. PROPS could be used on all types of projects, including product development, organizational development, construction, marketing, single projects, large and small projects, and cross-functional projects.

PROPS focuses on business, which means devoting all operative activities to customer satisfaction and securing profitability through effective use of company resources. PROPS uses a tollgate concept and project sponsorship to ensure that projects are initiated and procured in a business-oriented manner and that the benefits for the customer as well as for Ericsson are considered.

The PROPS model is extremely generic, which adds flexibility to its application to each project. The four cornerstones of the generic project model are:

1. Tollgates
2. The project model
3. The work models
4. Milestones

Tollgates are superordinate decision points in a project at which formal decisions are made concerning the aims and execution of the project, according to concepts held in common throughout the company. Five tollgates constitute the backbone of the PROPS model. The function and position of the tollgates are standardized for all types of projects. Thus, the use of PROPS ensures that the corporate tollgate model for Ericsson is implemented and applied.

The project sponsor makes the tollgate decision and takes the overall business responsibility for the entire project and its outcome. A tollgate decision must be well prepared. The tollgate decision procedure includes assessment and preparation of an executive summary, which provides the project sponsor with a basis for the decision. The project and its outcome must be evaluated from different aspects: the project’s status, its use of resources, and the expected benefit to the customer and to Ericsson. At the five tollgates, the following decisions are made:

• Decision on start of project feasibility study
• Decision on project execution
• Decision on continued execution, confirmation of the project or revision of limits, implementation of design
• Decision on making use of the final project results, handover to customer, limited introduction on the market
• Decision on project conclusion

The project model describes which project management activities to perform and which project documents to prepare from the initiation of a prestudy to the project’s conclusion. The project sponsor orders the project and makes the tollgate decisions; most of the other activities described in the project model are the responsibility of the project manager. The project model is divided into four phases: prestudy, feasibility study, execution, and conclusion phases.

The purpose of the prestudy phase is to assess feasibility from technical and commercial viewpoints based on the expressed and unexpressed requirements and needs of external and internal customers. During the prestudy phase, a set of alternative solutions is formulated. A rough estimate is made of the time schedule and amount of work needed for the project’s various implementation alternatives.

The purpose of the feasibility study phase is to form a good basis for the future project and prepare for the successful execution of the project. During the feasibility study, different realization alternatives and their potential consequences are analyzed, as well as their potential capacity to fulfill requirements. The project goals and strategies are defined, project plans are prepared, and the risks involved are assessed. Contract negotiations are initiated, and the project organization is defined at the comprehensive level.

The purpose of the execution phase is to execute the project as planned with respect to time, costs, and characteristics in order to attain the project goals and meet customer requirements. Technical work is executed by the line organization according to the processes and working methods that have been decided on. Project work is actively controlled; that is, the project’s progress is continuously checked, and the necessary action is taken to keep the project on track.

The purpose of the conclusion phase is to break up the project organization, to compile a record of the experiences gained, and to see to it that all outstanding matters are taken care of. During the conclusion phase, the resources placed at the project’s disposal are phased out, and measures are suggested for improving the project model, the work models, and the processes.

Besides describing the activities that will be performed to arrive at a specific result, the work model also includes definitions of the milestones. However, to get a complete description of the work in a specific project, one or more work models should be defined and linked to the general project model. A work model combined with the general project model is a PROPS application. If there are no suitable work models described for a project, it is the project manager’s responsibility to define activities and milestones so that the project plan can be followed and the project can be actively controlled.

A milestone is an intermediate objective that defines an important, measurable event in the project and represents a result that must be achieved at that point. Milestones link the work models to the project model. Clearly defined milestones are essential for monitoring progress, especially in large and/or long-term projects. Besides providing a way of structuring the time schedule, milestones will give early warning of potential delays. Milestones also help to make the project’s progress visible to the project members and the project sponsor. Before each milestone is reached, a milestone review is performed within the project in order to check the results achieved against the milestone criteria. The project manager is responsible for the milestone review.

Ericsson’s worldwide success can be partially attributed to the acceptance and use of the PROPS model. Ericsson has shown that success can be achieved with even the simplest of models and without the development of rigid policies and procedures.

4.24 INDRA: CLOSING THE PROJECT²⁴

In a technological company like Indra, with projects being managed to develop, manufacture, and maintain complex hardware and software systems, an immature project closure can be, if not well treated, a cause of great efficiency losses.

Projects usually require a curve of effort with the peak at the beginning and half of a project life cycle. (See Figure 4-22.) Or in other words, from the project manager point of view, planning and monitoring and control are the phases that require more attention.

During planning stage, project manager works toward clear goals. At the same time, planning depends on established commitments with either the sponsor or the customer. While in the monitoring and control stages, the project manager’s attention is focused on coordinating team efforts to achieve project milestones, identifying variances to baselines, and protecting the project from changes, which really take most of the manager’s time.

This is not the case at the end of the project: When commitments are fulfilled, most of the pressure on project management is removed. This occasionally means that the last of the milestones (project closure) is not properly achieved, as PM attention and effort has been reduced. A new assignment might be waiting for the project manager, so she is released to start the new responsibility without properly closing the previous one.

In the context of an organization like Indra, whose main business is delivering project results to its customers, we intend to organize our resources in the most efficient manner, responding effectively to all commitments to customers in a business improvement framework.

Project managers may have little motivation to perform a good project closure; they may consider it to be a simple and administrative task. Therefore, they might forget that if we don’t pay attention to the opportunity to consolidate the efficiencies that were gained in the project, that benefit can be lost for the organization, particularly in the management of scope and resources (and scope and resources are the main values used to calculate productivity).

If we focus on scope management, if project closure is not well done, there is a risk that the customer might dilute, reopen, or reinterpret acceptance agreements of the deliverables. This happens if the project end is not well settled and if it is confused and mixed with the warranty period.

Consider this: After a new system is established, a customer’s needs may change, and this may mean that the interpretation of the requirements must evolve also. No longer can the requirements be traced to the initial project scope and former conditions of validation. As time passes, the perceptions of the person at the client who performs the requirements validation on deliverables may change without formal project closure. Then the customer may try to relocate new needs back on the project instead of placing them in a project extension, as they should be.

When managing a project based on agile models, which are so popular today, it is especially advisable to pay particular attention to the efforts dedicated to customer requirements acceptance.

If we focus on management of resources, several organizational staffing roadblocks can occur; one of the most frequent is the failure to release resources from our project to others. This lowers the productivity gained during the project. Another potential negative effect of poor project closure is a lack of methodological focus, with the process instead being redirected to managing reactions to change events and incidents. This risks that the changes, scope, improvements, and responsibilities that were properly negotiated by the project manager during other stages of the project will be jeopardized.

This concern has led Indra to improve project closure practices by implementing in the PMIS of a group of facilitators:

• The possibility of beginning of project closure activities early, by overlapping this phase with the previous phase (e.g., in cases where scope is cut or there is a planned closure date)
• The use of information the PMIS has accumulated from the project over its lifetime to help identify situations that could prevent formal closure
• The use of indicators and reports associated with project closure, tracking its status
• Linking lessons learned to updates to the PMIS, which allows searches in previous experiential knowledge; this could affect the closing process (and other processes) by requiring more time to capture lessons learned

The Spanish saying “Close the door [or] the cat will escape” shows the risks that organizations face if project closure is not properly done. If we don’t close the door, the project escapes; in other words, risks that were controlled at one point ultimately may still occur. Project managers who do not perform project closure carefully may be adding great risks to the project, risks that had been under control during earlier phases when the project manager’s effort and attention were high.

4.25 ROCKWELL AUTOMATION: QUEST FOR A COMMON PROCESS²⁵

Rockwell Automation was formed by bringing two major automation companies together in the late 1980s. These two companies, Allen-Bradley and Reliance Electric, were the foundation of what is now Rockwell Automation. Over the years, Rockwell Automation has continued to acquire leading automation suppliers as a growth strategy and also as a way to bring new advanced automation technologies into the company. In 2005, as Rockwell Automation was planning the roll-out of a new SAP business system, we recognized the need for a new “common” product development process that would be defined based on company best practices combined with what was considered the industry’s best practices for product development. This effort resulted in a “common product development” process that was defined in a way to allow for enterprisewide adoption. This is shown in Figure 4-23. This means that 16 different product businesses ranging from high-volume component suppliers to complex continuous process control systems solution suppliers all use the same high-level process framework for their new product developments.

The resulting process is made up of six phases with a stage-gate review after each phase. The six phases are:

1. Consideration
   • To develop a high-level business case and project proposal to justify AR1 funding for the execution of initiation and feasibility phase activities.

2. Initiation

   • To refine the high-level business case document created in the consideration phase into a set of customer requirements sufficient for the project team to create solution concepts, product requirement, and functional requirement documents in the feasibility phase. (See Figure 4-24.)

3. Feasibility

   • To evaluate solution concepts to address the customer requirements from the initiation phase.
   • To define the product requirements and functional requirements.
   • To complete all project planning and scheduling to update the project plan for all activities and resources required to complete the execution, release, and closeout phases of the project.
   • To develop a business case document that justifies the investment required to execute the project plan for the solution concept chosen. (See Figure 4-25.)
4. Execution
   • To develop the product or service according to the baselined functional requirement specification from the feasibility phase, performing the necessary reviews and making approved requirement and/or design changes as the project progresses.
5. Release
   • To finalize all test, certification, and other product verification documentation.
   • To build and validate pilot production.
   • To open for order entry and execute the commercial launch.
6. Close
   • To position the product for transition to continuation/sustaining engineering; documentation cleanup, postmortems, lessons learned, record retention, and complete all financial transactions.

Our goal was to achieve a rapid, repeatable framework that consistently results in high-quality output. A major focus of the team that produced this new process was to drive the product businesses to be more disciplined in how innovation was embraced when deciding what projects proposals were funded and which ones were not. There were too many examples of projects receiving management support and funding without meeting a set of minimum criteria that would result in a higher probability of commercial success. Investment proposals were not always based on an ideation process that was driven by our customers.

We found examples of funded projects enjoying support and funding without any customer-driven commercial basis. The justification for these projects was based on new interesting technologies, investing in product family coverage for the sake of coverage without real market demand, providing niche solutions with limited potential driven by a single customer, and others.

To solve this problem, the team’s original focus was on two aspects of what was defined as best practice. Numerous theories attempt to describe the best way to capture customer needs and use them as the basis for creating effective new product concepts. Our goal was to understand customer problems before we produced solution concepts and product solutions. We accomplished this goal by breaking apart an existing tool called the Marketing Requirements Document, a process used by product management, into two tools.

We wanted product owners to understand the market and target customer’s problems before they considered solutions. By breaking the Marketing Requirements Document into two deliverables, the Customer Requirements Document focused on the market need and customer problems and the Product Requirements Document focused on the solution concepts and product requirements, and locating these tools and activities in separate phases divided by a management stage-gate review, we forced our product managers to break away from the death march of continuously evolving the product that we were on.

Of course, accepted practice and company culture is hard to break so governance is critical in driving change. The simple step of providing governance is the beginning of what will be a significant improvement in the new product development practices of this company.

The driving force behind management’s commitment to implement any new process and to drive the cultural change was the vision of a common consistent methodology for new product development across the enterprise. This consistency was prioritized from the top (direct management involvement in the stage-gate reviews) down, in order to realize benefits as soon as possible.

All too often, businesses are forced to deny funding for strategic projects due to never-ending incremental product improvements that just keep coming. By forcing business management to approve each project’s passage from one phase to the next, we pushed the visibility of every project, every resource, and every dollar up to the decision makers who wrestled with trying to find dollars to fund the real game-changers. This visibility made it easier for business owners to kill projects with questionable returns or to delay a project in order to free up critical resources. Once management began to see the returns from these decisions in the form of product introductions that really moved the needle, we began to focus on fine-tuning the process and methodologies employed. (See Figure 4-26.)

The stage-gate review is the most important event of a project. Under the old way of executing a project, these reviews were informal and haphazard. Teams were able to continue spending and even overspending without any real fear of project cancellation. This new process ensures that every dependent organization is represented at the appropriate review and given the chance to agree or disagree with the project manager that all deliverables are available. The intent is to have the go/no-go decision made by both the primary organization responsible for the deliverables during the previous phase and the primary organization responsible for the deliverables in the subsequent phase. Both these organizations are required at each stage-gate review. If done correctly, we will be able to avoid surprises during the later phases by ensuring transparency during the earlier phases.

Once a project manager is assigned and a project team is formed, the importance of well-defined deliverables that are easy to locate and use became evident. The 12 months following the original launch of the new process was spent continuously improving the phase definitions, procedure documents, deliverable templates, and governance policies. There is a fine line between rigor and burden; the trick is to push this line hard to ensure rigorous implementation without slowing the progress of the project team down.

At the end of the feasibility phase, as the project enters the execution phase with requested funding secured, the project plan becomes the bible. The project plan drives all activities through the execution phase, release phase, and finally project close. Any issue that the project team is faced with that requires a change in course must be recognized in an updated project plan. At the conclusion of the project, the plan must represent what actually occurred. Prior to any new product being released for customer shipment, all impacted stakeholders must agree that the product is ready before they give the final approval.

The company is built from many related but very different product businesses. Each business segment was at a different maturity level relative to all aspects of product development, even the existence of a formal project management organization

Project managers are instrumental in the execution of a product development process. If consistency, transparency, and risk mitigation are important to a business, and they are to Rockwell Automation, then a formal, well-recognized and managed project management entity is paramount.

Rockwell Automation is pursuing the discipline of project management at all levels in its organization.

4.26 SHERWIN-WILLIAMS²⁶

There are several ways that a company can develop a methodology for project management. Outsourcing the development process to another company can be beneficial. Some companies have template methodologies that can be used as a basis for developing their own methodology. This can be beneficial if the template methodology has enough flexibility to be adaptable to the organization. The downside is that the end result of this approach may not fit the needs of the organization or the company’s culture. Hiring outside consultants may improve the situation a little, but the end result may still be unfavorable as well as more costly. This approach may require keeping contractors on the payroll for a long time such that they can fully understand the company’s culture and the way it does business.

Benchmarking may be effective, but by the time the benchmarking is completed, the company could have begun developing its own methodology. Another downside risk of benchmarking is that the company may not be able to get all of the needed information or the supporting information to make the methodology work.

Companies that develop their own methodology internally seem to have greater success, especially if they incorporate their own best practices and lessons learned from other activities. This occurred in most of the companies in this book.

* * *

4.27 HEWLETT-PACKARD²⁷

Many clients have a project management methodology. In addition, most companies have several methodologies that include project management disciplines. Hewlett-Packard (HP) has been successful in integrating the definitive project management method into the other methodologies to allow for leveraging of project management standards and tools without duplication.

For the management of an enterprise IT environment, we have developed a client-facing framework called the Information Technology Enterprise Management (ITEM). This framework assists the client to map their strategic direction into feasible releases. ITEM is a preintegrated framework of three models and a methodology, as illustrated in Figure 4-27.

Prior to the release of ITIL the 2007 edition, we identified a gap for managing the life cycle of a service and developed what we called back then the Release Management Methodology, which consisted of four stages (Planning, Integration, Deployment and Operations). Each stage consists of phases—activities—tasks. This is shown in Table 4-3.

Since then, ITIL has introduced the life-cycle approach in the 2007 and 2011 editions. Their stages—Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Operation—are almost an exact match to our RMM [Release Management Methodology] stages. Since the rollout of 2007, we have maintained much of our collateral, since the new ITIL editions did not provide a comprehensive work breakdown structure. We simply matched our WBS to the overall goals and contents of the ITIL life-cycle framework. That is an illustration of how we continually evolve our practices and continually apply industry advances.

Basically, we used the 9 × 9 rule, as shown in Figure 4-28. If there are more than nine phases across a stage and more than nine activities to each phase (81 total units of work), then the scope will become too large, and our numbering scheme will become unstable.

4.28 AIRBUS SPACE AND DEFENCE: GOLDEN RULES IN PROJECT MANAGEMENT²⁸

All of the companies discussed in this chapter have excellent methodologies for project management. When a company captures best practices in project management and relates it to the methodology, then the company can develop “Golden Rules in Project Management.” The remainder of section has been provided by Airbus Space and Defence¹⁵ and provides excellent examples of how project management should work for the benefits and value to be achieved. This material is also representative of what the outcome may be from the journey to excellence in project management as discussed in Chapter 3.

* * *

4.29 WHEN TRADITIONAL METHODOLOGIES MAY NOT WORK

While methodologies serve a viable purpose, traditional methodologies may not work well when projects become distressed and rapid action is required to save a failing project. In such a case, other factors may become more important than following the traditional life-cycle phases.