Urgenthomework logo
Live chat


Project Execution Case Study

Controlling projects is a necessity such that meaningful and timely information can be obtained to satisfy the needs of the project’s stakeholders. This includes measuring resources consumed, measuring status and accomplishments, comparing measurements to projections and standards, and providing effective diagnosis and replanning.

For cost control to be effective, both the scheduling and estimating systems must be somewhat disciplined in order to prevent arbitrary and inadvertent budget or schedule changes. Changes must be disciplined and result only from a deliberate management action. This includes distribution of allocated funds and redistribution of funds held in reserve.

The Two-Boss Problem

On May 15, 2001, Brian Richards was assigned full-time to Project Turnbolt by Fred Taylor, manager of the thermodynamics department. All work went smoothly for four and one-half of the five months necessary to complete this effort. During this period of successful performance Brian Richards had good working relations with Edward Compton (the Project Turnbolt engineer) and Fred Taylor.

Fred treated Brian as a Theory Y employee. Once a week Fred and Brian would chat about the status of Brian’s work. Fred would always conclude their brief meeting with, “You’re doing a fine job, Brian. Keep it up. Do anything you have to do to finish the project.”

During the last month of the project Brian began receiving conflicting requests from the project office and the department manager as to the preparation of the final report. Compton told Brian Richards that the final report was to be assembled in viewgraph format (i.e., “bullet” charts) for presentation to the customer at the next technical interchange meeting. The project did not have the funding necessary for a comprehensive engineering report.

The thermodynamics department, on the other hand, had a policy that all engineering work done on new projects would be documented in a full and comprehensive report. This new policy had been implemented about one year ago when Fred Taylor became department manager. Rumor had it that Fred wanted formal reports so that he could put his name on them and either publish or present them at technical meetings. All work performed in the thermodynamics department required Taylor’s signature before it could be released to the project office as an official company position. Upper-level management did not want its people to publish and therefore did not maintain a large editorial or graphic arts department. Personnel desiring to publish had to get the department manager’s approval and, on approval, had to prepare the entire report themselves, without any “overhead” help. Since Taylor had taken over the reins as department head, he had presented three papers at technical meetings.

A meeting was held between Brian Richards, Fred Taylor, and Edward Compton.

Edward: “I don’t understand why we have a problem. All the project office wants is a simple summary of the results. Why should we have to pay for a report that we don’t want or need?”

Fred: “We have professional standards in this department. All work that goes out must be fully documented for future use. I purposely require that my signature be attached to all communications leaving this department. This way we obtain uniformity and standarization. You project people must understand that, although you can institute or own project policies and procedures (within the constraints and limitations of company policies and procedures), we department personnel also have standards. Your work must be prepared within our standards and specifications.”

Edward: “The project office controls the purse strings. We (the project office) specified that only a survey report was necessary. Furthermore, if you want a more comprehensive report, then you had best do it on your own overhead account. The project office isn’t going to foot the bill for your publications.”

Fred: “The customary procedure is to specify in the program plan the type of report requested from the departments. Inasmuch as your program plan does not specify this, I used my own discretion as to what I thought you meant.”

Edward: “But I told Brian Richards what type of report I wanted. Didn’t he tell you?”

Fred: “I guess I interpreted the request a little differently from what you had intended. Perhaps we should establish a new policy that all program plans must specify reporting requirements. This would alleviate some of the misunderstandings, especially since my department has several projects going on at one time. In addition, I am going to establish a policy for my department that all requests for interim, status, or final reports be given to me directly. I’ll take personal charge of all reports.”

Edward: “That’s fine with me! And for your first request I’m giving you an order that I want a survey report, not a detailed effort.”

Brian: “Well, since the meeting is over, I guess I’ll return to my office (and begin updating my résumé just in case).”

The Bathtub Period

The award of the Scott contract on January 3, 1987, left Park Industries elated. The Scott Project, if managed correctly, offered tremendous opportunities for follow-on work over the next several years. Park’s management considered the Scott Project as strategic in nature.

The Scott Project was a ten-month endeavor to develop a new product for Scott Corporation. Scott informed Park Industries that sole-source production contracts would follow, for at least five years, assuming that the initial R&D effort proved satisfactory. All follow-on contracts were to be negotiated on a year-toyear basis.

Jerry Dunlap was selected as project manager. Although he was young and eager, he understood the importance of the effort for future growth of the company. Dunlap was given some of the best employees to fill out his project office as part of Park’s matrix organization. The Scott Project maintained a project office of seven full-time people, including Dunlap, throughout the duration of the project. In addition, eight people from the functional department were selected for representation as functional project team members, four full-time and four half-time.

Although the workload fluctuated, the manpower level for the project office and team members was constant for the duration of the project at 2,080 hours per month. The company assumed that each hour worked incurred a cost of $60.00 per person, fully burdened.

At the end of June, with four months remaining on the project, Scott Corporation informed Park Industries that, owing to a projected cash flow problem, follow-on work would not be awarded until the first week in March (1988). This posed a tremendous problem for Jerry Dunlap because he did not wish to break up the project office. If he permitted his key people to be assigned to other projects, there would be no guarantee that he could get them back at the beginning of the follow-on work. Good project office personnel are always in demand.

Jerry estimated that he needed $40,000 per month during the “bathtub” period to support and maintain his key people. Fortunately, the bathtub period fell over Christmas and New Year’s, a time when the plant would be shut down for seventeen days. Between the vacation days that his key employees would be taking, and the small special projects that this people could be temporarily assigned to on other programs, Jerry revised his estimate to $125,000 for the entire bathtub period.

At the weekly team meeting, Jerry told the program team members that they would have to “tighten their belts” in order to establish a management reserve of $125,000. The project team understood the necessity for this action and began rescheduling and replanning until a management reserve of this size could be realized. Because the contract was firm-fixed-price, all schedules for administrative support (i.e., project office and project team members) were extended through February 28 on the supposition that this additional time was needed for final cost data accountability and program report documentation.

Jerry informed his boss, Frank Howard, the division head for project management, as to the problems with the bathtub period. Frank was the intermediary between Jerry and the general manager. Frank agreed with Jerry’s approach to the problem and requested to be kept informed.

On September 15, Frank told Jerry that he wanted to “book” the management reserve of $125,000 as excess profit since it would influence his (Frank’s) Christmas bonus. Frank and Jerry argued for a while, with Frank constantly saying, “Don’t worry! You’ll get your key people back. I’ll see to that. But I want those uncommitted funds recorded as profit and the program closed out by November 1.”

Jerry was furious with Frank’s lack of interest in maintaining the current organizational membership.


  1. Should Jerry go to the general manager?
  2. Should the key people be supported on overhead?
  3. If this were a cost-plus program, would you consider approaching the customer with your problem in hopes of relief?
  4. If you were the customer of this cost-plus program, what would your response be for additional funds for the bathtub period, assuming cost overrun?
  5. Would your previous answer change if the program had the money available as a result of anunderrun?
  6. How do you prevent this situation from recurring on all yearly follow-on contracts?

Ford Motor Co.: Electrical/Electronic Systems Engineering

Ford Motor Co. has revenues of $164.196 billion and 327,531 employees worldwide. The Electrical/Electronic Systems Engineering department develops electrical systems valued at $800 to $1,000 at cost to more than eighty vehicle programs. The department consists of approximately 740 staff resources, with electrical program management teams comprising about twenty-five engineering resources each.

The Electrical/Electronic Systems Engineering department has four functional engineering areas, each with its own chief engineer:

  1. North America Truck
  2. North America Car
  3. Commodity and Application Engineering
  4. E/E Software and Modeling

This department is aligned with the product creation mission of Ford— “Great Products . . . More Products . . . Faster”—that outlines the priorities for the department:

  • Improve quality.
  • Improve quality (intentionally repeated).
  • Develop exciting products.
  • Achieve competitive cost and revenue. Build relationships.

Additionally, Ford’s Electrical/Electronic Systems Engineering department has aligned with the company’s key focus areas for department communication and processes. To “intensify communications,” the department stresses the following:

  • Communicate consistently.
  • Focus on vital few priorities.
  • Keep the message simple.
  • Help people prioritize.
  • Remove barriers.

The department also emphasizes that each team member should improve working processes by simplifying, stabilizing, standardizing, setting cadence, and sustaining.

By using these principles across all product development commodities, the department has achieved a reduction in engineering errors, as well as higher engineer engagement.


Examining project management at Ford revealed three best practices. First is Ford’s executive sponsorship of an Electrical/Electronic Systems Engineering project management office. This office standardizes project management and engineering processes across its internal functional areas and the electrical program management team. It also acts as a single governance board for the project management office framework. The department’s directors, chiefs, and the electrical business planning and technology office participate in the governance board through weekly project management meetings to provide support and shift priorities as required.

Second, professional project managers consult on the implementation, execution, and maintenance of the project management office, as well as assisting with the transfer of project management knowledge for the organization.

Additionally, the Electrical/Electronic Systems Engineering department has internalized project management as a discipline in engineering and provided training to the entire organization, with follow-up auditing processes in place for implemented projects. It has always been Ford’s intent for engineers to develop competencies in the area and build an in-house project management discipline.

Managing Resistance

Transferring the leadership and ownership of project management from professional project managers to the engineering division has allowed further entrenching of the organization’s goal of increasing project management maturity and has produced positive results.

Senior-level managers in the organization expect 100 percent compliance with the project management tools and methodologies developed by the project management office and approved by the governance board. They approached the changes as sustained continuous improvement and took the time to listen to comments and criticism from the people in the framework, which resulted in less overall resistance than was expected.

Another method used by the Electrical/Electronic Systems Engineering department to counter resistance was to design the project management office framework around stakeholder participation. All organization personnel can participate in the project management office tools and methodology discussions at the management level, as well as the project management office working level meetings. This level of participation in the organization helps build the best practice process.


Project Definition

The Electrical/Electronic Systems Engineering project management office acts as the central project manager to standardize projects. The office engages defined projects that usually have a short time frame with a clearly defined scope and a clear allocation of resources. Long-term technical or business planning projects are handled outside of the project management office. Although these projects may interact with the office, it does not directly manage them.

Project Management Organization/Methodology

The Electrical/Electronic Systems Engineering department’s project management office comprises three levels.

  1. The governance board of executive directors and engineering chiefs. This small body prioritizes projects according to the corporate scorecard. The group includes two executive directors and four engineering chiefs and sets the tone for the department’s overall level of project management excellence.
  1. Stakeholders. This group includes members of the department that participate either regularly or sporadically in approved projects, usually as subject matter experts. These resources provide technical knowledge regarding the various engineering disciplines and tools.
  2. Professional project managers. These staff members are from the project management-consulting firm retained by the department. Their duties include participating in cascaded/prioritized projects, developing project execution plans and work plans, performing audit processes, and facilitating team formation and execution of deliverables in a specified timeline and scope as approved by the governance board. The professional project managers also developed a change management process for updating existing project management tools on an as-needed basis.

The professional firm of Pcubed Inc. is considered the owner of the project management methodology employed at Ford Motor Company. This methodology is aligned with the Project Management Body of Knowledge (PMBOK® Guide), PMI, and PM Berkeley Maturity models, which are the recognized industry standards. The approach comprises three phases.

  1. Discover and define. The objective during this phase is to assess the overall health and baseline project management process.
  2. Develop and deliver. The Phase 2 objective is to develop and pilot the recommended solutions to address the needs identified in Phase 1.
  3. Deploy and drive. The last objective is to ensure solutions are fully implemented across the department.

Project Managers/Teams

Five to eight full-time professional project managers staff the Electrical/ Electronic Systems Engineering project management office per quarter, depending on the project needs. The project management office reports its general project scope recommendations or issues to the Electrical/Electronic Systems Engineering department business office manager prior to those recommendations/issues being elevated to the governance board review process, where they are then reviewed by directors and engineering chiefs.

The relationship between the project management office and the functional areas is clearly structured, with the project management office as the focal point for all project management processes. The functional teams do not have the authority to influence or overrule the directives managed by the project management office. In 2004, the project management office began to work with the Electrical/Electronic Systems Engineering department to identify resources that will participate in an increased capacity based on the job families for engineers with project management responsibilities.

The composition of a typical Electrical/Electronic Systems Engineering department project team and the corresponding roles and responsibilities include the following:

  • The project manager. This person leads the project execution plan development. This also includes gathering the necessary resources, as well as defining the scope, deliverables and time line for the project.
  • The stakeholders. Usually, they are subject-matter experts who provide feedback about the project deliverables.
  • The governance board. The board reviews the progress of the project and gives the necessary approval or rejections for recommendations.

In some instances, the stakeholders take the lead role, and the project management office acts as coordinator or facilitator.

Currently, the Electrical/Electronic Systems Engineering department identifies resources and potential leaders using the individual development plan, a tool completed by the department’s engineers. Resources identified for advance training take on permanent leadership roles in the organization. Some of these resources will have only part-time responsibilities for project management, and others will be used full-time to manage the project management office.

To maintain the structure necessary for consistent project delivery while allowing for changing circumstances, the project management office and the governance board review projects’ status monthly and make any necessary recommendations. Stakeholders also meet monthly for change control of project management tools and processes. This is the formal change control process for any methodology improvements to existing projects. The project scope can be modified as necessary to manage changes to the original project assumptions. The suggested revisions are always reviewed by the top two levels of the project management structure (governance board and stakeholder team), and any revisions are taken from their directions.

Ford used the Berkeley Project Management Maturity Model to quantify the needs assessment results across the project management disciplines and the project life cycle. Level one of the Berkeley Maturity Model is the ad hoc stage, where no formal procedures or plans to execute exist and where project management techniques are applied inconsistently, if at all. Level two is the planned stage, where informal and incomplete processes are used, and planning and management of projects depend primarily on individuals. Level three is the managed stage, where project management processes demonstrate systematic planning and control and where cross-functional teams are becoming integrated. Level four of the model is the integrated stage. Here, project management processes are formal, integrated, and fully implemented. Lastly, level five is the sustained stage, which involves continuous improvement of the project management processes. At the project management office launch in 2003, the Electrical/Electronic Systems Engineering department had a maturity level rating of 1.85, aligning with the average maturity level of most organizations, which is between level one and two.

At the end of 2003, after the implementation of the project management office and the achievement of an organized approach, an informal review of the organization’s processes moved the rating to 3.0. To continue increasing its maturity level in 2004, the department’s governance board began internalizing the effort to transfer project management knowledge by using technical maturity models, which provide training models, individual development plans, and core training and education online courses in department project management processes. The goal of the department is to internalize competency and to approach project management internally.

Project Management Strategy

The Electrical/Electronic Systems Engineering department has two primary strategies for selecting project management office projects:

  1. Base selection on the corporate scorecard objectives for the given calendar year.
  2. Base selection on the underlying goal of increasing the department’s project management maturity.

The project management strategy aligns with the corporate strategic plan by placing top priority on selecting a project based on its ability to meet the corporate scorecard objectives (i.e., improving the product creation process and engineering disciplines). Other criteria can also include the ability to improve work-related efficiency, standardize reports and processes to improve clarity of data for decision making at the senior level, and realign the organization crossfunctionally to increase project synergies.

The department’s approach to project management has been used to achieve the strategic objectives of the organization in the following ways:

  • The project management office had input into the corporate-level development of the engineering quality operating system. The office also had responsibility for building electrical assessment health charts by system and commodity levels, training the Electrical/Electronic Systems Engineering organization to integrate new corporate reporting tools, implementing an auditing process to ensure proper compliance with procedure, and reporting the efficiency of the organization to senior leadership.
  • The department worked toward realigning the sourcing process with the finance department, cataloged issues via the engineering quality operating system reporting system, and gained the support of the finance department in a joint partnership to improve the supplier sourcing process.
  • The department also maintained continuous improvement projects in product development, such as participating in corporate objectives as they pertain to the processes to improve product creation (e.g., improving time to market and the quality of the product launch).

Resource Assignment

Electrical/Electronic Systems Engineering ensures that adequate project resources are devoted to the upfront project phases (project initiation and planning) by defining project execution plans one month prior to the project kick-off. This plan details the scope, timeline, and required resources. Once the governance board approves this plan, it ensures that sufficient organization resources are enabled, and the project management office matches projects to the skill sets of individual project managers.

To effectively manage geographically dispersed or global project teams, the department uses a clearly defined communication plan, including the scope, timeline, resources, and the necessary communication tools that can facilitate a global meeting such as eRoom or Pictel. It is also important to form the project team early and clearly define the objectives, as well as outline regular status-reporting meetings. Cultural differences that might arise during the project are managed by best practices training. For example, the project leader might make recommendations to the team for specific communication plans, the formality of meetings, or conduct, and might negotiate work-related differences and scope disagreements.

Project Management Professionalism/Training

As discussed previously, advanced project managers in the Electrical/Electronic Systems Engineering department are identified through individual development plans as part of the technical maturity model for project management. Resources identified for advanced training will take on permanent leadership roles in the department, which usually consists of managing projects or the project management office.

Training needs for project managers are also identified by comparing the results of the completed individual personal development plans to the technical maturity model for project management. Resources requiring user/expert level skills will be trained by a variety of sources:

  • Current professional project managers assigned to train them on project management office operations

Building Project Portfolios by Prioritizing Projects

  • Web-based training or seminar training provided by Ford on core project management disciplines
  • Specialized courses developed by the department along with Ford Motor Co. on project management processes, tools, and methodologies

Structuring and Negotiating Project Scope

Professional project managers in the project management office initially prepare the project scope based on a discovery phase approach. The scope is outlined in a project execution plan against the project requirements, timeline, and resources required. Process changes must go through the formal change control process, as outlined earlier, that begins at the monthly stakeholder meeting. Scope changes related to resources are first reviewed with the manager of electrical technology and operations. The governance board must then review the proposed changes before giving its approval or rejection. An adjustment of resources is then made as necessary to meet the approved changes to the scope.

Maintaining Consistency in Project Management Delivery

Overall, the department identifies a number of important ways that it maintains consistency in project management delivery:

  • Project management tools, processes, and methods in the department are standardized.
  • The project management office institutionalizes approved new processes through training of the organization.
  • The project management office audits the correct use of new tools and processes.
  • Monthly change control actions are taken to improve gaps.
  • Processes are available to the organization through the use of eRoom documentation storage.
  • Ongoing organization training and project management pocket cards for engineers are provided.



In Ford’s portfolio management approach, projects are ranked based on the priorities identified by the governance board using the corporate scorecard. Initially, the scopes of the various projects are high level, and the project managers review all requested projects and define the scope with the department’s business operations manager. In 2004 the organization performed an assessment of this approach and plans to make assessments a biannual process.

Allocation of Resources

As previously outlined, the Electrical/Electronic Systems Engineering department allocates resources to projects based on the project priority, scope, and available resources. If reassignment of resources is necessary because of changes to the project or the personnel, then proposed changes are reviewed and approved by the governance board and department’s business office manager. However, the final decision on the prioritization of projects lies with the department’s governance board.

The allocation of development funds or resources to different project types, business areas, market sectors, or product lines again depends on the corporate scorecard objectives, areas requiring process improvements, and an increase in the organization’s project management maturity level. Organization objectives are cascaded by the governance board to the project management office, which develops high-level project plans that the governance board then reviews for approval. To ensure sufficient resources are available for projects, the governance board conducts monthly reviews to monitor strict adherence to the scope management of projects, as well as manage any over-allocation of resources.

The job of ensuring that low-value projects are terminated before consuming resources is primarily that of the project management office’s project manager, governance board, and the Electrical/Electronic Systems Engineering department’s business manager. The feedback on value achievement from these sources is provided monthly. Additionally, a periodic formal project management office survey is administered by the Electrical/Electronic Systems Engineering department’s business operations planning group to the department to rank the effectiveness and use of project management office tools, processes, and project outcomes. The results of the survey are reviewed with the project management office and the governance board to identify areas of improvement and capture lessons learned.

To enhance ongoing management decisions using the project portfolio, Ford uses the engineering quality operating system reporting system to quantitatively measure the success of program delivery across the North American engineering community, including electrical/electronic commodity and deliverables to the program level. This measurement system is designed to review the history and also present the status of progress across the vehicle programs. The project management office has worked on various projects that have facilitated the communication of these status results in a more streamlined manner to help decision-making capabilities. For example, the Electrical/Electronic Systems Engineering department will prioritize “red issues” and track any red issue closures in a database. These progress reports against the closure of red issues are reviewed as high as the vice president level.


Ford uses the engineering quality operating system to measure the success of its projects in the engineering community. Its integrator reporting system captures the status of projects and can report these findings up to the system and program levels.

Additionally, the metrics or measures used by the project management office are mostly qualitative and can include completed deliverables assigned to the project or feedback by the user community or other outside sources.

The department’s business operations planning department manages all financial aspects of the Electrical/Electronic Systems Engineering project cost. The department’s business operations planning manager found the project management approach the most cost effective for managing projects in a large organization. This approach has driven 5 percent efficiency in the operating costs for the electrical area of the company.

The collection of project data is managed by the project management office and can come from various sources, such as the engineering quality operating system health charts (project status reports) or work plans. Data integrity is managed by periodic auditing of the functional engineering team’s adherence to the organization’s tools and processes. The results of the audit are reported to the chief engineers and also posted in the team’s specific eRoom for team feedback. The chief engineers examine the auditing reports to drive 100 percent compliance through the organization.

To make data informational and useful, the organization analyzes various types of data with the following frequency:

  • Trend analysis of engineering quality operating system health charts is done twice monthly.
  • Timing analysis on work plans is conducted monthly and reported to the electrical program management team.
  • Updates to the engineering quality operating system integrator are conducted monthly, but tracking of red issues is conducted on a weekly basis.

Additionally, the following reporting methods or mechanisms are used in the organization:

  • The Web-based engineering quality operating system assessment provides red/yellow/green health charts for the commodity and system-level teams.
  • Work plans are maintained on eRooms for easy access to project timing data and deliverables.
  • Tracking of red issues conducted via a tracking database and a trend analysis is performed on this data.

Decision makers in the organization act on the reported metric data in different ways. The governance board conducts reviews of the engineering quality operating system red-status items across the organization for two hours every week and provides feedback to the managers on action items. The timing reviews are held bimonthly at the system level to review commodity development and testing status. Issues arising from these reviews are elevated to the chief engineers, who actively manage the red issues to green status.

To ensure that the project-related measures add value to the organization, the Electrical/Electronic Systems Engineering department can point to improvements in performance. The quality of the red/yellow/green status at various vehicle program milestones has been steadily improving since 2003. The organization acknowledges an effort to minimize projects in the yellow status. Corrective action plans are for the purpose of changing a commodity status to green, not to merely improve it from red to yellow. The Web-based engineering quality operating system assesses milestone deliverables using the red/yellow/green status and provides managers with immediate issue elevation.


Because project managers execute governance-board-approved projects, team members know they are expected to participate and meet project objectives. Project managers are given the authority to elevate issues or roadblocks that arise during the life of the project to the governance board for any needed feedback or assistance. The overall authority granted to project managers is commensurate with their level of accountability.

The roles and responsibilities for project managers are in the process of being mapped into the Ford Electrical/Electronic Systems Engineering job families. At the manager level, however, achievement and technical excellence is recognized and rewarded by senior management.

In terms of future objectives, the project management office has outlined the following effort to continue to improve the Electrical/Electronic Systems Engineering department’s project management maturity:

  • Develop a technical maturity model for project management to provide training and organizational structure to transfer project management roles and responsibilities and/or competencies.
  • Migrate commodity engineering quality operating system assessment summaries to the integrator and audit/coach/mentor commodity teams on the integrator.
  • Continue to expand electrical program management teams and commodity-in-a-box tools and processes.
  • Lead electrical work stream development in new product development system.

Greatest Measurement Challenges

The primary measurement challenge for Ford’s Electrical/Electronic Systems Engineering department was the length of time it took managers to realize that the project management office approach was necessary for project management processes to improve.

As discussed previously, the current auditing processes used by the project management office to measure project delivery typically address quality issues, whereas the project management change control process in the department allows for ongoing improvement to tools and processes, as well as the management of scope changes. Flexibility in these measurement systems has been important in achieving a higher rate of successful project outcomes. Additionally, processtraining surveys are conducted with team members after the rolling out of a new process or tool to gather feedback and to identify areas of improvement.


Learning from Project Management Missteps

Even with a strong effort to engage personnel, the objectives of the project management office were not initially clearly understood in the Electrical/Electronic Systems Engineering organization. Because most personnel had not previously experienced a working project management office, incorrect assumptions were sometimes made regarding its scope, roles, and responsibilities. It took the project management office some time to get the entire organization aligned on its value and the most effective method for execution of projects. The participation of the stakeholder board was key to the eventual acceptance of the project management office, along with constant communication.

To summarize, the Electrical/Electronic Systems Engineering department’s project manage office’s project execution plans were developed and reviewed and then approved by the governance board to clearly define the quarterly project management office objectives, scope, and resource allocation. These plans were made available to the organization via the eRoom and also reviewed at the manager level. Any overextending of project management resources or changes in project scope are routinely reviewed by the governance board at the monthly status review. After one year, the department had developed an effective working relationship with the project management office and had accepted the accompanying project management tools and methodologies.

Excerpted from APQC’s Best-practice Report Project Management, which is available for purchase at www.apqc.org/pubs. APQC is an international nonprofit research organization.

The Irresponsible Sponsors


Two executives in this company each funded a “pet” project that had little chance of success. Despite repeated requests by the project managers to cancel the projects, the sponsors decided to throw away good money after bad money. The sponsors then had to find a way to prevent their embarrassment from such a blunder from becoming apparent to all.


Two vice presidents came up with ideas for pet projects and funded the projects internally using money from their functional areas. Both projects had budgets close to $2 million and schedules of approximately one year. These were somewhat highrisk projects because they both required that a similar technical breakthrough be made. There was no guarantee that the technical breakthrough could be made at all. And even if the technical breakthrough could be made, both executives estimated that the shelf life of both products would be about one year before becoming obsolete but that they could easily recover their R&D costs.

These two projects were considered as pet projects because they were established at the personal request of two senior managers and without any real business case. Had these two projects been required to go through the formal process of portfolio selection of projects, neither project would have been approved. The budgets for these projects were way out of line for the value that the company would receive and the return on investment would be below minimum levels even if the technical breakthrough could be made. Personnel from the project management office (PMO), which are actively involved in the portfolio selection of projects, also stated that they would never recommend approval of a project where the end result would have a shelf life of one year or less. Simply stated, these projects existed for the selfsatisfaction of the two executives and to get them prestige with their colleagues.

Nevertheless, both executives found money for their projects and were willing to let the projects go forward without the standard approval process. Each executive was able to get an experienced project manager from their group to manage their pet project.

©2010 by Harold Kerzner. Reproduced by permission. All rights reserved.


At the first gate review meeting, both project managers stood up and recommended that their projects be canceled and the resources be assigned to other more promising projects. They both stated that the technical breakthrough needed could not be made in a timely manner. Under normal conditions, both of these project managers should have received medals for bravery in standing up and recommending that their projects be canceled. This certainly appeared as a recommendation in the best interest of the company.

But both executives were not willing to give up that easily. Canceling both projects would be humiliating for the two executives that were sponsoring these projects. Instead, both executives stated that the projects were to continue until the next gate review meeting, at which time a decision would be made for possible cancellation of both projects.

At the second gate review meeting, both project managers once again recommended that their projects be canceled. And, as before, both executives asserted that the projects should continue to the next gate review meeting before a decision would be made.

As luck would have it, the necessary technical breakthrough was finally made, but six months late. That meant that the window of opportunity to sell the products and recover the R&D costs would be six months rather than one year. Unfortunately, the thinking in the marketplace was that these products would be obsolete in six months and no sales occurred of either product.


Both executives had to find a way to save face and avoid the humiliation of having to admit that they squandered a few million dollars on two useless R&D projects.

This could very well impact their year-end bonuses.


  1. Is it customary for companies to allow executives to have pet or secret projects that do not follow the normal project approval process?
  2. Who got promoted and who got fired? In other words, how did the executives save face?

The Need for Project Management Metrics (A)


Everybody knew that this would be a very unpleasant meeting. The selling price of the company’s stock was near a five-year low. The company was just downgraded by one of the rating agencies. Several Wall Street analysts wanted more information on what new projects the company was working on and the potential strength of the R&D projects in the company’s pipeline. And to make matters worse, the company was forced to slash the company’s dividend payment to conserve cash.

Unlike other companies that could produce new products quickly and deliver them to the marketplace with minimal cost, this company struggled. Historically, the company was more of a follower than a leader. The company had problems when it came to creating value through innovation processes. In the past, whenever new products were created, the company was good at adding value to existing products using process reengineering, product modifications and enhancements, quality initiatives, and business process improvements. But this alone would not get the company through the current turbulent economic times. Innovation was a necessity and needed to happen quickly. The creation of customer-recognized value was needed and the company was struggling.

As Al Grey, President and Chief Executive Officer (CEO), entered the room, everyone could see that he was not happy. The company was in trouble and nobody really had a plan for how to rectify the situation. Finger-pointing and the laying of blame elsewhere had become the norm. The company had a multitude of talented people, but their achievements were less than par. This was particularly true of the R&D Group and the Engineering Departments responsible for the development of new products.

Al Grey stood up and addressed the senior staff:

I believe that I have identified the root cause of our innovation problems and we should be able to come up with a solution. I’m passing out to each of you two sheets of paper. In the first sheet (see Exhibit I), I have identified seven R&D projects that we considered to be total failures. You’ll notice that five of the seven projects that failed consumed some of our most talented people and yet there were no new products developed from these five projects or from the other two projects. You’ll also notice in which life cycle phase we made the decision to pull the plug on these projects. Several of these projects had gone through to completion before we discovered, or should I say were willing to admit, that the projects would produce no fruitful results.

Over the past year, we worked on a total of twelve high-priority R&D projects where we were convinced that success would be forthcoming. Only five of these projects generated any revenue stream, and none of the five were considered as “home runs” producing the desired cash flow. In the second sheet of paper (see Exhibit II), I have shown how much money we have squandered on the seven projects that failed. We threw away millions of dollars.

Several of you have pointed the finger at the project management office (PMO) and tried to put the entire blame on their shoulders claiming that the process we use for our portfolio selection of projects was at fault. While it is true that perhaps our process, like any other process, could be improved, it was still all of us in this room that agreed with their selection recommendations. Not all projects that we recommend will be successful and any executive in this room that believes that they will all be a success is a fool.

Exhibit I. Failure identification per life-cycle phase

Failure identification per life-cycle phase

Weekly Executive Staff Meeting

Exhibit II. R&D termination costs and reasons for failure


Original Budget

Expenditure at Termination

Reason for Failure




Objective too optimistic




Could not make breakthrough




Structural integrity test failure




Vendors could not perform




Product safety test failures




Specification limits unreachable




Could not make breakthrough




Some projects will fail, but with a failure rate of seven projects out of twelve, the company’s growth could be limited.

Everybody in the room reviewed the two sheets. There was dead silence. Nobody wanted to speak. Using the PMO as the scapegoat would no longer work. There was a feeling that Al Grey was about to blame someone for the calamity but nobody knew who it might be. Al Grey continued:

Given the reality that some projects will fail, why must we squander so much money by waiting until we get to the last two life cycle phases of our five phase methodology before we are willing to admit that the project might fail? Why can’t one of the project managers stand up in any of the earlier phases and state that the project should be cancelled?

Everybody then looked at Doug Wilson, Vice President for Engineering and R&D, for his response to the question. Even though a PMO existed, the majority of the project managers were engineers who reported directly to Doug Wilson. The project managers were “solid” to Engineering but “dotted” to the PMO just for project status reporting.

“I’m going to defend my people,” said Doug. “They work hard and have a history of producing results, profitable results at that! I know that some of our more recent projects have come in late, have been over budget, and the results have not been there. Our projects were challenging and sometimes this happens. It is uncalled for to blame my people for these seven failures.” Ann Hawthorne, Vice President for Marketing, decided to intervene:

I have worked with engineers for decades. They are highly optimistic and believe that whatever plan they develop will work correctly the first time. They refuse to admit that projects have budgets and schedules. The goal of every engineer that I have ever worked with wants to exceed the specifications


rather than just meet them, and they want to do it on someone else’s budget. When you perform R&D on government contracts, you can always request more money and a schedule extension, and you’ll probably get it from the government. But our engineers are spending our money, not funds provided from an external source. It’s hard for me to believe that they couldn’t identify early on that some of these projects should have been cancelled.

Everyone looked at each other wondering who would be next to be blamed for the problems. Al Grey then spoke out again:

Whenever I review one of our project status reports, all I see is information on budgets and schedules. The rest of the information is obscure or hidden and sometimes makes no sense to me. Sometimes, there are comments about risks. Why isn’t it possible to establish some metrics, other than time or cost metrics, which can provide us with meaningful information such that we can make informed decisions in some of the earlier life cycle phases? I see this as being the critical issue that must be resolved quickly.

After a brief discussion, everyone seemed to agree that better metrics could alleviate some of the problems. But getting agreement on the identification of the problem was a lot easier than finding a solution. New issues on how to perform metrics management would now be surfacing and most of the people in the room had limited experience with metrics management.

The company had a PMO that reported to Carol Daniels, Chief Information Officer. The PMO was created for several reasons, including the development of an enterprise project management methodology, support for the senior staff in the project portfolio selection process, and creation of executive-level dashboards that would provide information on the performance of the strategic plan. Carol Daniels then commented:

Our PMO has expertise with metrics, but business-based metrics rather than project-based metrics. Our dashboards contain information on financial metrics such as profitability, market share, number of new customers, percentage of our business that is repeat business, customer satisfaction, quality survey results and so forth. I will ask the PMO to take the lead in this, but I honestly have no clue how long it will take or the complexities with designing project-based metrics.

Everyone seemed relieved and pleased that Carol Daniels would take the lead role in establishing a project-based metric system. But there were still concerns and issues that needed to be addressed and it was certainly possible that this solution could not be achieved even after significant time and effort would be expended on metric management.

Al Grey then stated that he wanted another meeting with the executive staff scheduled in a few days where the only item up for discussion would be the plan for developing the metrics. Everyone in the room was given the same action item in preparation for the next meeting: “Prepare a list of what metrics you feel are necessary for early-on informed project decision-making and what potential problems we must address in order to accomplish this.”


In answering these questions, do not look for the perfect answer. This problem is quite common today and plaguing executives, stakeholders, and other decisionmakers involved in projects. There may be several answers to each question based upon your interpretation of the situation.

  1. Can the failure of R&D actually be this devastating to a company?
  2. When project work goes bad and failures occur, is it common practice for finger-pointing and the laying of blame to occur, even at the executive levels?
  3. What information is found in Exhibit I?
  4. What information is lacking in Exhibit I?
  5. Is it possible that highly talented resources can overthink an R&D project tothe point where they look for the most complicated solution rather than the simplest solution?
  6. Is it good or bad to have five R&D projects out of twelve completed successfully?
  7. Can a PMO prevent failure?
  8. Is it inherently dangerous to encourage a project manager to recommendthat his or her project be terminated during early life-cycle phases?
  9. Who, if anyone, should be blamed for the failure of the projects in this case study?
  10. Is Ann Hawthorne’s description of engineers realistic?
  11. Would you agree with Al Grey that the real cause of the failures appears tobe a lack of good metrics? If this is the cause, then how do you justify that other projects were successful?
  12. Should the PMO take the lead in the establishment of the metrics?
  13. Are a few days enough time for the follow-on meeting and should the executives attend?

The Need for Project Management 2 Metrics (B)


The weekly executive staff meeting concluded and everyone felt confident that the company was now heading in the right direction. Al Grey sent out a companywide e-mail letting everyone know what was about to happen and that the company needed everyone’s cooperation to make this metrics management initiative succeed. Al Grey stated:

As you all know, today’s business environment is changing rapidly. We can no longer rely solely upon our existing product lines for continuous growth. In the past, we have captured best practices and lesson learned, and this has improved the efficiency and effectiveness of our operations which then added to profits. Unfortunately, the best practices and lessons learned that we captured did not directly provide benefits to our innovation processes.

Because we are now in a dynamic rather than stable business environment, we must rely heavily upon the creation of new products to achieve sustained growth. Our customers are demanding new products with higher quality and at a lower cost. Customers are now looking at how our products provided value to them and sometimes the importance of perceived value takes precedence over cost and quality considerations.

©2010 by Harold Kerzner. Reproduced by permission. All rights reserved.

We must now redefine our innovations processes to meet rapidly changing consumer demands. Our business development managers are being challenged to identify the value of business opportunities for new products that do not yet exist. Our R&D staff must develop these products and we must have an innovation process in place that allows us to achieve our strategic objectives.

Because of the turbulent business environment, time is no longer a luxury but a critical constraint in our innovation process. With limited resources to work with, we must be absolutely sure that we are working on the right mix of projects. We are in the process of developing a metrics management system to allow us to make better decisions with regard to the selection and development of new products with exceptional value. The metrics we create will help us ensure that we are creating products that have value. Metrics management is essential. We must know if we are heading in the right direction and if the light at the end of the tunnel is reachable. If the metrics indicate that we cannot achieve our goals on a particular project, then we must pull the plug and assign the resources to those other projects that provide business value opportunities.

We are establishing a metric management team to develop this capability. The metrics management team will report to the PMO. I expect all of you to assist the team in carrying out their mission if they ask for your input and assistance.


Al Grey was convinced that he was on the right track in his quest for a metrics management system. Rather than leave the team member assignments to chance, Al personally selected the members of the task force. He knew each of these team members personally and was convinced that they could live up to the challenge. The six team members were:

  • John: representing the PMO and the team leader
  • Patsy: representing Marketing
  • Carol: representing New Business Development
  • Allen: representing Engineering
  • Barry: representing R&D
  • Paul: representing Manufacturing

The team met and began discussing their challenge. The first step was to get a good understanding of what metrics are and how the company can benefit from their use. Everybody seemed to understand that a company cannot manage innovation projects without having good metrics and reasonably accurate measurement capable of providing complete or nearly complete information for the decision-makers. Furthermore, since most of the company’s projects were becoming more complex, it would become harder to determine true progress without effective metrics.


The team prepared a list of the benefits of using metrics. The list included:

  • To improve performance for the future
  • To improve future estimating
  • To validate baselines
  • To validate if we are hitting our targets or getting better or worse
  • To catch mistakes before they lead to other perhaps more serious mistakes
  • To improve client satisfaction
  • A means of capturing best practices and lessons learned

Although everyone agreed on the benefits of metrics, John expressed his concern that the team must remain focused. John stated:

It takes companies years to achieve all of those benefits. We simply do not have the luxury of doing that. We must focus on our primary mission, which is the establishment of metrics for our innovation process. We need objective, measurable attributes of project performance in order to make informed decisions. We must be able to use the metrics to predict project success and failure. Therefore, we must establish some type of priority for what type of metrics we will develop first.

The team decided that the primary focus should be to establish metrics that can be used as a means of continuous health checks on innovation projects. The metrics has to serve as early warning signs or risk triggers.

But deciding what to do and being able to do it were two separate activities. The business side of the company had been using metrics for some time. These were metrics related to market share, profitability, cash flow, and other such highlevel measurements. The innovation metrics to be developed would be more detailed, and this could alienate the culture to the point where there would be more resistance than support. Allen commented:

Engineers do not like constant supervision. They like the freedom to create and I am sure the same holds true in R&D. If we develop metrics that are too detailed and our people believe that the metrics are being used to spy on them, I feel that we will get a lot of resistance.

Patsy then commented on her observations with the metrics used in marketing and sales:

I agree with Allen’s comments. In marketing, we had established some resistance as well, but for different reasons. Some people felt that the metrics were a waste of time and tied up valuable resources doing measurements. Some of the metrics we needed were not readably accessible from our information systems. Every executive wanted a different set of business metrics and it was impossible for us to get agreement on what metrics were actually needed. We had to make software changes to some of our information systems and that took time and money. Also, people felt that, since these were high level metrics and updated monthly or quarterly, it was sometimes too late to make changes that were necessary to improve our business.

Exhibit I. Differences between financial and project-based metrics





Financial measurement

Project performance


Meeting strategic goals

Meeting project objectives, milestones and deliverables


Monthly or quarterly

Real time data

Items to be looked at

Profitability, market share, repeat business, number of new customers, etc...

Adherence to competing constraints, validation and verification of performance

Length of use

Decades of even longer

Life of the project

Use of the data

Information flow and changes to the strategy

Corrective action to maintain baselines

Target audience

Executive management

Stakeholders and working levels

Everyone at the meeting had smiles on their faces ready to accept the new challenge. Patsy then showed the team Exhibit I, which compares financial metrics with the metrics that would have to be developed for projects. The smiles soon disappeared because the team now realized that they may not be able to draw upon the expertise from Marketing in creating project-based metrics. There were significant differences.

Now, the team was coming to the realization that this was more complicated than they originally thought. They were now questioning whether they could get all of this done in a timely manner.

Realizing that the team was getting a little nervous, John stepped into the conversation:

I know you are all a little nervous now, but let’s solve the problem with small rather than large steps. As I see it, there are four questions we should concern ourselves with:

  • What metrics should we select?
  • How will the metrics be measured?
  • How will the metrics be reported?
  • How will management react to the information?

The first two questions are probably the most important, and this is where we should start. I’m convinced we can do this, and in a reasonable time frame.

The team established an action item for then next meeting whereby all of the team members would interview their people and come up with a possible list of metrics. The meeting adjourned.



  1. Is there a relationship between the capturing of best practices and the development of new metrics?
  2. Is the makeup of the team correct? Should someone from senior management also have been part of the team?
  3. Does it seem reasonable that some people might feel that metrics can be aspying machine?
  4. Are the four questions posed by John correct?
  5. What metrics would you include in the list that may be appropriate for innovation projects?

The Need for Project Management 3 Metrics (C)


The team reconvened with each team member bringing with them a list of possible metrics. Each team member had interviewed people in their own group and at all levels of management. Each team member knew that their list was highly subjective and they now had to combine their thought process with the entire team and see if they could come up with a more objective list. The first step was to combine the metrics as shown in Exhibit I.

While many of the metrics seemed worthy of consideration, there was a consensus that the list may be too long. John spoke first:

If we accept all of these as workable metrics, we may do more harm than good. All metrics need measurement and too many metrics will force team members to steal time from other work to do the measurement and reporting. Some of these metrics have little or no value for innovation projects and if we were to provide all of this information to the executives, they may not be able to determine what information is critical.

©2010 by Harold Kerzner. Reproduced by permission. All rights reserved.


Exhibit I. Combined listing of metrics

  • Percent of work packages adhering to the schedule
  • Percent of work packages adhering to the budget
  • Number of assigned resources versus planned resources
  • Quality of the assigned resources versus planned resources
  • Percent of actual versus planned baselines completed to date
  • Percent of actual versus planned best practices used
  • Project complexity factor
  • Customer satisfaction ratings
  • Number of critical assumptions made
  • Percent of critical assumptions that have changed
  • Number of cost revisions
  • Number of schedule revisions
  • Number of scope change control meetings
  • Number of critical constraints
  • Percent of work packages with a critical risk designation
  • Net operating margins
  • Number of unstaffed hours
  • Turnover of key personnel, in number or percent
  • Percent of labor hours on overtime
  • Schedule variance, SV
  • Cost variance, CV
  • Schedule performance index, SPI
  • Cost performance index, CPI

Carol spoke next:

I agree with John’s remarks that the list is too long. But playing the devil’s advocate, providing too few metrics can be equally as bad. Providing too few metrics can be disastrous if executives overreact to bad news on just a couple of metrics. They may not see the true story. We may need to educate the executives on how to understand the metrics. If we do not provide the right information, then executives may not be able to make informed decisions in a timely manner.

Patsy then added her comments to the conversation:

I was part of the committee that established the financial and business metrics a few years ago. After several meetings, we established a business metric selection process that stated that whatever metrics we selected had to be worth collecting; we had to be sure that we would use what we collected; we had to make sure that the metrics were informative; and we eventually had to train our people in the use and value of these metrics.

It was now apparent that metric selection would be critical. The team knew that no matter how large or how small the final list would be, there would be naysayers that would argue that the benefits do not justify the cost and that metric measurement is a waste of time and useless.

Exhibit II. Categories of metrics

  • Quantitative metrics (planning dollars or hours as a percentage of total labor)
  • Practical metrics (improved efficiencies)
  • Directional metrics (risk ratings getting better or worse)
  • Actionable metrics (affect change such as the number of unstaffed hours)
  • Financial metrics [profit margins, return on investment (ROI), etc.]
  • Milestone metrics (number of work packages on time)
  • End result or success metrics (customer satisfaction)

Barry stated that he has friends in other companies that maintain a metrics library the same way that other companies maintain a best practices library. While Barry’s contacts were not willing to provide a list of the exact metrics in their library, they were willing to provide the categories of metrics as they appeared in the library. The categories are shown in Exhibit II:


  1. What are the risks of reporting on too many metrics?
  2. What are the risks of reporting on too few metrics?
  3. Using Exhibit III, categorize the metrics in Exhibit I.

Exhibit III. Categorizing the metrics








End Result

Percent of work packages on schedule

Percent of work packages on budget

Number of assigned versus planned resources

Quality of assigned versus planned resources

Percent of actual versus planned baselines completed

Percent of actual versus planned best practices used

Complexity factor

Customer satisfaction rating

Number of critical assumptions

Percentage of critical assumptions that have changed

Number of cost revisions

Number of schedule revisions

Number of scope change control meetings

Number of critical constraints

Percent or work packages with a critical designation

Net operating margin

The Need for Project Management 4 Metrics (D)


Although the list of metrics was good, it was apparent that the list was too long for senior management. The metrics had to be converted to key performance indicators (KPIs). Although most companies use just metrics for measurement purposes, they seem to have a poor understanding of what constitutes a KPI, especially for projects. The ultimate purpose of a KPI is the measurement of items relevant to performance and to provide information on controllable factors appropriate for informed decision-making such that it leads to positive outcomes.

On innovation projects, KPIs drive change but do not prescribe a specific course of action. Not all metrics are KPIs. A KPI is a metric specifically related to decision-making. All KPIs have targets. If we are meeting or exceeding the target, then that’s good. If we are not, then we must decide whether a correction is possible or whether we should cancel the project. On innovation projects, KPIs serve as early indicators of success or failure.

Several of the team members appeared confused over the difference between metrics and KPIs. John then said:

All KPIs are metrics but not all metrics are KPIs. As an example, executives should not be concerned with the number of unstaffed man-hours or the quality of the assigned resources. However, if it looks like the project may be in trouble, then the executives should have the right to “drill down” to more detailed levels of information. KPIs should be viewed as high level metrics whereas more detailed information may appear as just metrics. I know the difference may not be clear to some of you, but the difference is there. On one project, a measurement can be treated as a KPI and on another project it may appear as just a pure metric.

©2010 by Harold Kerzner. Reproduced by permission. All rights reserved.

Allen then made the following comments:

Given what you just said, each innovation project can have a different set of KPIs. Therefore, I recommend that, for each project, we look at the entire list of metrics and decide which should be treated as KPIs.

Patsy then interjected:

In marketing, we have just eight metrics and we report on these same eight metrics every quarter. We have been doing this for the past several years with our financial scorecards. Now you’re saying that project-based metrics and KPIs can change from project to project.

John responded:

Not only can they change from project to project, they can also change during each life cycle phase. If a project gets into trouble, I expect some executives may want to see other metrics or KPIs reported such that they can make better decisions. We must also be prepared for the situation where each executive may want to see a different set of KPIs. They have that right, and we must live with it.

The team realized that converting metrics to KPIs would not be an easy task. It would be important that the number of KPIs be limited so that everyone could be focused on the same KPIs and understand them. Having too many KPIs may distract the project team and the executives from what is really important. This, in turn, could slow down projects because of excessive measurements and blur one’s vision on actual performance. John then stated:

It is my experience that companies often create too many KPIs rather than too few. Hopeful [sic], we can overcome that urge. I did some research and found a list of attributes that KPIs should have. The list is shown in Exhibit I. Perhaps this list can help us differentiate KPIs from pure metrics.


  1. Is there a simple way to differentiate between a metric and a KPI?
  2. What factors determine how many KPIs should be reported?
  3. Using the KPI selection criteria in Exhibit I, complete Exhibit II.
  4. How many of the metrics in Exhibit II are now considered as KPIs?

Exhibit I. KPI selection criteria

  • Predictive: able to predict the future of this trend
  • Measurable: can be expressed quantitatively
  • Actionable: triggers changes that may be necessary
  • Relevant: the KPI is directly related to the success or failure of the project
  • Automated: reporting minimizes the chance of human error Few in number: only what is necessary

Exhibit II. Categorizing the metrics







Percent of work packages on schedule

Percent of work packages on budget

Number of assigned versus planned resources

Quality of assigned versus planned resources

Percent of actual versus planned baselines completed

Percent of actual versus planned best practices used

Complexity Factor

Customer satisfaction rating

Number of critical assumptions

Percentage of critical assumptions that have changed

Number of cost revisions

Number of schedule revisions

Number of scope change control meetings

Number of critical constraints

Percent or work packages with a critical designation

Net operating margin

Number of unstaffed hours

Turnover of key personnel, In # or %

Percent of labor hours on overtime

Schedule variance, SV

Cost variance, CV

Schedule performance index, SPI

Cost performance index, CPI

The Need for Project Management 5 Metrics (E)


The team felt reasonably comfortable with the understanding of the differences between metrics and KPIs. Now came perhaps the biggest challenge: the need for KPI measurements. For decades, the only metrics the company looked at were time and cost metrics. The measurements came from time cards and reported through the company’s project management information system. Time and cost metrics were considered to be objective measurements even though management often questioned how valuable they were toward predicting the success or failure of a project.

The team knew the questions that now needed to be addressed:

  • Measurements:
  • What should be measured?
  • When should it be measured?
  • How should it be measured?
  • Who will perform the measurement?
  • Collecting information and reporting:
  • Who will collect the information?
  • When will the information be collected?
  • When and how will the information be reported?

©2010 by Harold Kerzner. Reproduced by permission. All rights reserved.

From KPI Selection to KPI Measurement

Patsy commented:

In marketing, the eight metrics we have on our scorecard are direct measurements and absolutely objective. But for project-based metrics, I believe that most of the metrics will come from highly subjective calculations. Perhaps after we use all of these project-based metrics for a while the way we calculate them will become more objective rather than subjective, but that may be years from now.

Also, I’m not sure we will be able to come up with measurements for all of the KPIs we selected. This may be a challenge beyond our team’s capability. And even if we can come up with a measurement approach, how will we know if each project team can perform the measurement?

John had some experience with measurements and added to the conversation:

Anything can be measured as long as we do not insist upon perfect measurements. The alternative to perfect measurements is no measurements at all, and that’s really bad. Work that gets measured gets done! If it cannot be measured, then it cannot be managed, and that would then defeat the purpose of having KPIs. My experience is that you never really understand anything until you try to measure it.

In the past, we looked only at those metrics that were easy to measure, such as time and cost. Everything else was difficult to measure and therefore ignored. Now, we are realizing that all metrics must somehow be measured and reported. Perhaps in the future more sophisticated measurement techniques will be available to us. But for now, we must use what we have and what we understand.

Allen knew that John’s comments were correct. Allen then said:

There are numerous ways that measurements can be made. We use a variety of techniques in engineering. We can measure things in numbers, dollars, headcount and ratings such as good, neutral or bad. Some measurements will be quantitative whereas others will be qualitative.

The team spent several hours looking at various measurement techniques for each of the KPIs. It was obvious that no single measurement method would be appropriate for all of the KPIs. The team was now somewhat perplexed as to what measurement techniques to look at. Carol then commented:

We cannot separate measurement from reporting. We must look at them together. For example, if we are $15,000 over budget, is that really bad and should we give consideration to cancelling this project? Perhaps $15,000 over budget is acceptable to management. Perhaps it might even be looked at as being good.


Exhibit I. Generic boundary box Performance


Favorably Exceeding Target

Exceeding Target

Performance Target

Unfavorable Expectation

Risk of Project Failure


Target + 20%


Target + 10%


Target 10%


Target 20%

Urgent Attention

My concern is that all measurements should be made from a target or reference point so that we can determine if this is a good or bad situation. I believe that we must establish targets for each of the KPIs.

The team felt that Carol’s comments provided them with some direction as to where to proceed. After a few more hours of deliberation, the teams came up with a generic boundary box approach for establishing targets for each of the KPIs. The generic boundary box is shown in Exhibit I.

Each boundary box would have five levels. At the beginning of the project, the project manager would work with the sponsor or stakeholders to establish a reasonable performance target for this KPI. For example, if we consider cost as a KPI, then the actual cost ±10 percent might be considered an acceptable performance target and something management can live with. If we are under budget by 10–20 percent, then this could be considered as exceeding the target by a small amount. If we are under budget by more than 20 percent, then this could be regarded as superior performance.

The same scenario holds true if we are over budget. If we are over budget by 10–20 percent, this could be viewed as a caution, especially if this number becomes more unfavorable each reporting period. If the costs are over budget by more than 20 percent, then management may wish to consider canceling the project.

The team felt that this approach was workable. However, it would be highly subjective because on one project the normal range boundaries may be at ± 10


percent but on another project it may be at ± 5 percent. But everyone knew that, with experience, the ranges would be tightened up.

No single metric or KPI would most likely dictate that cancellation would be necessary. However, looking at all of the KPIs together and possibly in combination with some of the other metrics, termination may then be the only viable alternative.


  1. Can any KPI be measured?
  2. Does Exhibit I satisfy the necessity for a target for a KPI?
  3. For each of the KPIs identified in the previous case, establish what you consider to be a reasonable boundary box.

The Need for Project Management 6 Metrics (F)


For almost a year, the company had some degree of success with the metrics for innovation projects even though the measurements were highly subjective. The metrics management initiative team met occasionally to reassess performance and look for ways to improve the process. Decisions were being made much earlier than before to cancel some projects that appeared unable to meet the objectives. Resources were then assigned to other projects. Projects that went through to completion were generating sales. But management was still unhappy. The products that were being developed were not meeting sales goals. Perhaps some of the metrics had to be changed.

Al Grey met with the metrics management initiative team to express his concerns:

The metrics that were developed seemed rather attractive at first. But as often happens, some of the more important metrics that are needed are not discovered until some time later. This is the case now.

Many of the projects that went through to completion were done within the time and cost constraints. Unfortunately, being within time and cost does not mean that there will be value in the end result such that the customers will be pleased.

We need not just products, but products that possess the necessary value such that clients that are faced with a purchase decision will select our products. While we do not always know the customer’s definition of value, we must still try to develop value-based metrics to allow us to work on the right projects. Value-based metrics are also a necessity to help us make the right tradeoffs on some of these innovation projects.

The team wasn’t sure where to begin. It took quite a bit of time to establish targets and measurements for the metrics and KPIs that were currently being used. But value-based metrics for innovation projects were something entirely new to most of the team. After a lengthy discussion, Patsy stated:

We’ve done a few surveys in marketing and the following five points were found to be important value contributors to our clients:

  • Product quality
  • Product cost
  • Product safety
  • Product features
  • Delivery date

I believe that we should be able to take advantage of this research for establishing some value metrics for projects. But we must remember that this list was generated from surveys of our customers based upon their definition of quality. Measuring a project’s value requires a rigorous value measurement approach. It is not just measuring value; it is measuring customer value. This list that I just gave you may have to change for use on our internal projects.

John then reinforced Patsy’s comments by stating the PMO is looking at a new way of doing the portfolio selection of projects. Each project must provide value in one or more of the four value quadrants, namely internal value, financial value, future value, and customer-oriented value. Many of the value characteristics are the same for more than one quadrant. As an example, the value contributors identified by Patsy were applicable to future value and customer-oriented value.

The team believed that Patsy’s and John’s comments had tremendous merit. But using all five of these contributors as separate metrics would simply add more metrics to the list. The team came up with another idea. They would use the same five criteria mentioned above but product cost would be replaced by innovation project cost and delivery date would be replaced by innovation project completion date. Using this concept, weighting factors could be assigned to each component of the new value metric. That would show us what percentage of the value metric came from each of these factors. As an example:

Product quality


Project cost


Product safety


Product features


Project completion date


Now there was just one value metric, but it had five components. Using the generic boundary box in the previous case study, the team established a quantitative value measurement system where points could be assigned, such as: Points

● Superior performance


● Good performance


● Standard performance


● Below-par performance


● Risk of failure


As an example, the team considered the five value components measured and reported as follows:

Value Component

Weighting Factor (%)

Value Measurement

Value Contribution
























If all of the value components simply met their targets or were expected to meet their target or standard performance, all of the value measurements would be 2.0 and the value contribution would be 2.0 as well, which is the standard target value. But since the total value contribution is 2.70, this project is producing added value and should be considered for continuation. But if the value contribution were 1.75, then the project may not be producing the desired value (i.e., targeted value) and should be reevaluated for continuation.

This approach was also highly subjective in assigning the weighting factors and the boundary box measurement. But over time, it could become more of an objective rather than subjective technique.

For this technique to work well, each project manager would have to work with their sponsor to determine the weighting factors. The weighting factors could change during the project as well. For example, the exhibit shown below might be representative of how the weighting factors can change if a project is currently having a significant schedule slippage or cost overrun.

Value Component

Normal Weighting

Weighting Factors If

Weighting Factors If We

Factor (%)

We Have a Significant

Have a Significant

Schedule Slippage (%)

Cost Overrun (%)





















Need for KPI That Measures Value

By adjusting the weighting to a higher percentage in one area, there would have to be significant value contributions elsewhere to compensate for the potential problem. As the company gets more experienced with this approach, more than five value components can be used, and the decision on what value components to use will take place at the onset of each project.

The subjectivity of the approach still bothered some of the team members. The team then decided that, in order to reduce some of the subjectivity, there should be ranges in the weighting factors as shown below and where the nominal values need not be the middle value of the range:

Value Component

Minimal Weighting

Maximum Weighting

Nominal Weighting

Value (%)

Value (%)

Value (%)





















Realizing that management would like to be briefed on their recommendations, the team prepared a list of topics to be discussed in the briefing:

  • Every project will have just one value metric or value KPI.
  • There will be a maximum of five components for each value metric.
  • The weighting factors and measurement techniques will be established by the project manager and the stakeholders at the onset of the project.
  • The target boundary boxes will be established by the project manager and the PMO.

Even though the team felt comfortable with this approach, there were still questions that needed to be addressed, but perhaps not immediately:

  • What if only three of the five components of value can be measured at a point in time, such as in early life-cycle phases?
  • Should the project be a certain percent complete before the value metric has any real meaning and should be considered?
  • In such a case where only some of the components can be measured, should the weighting factors be changed or normalized to 100 percent or left alone?
  • Who will make decisions as to changes in the weighting factors as the project progresses through its life cycle-phases?
  • Can the measurement technique for a given component change over each life-cycle phase or must it be the same throughout the project?
  • Can we reduce the subjectivity of the process?

Even though questions persisted, the team realized that some form of template needed to be developed specifically for the reporting of the value metric. After some deliberation, the team came up with the template shown in Exhibit I. Now, the team had to wait until this subjective approach was tried in several projects.

Exhibit I. The value metric report

Project Title:

Smart Phone Redesign

Project Manager:

Carol Grady

Planning Date:

November 12, 2010

Plan Revision Date:

January 15, 2011

Revision Number:



Value Components Weighting Factor

Value Component

Weighting Factor

Measurement Technique

Value Measurement

Value Contribution









Direct Counting
















Direct Counting



Total = 2.7


  1. What factors would make this process more subjective than objective?
  2. If these innovation projects were for external rather than internal clients, whoshould have more of an influence in the selection of the value components: the customers or the contractor doing the work?
  3. Can the value component change over the life-cycle phases and, if so, underwhat circumstances?
  4. At what value contribution level would a project definitely be canceled?
  5. Under what conditions would a project still be allowed to continue even if itfalls below the acceptable value threshold limit?

The Need for Project Management 7 Metrics (G)


Even with the use of value metrics, the company realized that not many projects were being canceled. Everybody knew that creating products within time and cost constraints would be difficult. Although the company was good at linking its innovation projects to a business strategy, the company was equally as poor at cost estimating. Even when a project was selected and properly linked to a business strategy, there was still a fuzzy front end on the project where detailed requirements were almost impossible to develop. On innovation projects, it was common practice to use “rolling wave planning” where more detail would be added to the requirements as the work progressed. Simply stated, if you can lay out a detailed plan for innovation, then you do not have an innovation project.

Estimating the time and especially the cost of an innovation breakthrough was almost impossible. Effective innovation leaders are those who have a fervent belief in the project, refuse to let the project die, and often find faulty rationalization as to why the project should continue regardless of what the value metric measurement shows. Some people believe that effective innovation leaders are those who see a future that does not exist yet for what they are developing. This generates a reluctance to terminate projects.

The company needed to do a much better job of pulling the plug on projects. Every project seemed to develop a life of its own and nobody had the heart to cancel it regardless of the value metric measurement results. Nobody seemed to have the authority to cancel the projects. Once a project was terminated, the company would ask, “Why didn’t we do this earlier?” or “Why did we approve this project in the first place?” No best practices or lesson learned were ever captured related to mechanisms for canceling projects.

Al Grey met with the metric management team again and asked them for their assistance.

We need to do a better job on cancelling projects. I know this is not the reason why your team was created, but I value your input. Perhaps, metrics management in another form is the solution, but I am not sure. I have looked at three mechanisms for cancelling projects and perhaps you can give me your opinion of the advantages and disadvantages of each method.

First, our senior people seem to get involved in these projects at a point where they can be the least helpful. They seem to avoid identification with any project that might damage their career. Their involvement appears only after they have someone to blame other than themselves if the project is terminated. So, in the first method, we could assign a project sponsor from the senior levels of management to each of these innovation projects and the sponsor must then be involved all the way through.

The second method involves lower and middle management. Right now, lower and middle management are backed into a corner because they may be involved in some of the projects, yet have no decision-making authority for cancelling them. To make matters worse, the people on project teams often are not honest with lower and middle management as to the real status of the projects. Now, senior management begins to wonder if there is frank disclosure coming up to their levels. Perhaps lower and middle management should serve as project sponsors and be actively involved in the innovation projects from cradle to grave.

Although project sponsorship seems like the right idea, I have read about some of the risks in assigning sponsors. The risks include:

  • Seeing what they want to see
  • Refusing to accept or admit defeat or failure
  • Viewing bad news as a personal failure
  • Fearful of exposing mistakes to others
  • Viewing failure as a sign of weakness
  • Viewing failure as damage to one’s reputation
  • Viewing failure as damage to one’s career

As a result, sponsors may not want to cancel projects. Therefore, perhaps we should assign an exit champion. The exit champion would be someone from the executive levels of management and a person that has no vested interest in the workings of the project. The exit champion will determine periodically if the project should continue on. If the exit champion determines that cancellation is the best option, then the exit champion will present his or her findings to the executive steering committee. The executive steering committee will have the authority to override the findings of the project sponsor in favor of the findings of the exit champion.


  1. What are the advantages and disadvantages of each approach?
  2. Which approach would you pick?
  3. Can the exit champion use a different criterion such as looking only at returnon investment?

The Need for Project Management 8 Metrics (H)


Prosperity never comes without headaches. The new metrics measurement system was working quite well. Some projects were canceled, as expected, and most of the projects that went through to completion were considered a success. Actually, the company was becoming more successful than it had originally hoped, and this was placing a strain on manufacturing capacity.

Al Grey convened the metrics management team once again to see if any metrics could be created to assist with capacity planning. Al Grey stated:

As you all know, the company has been relatively conservative in the past when it came to adding more manufacturing capacity. Sometimes, we were too conservative and ended up with a large backlog or orders which, in turn, alienated some of our customers. The success of our innovation processes has created more new products than we can currently manage with our existing capacity. Manufacturing personnel are working overtime and weekends to try to keep up with demand. We are managing somehow at present, but we have many new innovation projects in the queue. Are there any metrics we can develop and use during our innovation processes that will give us some insight on future capacity needs?

Al Grey handed out Exhibit I and explained that, with the existing products in manufacturing, capacity would be lagging demand by almost 10,000 units per year beginning in 2012. The conservative nature of the company was based upon the belief that unused capacity was a cost not worth considering. That thinking has since disappeared.

Al Grey then handed out Exhibit II, which showed that the company was considering yearly capacity increases beginning in 2012 to alleviate this pressure on manufacturing. However, yearly increases of 10,000 units would satisfy current and projected demands for the company’s existing products. Al Grey then handed out Exhibit III, which showed that adding capacity at 20,000 units every two years could be a better approach.

But there was still another capacity issue. With the success in the company’s innovation processes, new products were being developed that could make the capacity problem worse. The company wanted metrics to show the capacity requirements that would be needed for the projects that are now part of the innovation processes. The company knew the difficulties with capacity planning projections and knew that alternative sources of capacity could be used, as shown in

Exhibit IV, but this would be just a temporary solution.` Al Grey then continued:

The problem is more complex than just adding capacity. In the past, it has taken us between three months and six months from the time the innovation project is completed to the time when manufacturing begins and we can start delivering the products. During that window, we prepare our manufacturing plans and conduct our procurements. Sometimes, procurement alone can

Exhibit I. Capacity lagging demand

Capacity lagging demand

Exhibit II. Capacity increments of 10,000 yearly to meet demand

Capacity increments of 10,000 yearly to meet demand

Exhibit III. Capacity increments of 20,000 units every two years

Capacity increments of 20,000 units every two years

last for three months or longer. So, what I am saying is that any metric you can provide on the overall probability of success and how much capacity we will need, will be helpful. The company understands the risks in what we are asking you to do and is willing to accept the risks.


Exhibit IV. Using alternative sources of capacity increments yearly

Using alternative sources of capacity increments yearly


  1. Can a metric for predicting success be developed?
  2. Can a metric for predicting capacity needs be developed?
  3. What are the risks assuming these two metrics can be created?

Project Management Tutorials

Project Management Case studies

Project Management Sample Assignments

Project Management Sample Solutions


Very affordable projects!! And that to submit before deadlines. Thanks for helping me in my database project and raising my grades. I have been able to secure good marks in my internal assessment only because of you. Read More

Copyright © 2009-2023 UrgentHomework.com, All right reserved.