61,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Fachliteratur
- Sprache: Englisch
The new edition of Harold Kerzner's bestselling book on measuring project management performance With today's complex projects, increased stakeholder involvement, and advances in computer technology, metrics and key performance indicators (KPIs) have become increasingly integral to informed decision-making and effective project management. Project Management Metrics, KPIs, and Dashboards, Second Edition helps functional managers gain a thorough grasp of what metrics and KPIs are and how to use them, as well as an understanding of different dashboard types, design issues, and applications. Closely aligned with PMI®'s PMBOK® Guide, this new edition features: * New content on topics ranging from customer relations management and project oversight to agile and SCRUM metrics, as well as metrics, pitfalls, and myths * An emphasis on value, including an in-depth discussion of value-driven metrics and value-driven KPIs * Full-color screen shots showing dashboards from some of the most successful project management companies * PowerPoint slides and a test bank for use in seminar presentations and courses This book allows functional managers to bolster their awareness of what good metrics management really entails today--and be armed with the knowledge to measure performance more effectively. (PMI and PMBOK are registered marks of the Project Management Institute, Inc.)
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 614
Veröffentlichungsjahr: 2013
Ähnliche
Contents
Preface
Chapter 1: The Changing Landscape of Project Management
1.0 Introduction
1.1 Executive View of Project Management
1.2 Complex Projects
1.3 Global Project Management
1.4 Project Management Methodologies and Frameworks
1.5 The Need for Effective Governance
1.6 Engagement Project Management
1.7 Customer Relations Management
1.8 Other Developments in Project Management
1.9 A New Look at Defining Project Success
1.10 The Growth of Paperless Project Management
1.11 Project Management Maturity and Metrics
1.12 Project Management Benchmarking and Metrics
1.13 Conclusions
Chapter 2: The Driving Forces for Better Metrics
2.0 Introduction
2.1 Stakeholder Relations Management
2.2 Project Audits and the PMO
2.3 Introduction to Scope Creep
2.4 Project Health Checks
2.5 Managing Distressed Projects
Chapter 3: Metrics
3.0 Introduction
3.1 Project Management Metrics: The Early Years
3.2 Project Management Metrics: Current View
3.3 Metrics Management Myths
3.4 Selling Executives on a Metrics Management Program
3.5 Understanding Metrics
3.6 Causes for Lack of Support for Metrics Management
3.7 Using Metrics in Employee Performance Reviews
3.8 Characteristics of a Metric
3.9 Metric Categories and Types
3.10 Selecting the Metrics
3.11 Selecting a Metric/KPI Owner
3.12 Metrics and Information Systems
3.13 Critical Success Factors
3.14 Metrics and the PMO
3.15 Metrics and Project Oversight/Governance
3.16 Metric Traps
3.17 Promoting the Metrics
3.18 Churchill Downs Incorporated’s Project Performance Measurement Approaches
Chapter 4: Key Performance Indicators
4.0 Introduction
4.1 The Need for KPIs
4.2 Using the KPIs
4.3 The Anatomy of a KPI
4.4 KPI Characteristics
4.5 Categories of KPIs
4.6 KPI Selection
4.7 KPI Measurement
4.8 KPI Interdependencies
4.9 KPIs and Training
4.10 KPI Targets
4.11 KPI Failures
4.12 KPIs and Intellectual Capital
4.13 KPI Bad Habits
4.14 BrightPoint Consulting, Inc.—Dashboard Design: Key Performance Indicators and Metrics
Chapter 5: Value-Based Project Management Metrics
5.0 Introduction
5.1 Value over the Years
5.2 Values and Leadership
5.3 Combining Success and Value
5.4 Recognizing the Need for Value Metrics
5.5 The Need for Effective Measurement Techniques
5.6 Customer/Stakeholder Impact on Value Metrics
5.7 Customer Value Management (CVM)
5.8 The Relationship between Project Management and Value
5.9 Background to Metrics
5.10 Selecting the Right Metrics
5.11 The Failure of Traditional Metrics and KPIs
5.12 The Need for Value Metrics
5.13 Creating a Value Metric
5.14 Presenting the Value Metric in a Dashboard
5.15 Industry Examples of Value Metrics
5.16 Use of Crisis Dashboards for Out-of-Range Value Attributes
5.17 Establishing a Metrics Management Program
5.18 Using Value Metrics for Forecasting
5.19 Metrics and Job Descriptions
5.20 Graphical Representation of Metrics
5.21 Creating a Project Value Baseline
Chapter 6: Dashboards
6.0 Introduction
6.1 Traffic Light Dashboard Reporting
6.2 Dashboards and Scorecards
6.3 Benefits of Dashboards
6.4 Rules for Dashboards
6.5 Bitwork, Inc.: Ten Questions to Ask before Implementing a Dashboard or Reporting System
6.6 BrightPoint Consulting, Inc.: Designing Executive Dashboards
6.7 All That Glitters Is Not Gold
6.8 Using Emoticons
6.9 Agile and Scrum Metrics
6.10 Mashup Dashboards
6.11 Dashboard Design Tips
6.12 Pureshare, Inc.
6.13 LogiXML, Inc.: Dashboard Best Practices
6.14 A Simple Template
6.15 Summary of Dashboard Design Requirements
6.16 Dashboard Limitations
6.17 The dashboard pilot run
6.18 Evaluating Dashboard Vendors
6.19 New Dashboard Applications
Chapter 7: Dashboard Applications
7.0 Introduction
7.1 Dashboards in Action: Ventyx, An ABB Company
7.2 Dashboards in Action: Johnson Controls, Inc.
7.3 Dashboards in Action: Computer Associates, Inc.
7.4 Dashboards in Action: PIEmatrix, Inc.
7.5 PIEmatrix Overview
7.6 Dashboards in Action: International Institute for Learning
7.7 Dashboards in Action: Westfield Insurance
7.8 Dashboards In Action: Mahindra Satyam
Chapter 8: Measurement-Driven Project Management
8.0 Introduction
8.1 Measurement Concepts
8.2 Definitions
8.3 Measurement Process
8.4 Additional Information On Measurement Categories
8.5 Final Comments
Index
Advertisement
Cover image: © Wiley
Cover design: © Ventyx, an ABB company
This book is printed on acid-free paper.
Copyright © 2013 by International Institute for Learning, Inc., New York, New York. All rights reserved
Published by John Wiley & Sons, Inc., Hoboken, New Jersey
Published simultaneously in Canada
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750–8400, fax (978) 646–8600, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748–6011, fax (201) 748–6008, or online at www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with the respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor the author shall be liable for damages arising herefrom.
For general information about our other products and services, please contact our Customer Care Department within the United States at (800) 762–2974, outside the United States at (317) 572–3993 or fax (317) 572–4002.
Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.
Library of Congress Cataloging-in-Publication Data
Kerzner, Harold.
Project management metrics, KPIs, and dashboards : a guide to measuring and monitoring project performance / Harold Kerzner, Ph.D., Sr. Executive Director for Project Management, The International Institute for Learning.—Second edition.
pages cm.
Includes index.
ISBN 978-1-118-52466-4 (cloth); 978-111-8-65895-6 (ebk.); 978-111-8-65899-4 (ebk.)
1. Project management. 2. Project management—Quality control. 3. Performance standards. 4. Work measurement. I. Title.
HD69.P75K492 2013
658.4'04—dc23
2013004686
PREFACE
The ultimate purpose of metrics and dashboards is not to provide more information but to provide the right information to the right person at the right time, using the correct media and in a cost-effective manner. This is certainly a challenge. As computer technology has grown, so has the ease with which information can be generated and presented to management and stakeholders. Today, everyone seems concerned about information overload. Unfortunately, the real issue is non-information overload. In other words, there are too many useless reports that cannot easily be read and that provide readers with too much information, much of which may have no relevance. It simply distracts us from the real issues.
Insufficient or ineffective metrics prevent us from understanding what decisions really need to be made. In traditional project review meetings, emphasis is placed upon a detailed schedule analysis and a lengthy review of the cost baseline versus actual expenditures. The resulting discussion and explanation of the variances are most frequently pure guesswork. Managers who are upset about the questioning by senior management then make adjustments that do not fix the problems but limit the time they will be grilled by senior management at the next review meeting. They then end up taking actions that may be counterproductive to the timely completion of the project and real issues are hidden.
You cannot correct or improve something that cannot be effectively identified and measured. Without effective metrics, managers will not respond to situations correctly and will end up reinforcing undesirable actions by the project team. Keeping the project team headed in the right direction cannot be done easily without effective identification and measurement of metrics.
When all is said and done, we wonder why we have studies like the Chaos Report, which has shown us over the past 15 years that only about 30 percent of IT projects are completed successfully. We then identify hundreds of causes as to why projects fail, but neglect what is now being recognized as perhaps the single most important cause: a failure in metrics management.
Metrics management should be addressed in all of the areas of knowledge in the PMBOK® Guide, especially communications management. We are now struggling to find better ways of communicating on projects. Our focus today is on the unique needs of the receiver of the information. The need to make faster and better decisions mandates better information. Human beings have a variety of ways in which they can absorb information. We must address all of these ways in the selection of the metrics and the design of the dashboards that convey this information.
The three most important words in a stakeholder’s vocabulary are, “making informed decisions.” This is usually the intent of effective stakeholder relations management. Unfortunately, this cannot be accomplished without an effective information system based upon meaningful and informative metrics and key performance indicators (KPIs).
All too often, we purchase project management software and reluctantly rely upon the report generators, charts, and graphs to provide the necessary information, even when we realize that this information is either not sufficient or has limited value. Even those companies that create their own project management methodologies neglect to consider the metrics and KPIs that are needed for effective stakeholder relations management. Informed decisions require effective information. We all seem to understand this, yet it has only been in recent years that we have tried to do something about it.
For decades we believed that the only information that needed to be passed on to the client and the stakeholders was information related to time and cost. Today, we realize that the true project status cannot be determined from time and cost alone. Each project may require its own unique metrics and key performance indicators. The future of project management may very well be metric-driven project management.
Information design has finally come of age. Effective communications is the essence of information design. Today, we have many small companies that are specialists in business information design. Larger companies may maintain their own specialist team and call these people graphic designers, information architects, or interaction designers. These people maintain expertise in the visual display of both quantitative and qualitative information necessary for informed decision making.
Traditional communications and information flow has always been based upon tables, charts, and indexes that were hopefully organized properly by the designer. Today, information or data graphics combines points, lines, charts, symbols, images, words, numbers, shades, and a symphony of colors necessary to convey the right message easily. What we know with certainty is that dashboards and metrics are never an end in themselves. They go through continuous improvement and are constantly updated. In a project management environment, each receiver of information can have different requirements and may request different information during the life cycle of the project.
With this in mind, the book is structured as follows:
Chapters 1 and 2 identify how project management has changed over the last few years and more pressure is being placed upon the organization for effective metrics management.
Chapter 3 provides an understanding of what metrics are and how they can be used.
Chapter 4 discusses key performance indications and explains the difference between metrics and KPIs.
Chapter 5 focuses on the value-driven metrics and value-driven key performance indicators. Stakeholders are asking for more metrics related to the project’s ultimate value. The identification and measurement of value-driven metrics can be difficult.
Chapter 6 describes how dashboards can be used to present the metrics and KPIs to the stakeholders. Examples of dashboards are included together with some rules for dashboard design.
Chapter 7 identifies dashboards that are being used by companies.
Chapter 8 provides various techniques for the actual measurement of the metric and the KPI. Metrics and KPIs serve no viable purpose if they cannot be effectively measured.
Harold Kerzner, Ph.D.
Sr. Executive Director for Project Management
The International Institute for Learning
CHAPTER 1
THE CHANGING LANDSCAPE OF PROJECT MANAGEMENT
CHAPTER OVERVIEW
The way we managed projects in the past will not suffice for many of the projects we are managing now, as well as for the projects of the future. The complexity of these projects will place pressure on organizations to better understand how to identify, select, measure, and report project metrics. The future of project management may very well be metric-driven project management.
CHAPTER OBJECTIVES
To understand how project management has changed
To understand the need for project management metrics
To understand the need for better, more complex project management metrics
KEY WORDS
Certification Boards
Complex Projects
Engagement Project Management
Frameworks
Governance
Project Management Methodologies
Project Success
1.0 INTRODUCTION
For more than 50 years project management has been in use but perhaps not on a worldwide basis. What differentiated companies that were using project management in the early years was whether or not they used project management, not how well they used it. Today, almost every company uses project management, and the differentiation is whether they are simply good at project management or whether they truly excel at project management. The difference between using project management and being good at project management is relatively small, and most companies can become good at project management in a relatively short time period, especially if they have executive-level support. A well-organized project management office (PMO) can also accelerate the maturation process. The difference, however, between being good and excelling at project management is quite large. One of the critical differences is that excellence in project management on a continuous basis requires more metrics than just time and cost. The success of a project cannot be determined just from the time and cost metrics, yet we persist in the belief that this is possible.
Companies such as IBM, Microsoft, Siemens, Hewlett-Packard, Computer Associates, and Deloitte, just to name a few, have come to the realization that they must excel at project management. This requires additional tools and metrics to support project management. IBM has more than 300,000 employees with more that 70 percent outside of the United States. This includes some 30,000 project managers. Hewlett-Packard (HP) has more than 8000 project managers and 3500 Project Management Professionals (PMP®s). HP desires 8000 project managers and 8000 PMP®s. These numbers are now much larger with HP’s acquisition of Electronic Data Systems (EDS).
1.1 EXECUTIVE VIEW OF PROJECT MANAGEMENT
The companies mentioned previously perform strategic planning for project management and are focusing heavily on the future. Several of the things that these companies are doing will be discussed in this chapter, beginning with senior management’s vision of the future. Years ago, senior management provided lip service to project management, reluctantly supporting it to placate the customers. Today, senior management appears to have recognized the value in using project management effectively and maintains a different view of project management as shown in Table 1–1.
TABLE 1-1 The Executive View of Project Management
OLD VIEW
NEW VIEW
Project management is a career path.
Project management is a strategic or core competency necessary for the growth and survivability of the company.
We need our people certified as Project Management Professionals (PMP®s).
We need our people to undergo multiple certifications, at a minimum, to be certified in project management and corporate business processes.
Project managers will be used for project execution only.
Project managers will participate in the portfolio selection of projects and capacity-planning activities.
Business strategy and project execution are separate activities.
Part of the project manager’s job is to bridge strategy and execution.
Project managers make solely project-based decisions.
Project managers make both project and business decisions.
Project management is no longer regarded as a part-time occupation or even a career path position. It is now viewed as a strategic competency needed for the survival of the firm. Superior project management capability can make the difference between winning and losing a contract.
For more than 20 years, becoming a PMP® was seen as the light at the end of the tunnel. Today, that has changed. Becoming a PMP® is the light at the entryway to the tunnel. The light at the end of the tunnel may require multiple certifications. As an example, after becoming a PMP®, a project manager may desire to become certified in:
Business Analyst Skills or Business Management
Program Management
Business Processes
Managing Complex Projects
Six Sigma
Risk Management
Some companies have certification boards, which meet frequently and discuss what certification programs would be of value for their project managers. Certification programs that require specific knowledge of company processes or company intellectual property may be internally developed and taught by the company’s own employees.
Executives have come to the realization that there is a return on investment in project management education. Therefore, executives are now investing heavily in customized project management training, especially in the behavioral courses. As an example, one executive commented that he felt that presentation skills training was the highest priority for his project managers. If a project manager makes a highly polished presentation before the client, the client believes that the project is being managed the same way. If the project manager makes a poor presentation, then the client might believe the project is managed the same way. Other training programs that executives feel would be beneficial for the future include:
Establishing metrics and key performance indicators (KPIs)
Dashboard design
Managing complex projects
How to perform feasibility studies and cost–benefit analyses
Business analysis
Business case development
How to validate and revalidate project assumptions
How to establish project governance
How to manage multiple stakeholders
How to design and implement “fluid” or adaptive enterprise project management methodologies
How to develop coping skills and stress management skills
Project managers are now being brought on board projects at the beginning of the initiation phase rather than at the end of the initiation phase. To understand the reason for this, consider the following situation:
SITUATION: A project team is assembled at the end of the initiation phase of a project to develop a new product for the company. The project manager is given the business case for the project together with a listing of the assumptions and constraints. Eventually, the project is completed, somewhat late and significantly over budget. When asked by marketing and sales why the project costs were so large, the project manager responds, “According to my team’s interpretation of the requirements and the business case, we had to add in more features than we originally thought.”
Marketing then replies, “The added functionality is more than what our customers actually need. The manufacturing costs for what you developed will be significantly higher than anticipated and that will force us to raise the selling price. We may no longer be competitive in the market segment we were targeting.”
“That’s not our problem,” responds the project manager. “Our definition of project success is the eventual commercialization of the product. Finding customers is your problem, not our problem.”
Needless to say, we could argue about what the real issues were in this project that created the problems. For the purpose of this book, there are two issues that stand out. First and foremost, project managers today are paid to make business decisions as well as project decisions. Making merely project-type decisions could result in the development of a product that is either too costly to build or overpriced for the market at hand. Second, the traditional metrics used by project managers over the past several decades were designed for project rather than business decision making. Project managers must recognize that, with the added responsibilities of making business decisions, a new set of metrics may need to be included as part of the project manager’s responsibility. Likewise, we could argue that marketing was remiss in not establishing and tracking business-related metrics throughout the project and simply waited until the project was completed to see the results.
1.2 COMPLEX PROJECTS1
For more three decades, project management has been used to support traditional projects. Traditional projects are heavily based upon linear thinking; we have well-structured life cycle phases and templates, forms, guidelines, and checklists for each phase. As long as the scope is reasonably well defined, traditional project management works well.
Unfortunately, only a small percentage of all of the projects within a company fall into this category. Most nontraditional or complex projects use seat-of-the-pants management because they are largely based upon business scenarios where the outcome or expectations can change from day to day. Therefore, project management techniques were neither required nor used on these complex projects that were more business oriented and aligned to five-year or ten-year strategic plans that were constantly updated.
Now, we are finally realizing that project management can be used on these complex projects, but the traditional project management processes may be inappropriate or must be modified. This includes looking at project management metrics and KPIs in a different light. The leadership style for complex projects may not be the same as that for traditional projects. Risk management is significantly more difficult on complex projects, and the involvement of more participants and stakeholders is necessary.
Now that we have become good at traditional projects, we are focusing our attention on the nontraditional or complex projects. Unfortunately, there is no clear-cut definition of a complex project. Some of the major differences between traditional and nontraditional or complex projects, in the author’s opinion, are shown in Table 1–2.
TABLE 1-2 Traditional versus Nontraditional Projects
TRADITIONAL PROJECTS
NONTRADITIONAL PROJECTS
The time duration is 6–18 months.
The time duration can be several years.
The assumptions are not expected to change over the duration of the project.
The assumptions can and will change over the project’s duration.
Technology is known and will not change over the project’s duration.
Technology will most certainly change.
People that started on the project will remain through to completion (the team and the project sponsor).
People who approved the project and are part of the governance may not be there at the project’s conclusion.
The statement of work is reasonably well defined.
The statement of work is ill defined and subject to numerous scope changes.
The target is stationary.
The target may be moving.
There are few stakeholders.
There are multiple stakeholders.
There are few metrics and key performance indicators.
There can be numerous metrics and key performance indicators.
Comparing Traditional and Nontraditional Projects
The traditional project that most people manage is usually less than 18 months. In some companies, the traditional project might be six months or less. The length of the project is usually dependent on the industry. In the auto industry, for example, a traditional project is three years.
With projects that are 18 months or less, we assume that technology is known with some degree of assuredness and technology may undergo little change over the life of the project. The same holds true for the assumptions. We tend to believe that the assumptions made at the beginning of the project will remain intact for the duration of the project unless a crisis occurs.
People that are assigned to the project will most likely stay on board the project from beginning to end. The people may be full-time or part-time. This includes the project sponsor as well as the team members.
Because the project lasts 18 months or less, the statement of work is usually reasonably well defined and the project plan is based upon reasonably well-understood and proven estimates. Cost overruns and schedule slippages can occur, but not to the degree that they will happen on complex projects. The objectives of the project, as well as critical milestone or deliverable dates, are reasonably stationary and not expected to change unless a crisis occurs.
The complexities of nontraditional projects seem to have been driven in the past by time and cost. Some people believe that these are the only two metrics that need to be tracked on a continuous basis. Complex projects may run as long as 10 years, or even longer. Because of the long time duration, the assumptions made at the initiation of the project will most likely not be valid at the end of the project. The assumptions will have to be revalidated throughout the project. There can be numerous metrics, and the metrics can change over the duration of the project. Likewise, technology can be expected to change throughout the project. Changes in technology can create significant and costly scope changes to the point where the final deliverable does not resemble the initially planned deliverable.
People on the governance committee and in decision-making roles most likely are senior people and may be close to retirement. Based upon the actual length of the project, the governance structure can be expected to change throughout the project if the project’s duration is 10 years or longer.
Because of scope changes, the statement of work may undergo several revisions over the life cycle of the project. New governance groups and new stakeholders can have their own hidden agendas and demand that the scope be changed or they might even cancel their financial support for the project. Finally, whenever you have a long-term complex project where continuous scope changes are expected, the final target may move. In other words, the project plan must be constructed to hit a moving target.
SITUATION: A project manager was brought on board a project and provided with a project charter than included all of the assumptions made in the selection and authorization of the project. Part way through the project, some of the business assumptions changed. The project manager assumed that the project sponsor would be monitoring the enterprise environmental factors for changes in the business assumptions. That did not happen. The project was eventually completed, but there was no real market for the product.
Given the premise that project managers are now more actively involved in the business, we must track the assumptions the same way that we track budgets and schedules. If the assumptions are wrong or no longer valid, then we may need to either change the statement of work or even consider canceling the project. We should also track the expected value at the end of the project because unacceptable changes in the final value may be another reason for project cancellation.
Examples of assumptions that are likely to change over the duration of a project, especially on a long-term project, include:
The cost of borrowing money and financing the project will remain fixed.
Procurement costs will not increase.
The breakthrough in technology will take place as scheduled.
The resources with the necessary skills will be available when needed.
The marketplace will readily accept the product.
Our competitors will not catch up to us.
The risks are low and can be easily mitigated.
The political environment in the host country will not change.
The problem with having faulty assumptions is that they can lead to bad results and unhappy customers. The best defense against poor assumptions is good preparation at project initiation, including the development of risk mitigation strategies and tracking metrics for critical assumptions. However, it may not be possible to establish metrics for the tracking of all assumptions.
Most companies either have or are in the process of developing an enterprise project management methodology (EPM). EPM systems are usually rigid processes designed around policies and procedures, and work efficiently when the statement of work is well defined. With the new type of projects expected over the next decade, however, these rigid and inflexible processes may be more of a hindrance.
EPM systems must become more flexible in order to satisfy business needs. The criteria for good systems will lean toward forms, guidelines, templates, and checklists rather than policies and procedures. Project managers will be given more flexibility in order to make decisions necessary to satisfy the business needs of the project. The situation is further complicated in that all active stakeholders may wish to use their own methodology, and having multiple methodologies on the same project is never a good idea. Some host countries may be quite knowledgeable in project management, whereas other may have just cursory knowledge.
In the future, having a fervent belief that the original plan is correct may be a poor assumption. As the project’s business needs change, the need to change the plan will be evident. Also, decision making based entirely upon the triple constraints, with little regard for the final value of the project, may result in a poor decision. Simply stated, today’s view of project management is quite different from the views in the past, and this is partially the result of recognizing the benefits of project management over the past two decades.
We can now summarize some of the differences between managing traditional and complex projects. These are shown in Table 1–3. Perhaps the primary difference is whom the project manager must interface with on a daily basis. With traditional projects, the project manager interfaces with the sponsor and the client, both of whom may provide the only governance on the project. With complex projects, governance is by committee and there can be multiple stakeholders whose concerns need to be addressed.
TABLE 1-3 Summarized Differences between Traditional and Nontraditional Projects
MANAGING TRADITIONAL PROJECTS
MANAGING NONTRADITIONAL PROJECTS
Single-person sponsorship
Governance by committee
Possibly a single stakeholder
Multiple stakeholders
Project decision making
Both project and business decision making
An inflexible project management methodology
Flexible or “fluid” project management methodology
Periodic status reporting
Real-time reporting
Success is defined by the triple constraints.
Success is defined by competing constraints, value, and other factors.
Metrics and KPIs are derived from the earned value measurement system.
Metrics and KPIs may be unique to the particular project and even to a particular stakeholder.
Defining Complexity
Complex projects can differ from traditional projects for a multitude of reasons, including:
Size
Dollar value
Uncertain requirements
Uncertain scope
Uncertain deliverables
Complex interactions
Uncertain credentials of the labor pool
Geographical separation across multiple time zones
Use of large virtual teams
Other differences
There are numerous definitions of a complex project, based upon the interactions of two or more of the preceding elements. Even a small, two-month infrastructure project can be considered complex according to the definition. This can create havoc when selecting and using metrics. The projects that you manage within your own company can be regarded as complex projects if the scope is large and the statement of work is only partially complete. Some people believe that R&D projects are always complex because, if you can lay out a plan for R&D, then you probably do not have R&D. R&D is when you are not 100 percent sure where you are heading, you do not know what it will cost, and you do not know if and when you will get there.
Complexity can be defined according to the number of interactions that must take place for the work to be executed. The greater the number of functional units that must interact, the harder it is to perform the integration. The situation becomes more difficult if the functional units are dispersed across the globe and if cultural differences makes integration difficult. Complexity can also be defined according to size and length. The larger the project is in scope and cost, and the greater the time frame, the more likely it is that scope changes will occur significantly, affecting the budget and schedule. Large, complex projects tend to have large cost overruns and schedule slippages. Good examples of this are Denver International Airport, the Channel between England and France, and the “Big Dig” in Boston.
Tradeoffs
Project management is an attempt to improve efficiency and effectiveness in the use of resources by getting work to flow multidirectionally through an organization. This holds true for both traditional projects and complex projects. Initially, this might seem easy to accomplish, but there are typically a number of constraints imposed upon a project. The most common constraints are time, cost, and performance (also referred to as scope or quality) and are known as “the triple constraints.”
From an executive-level perspective, the goal of project management may be meeting the triple constraints of time, cost, and performance, while maintaining good customer relations. Unfortunately, because most projects have some unique characteristics, highly accurate estimates may not be possible and tradeoffs between the triple constraints may be necessary. As will be discussed later, there may be significantly more than three constraints on a project, and metrics may have to be established to track each of the constraints. The metrics provide the basis for informed tradeoff decision making. Executive management, functional management, and key stakeholders must be involved in almost all tradeoff discussions to ensure that the final decision is made in the best interests of the project, the company, and the stakeholders. If multiple stakeholders are involved, as there are on complex projects, then agreement from all of the stakeholders may be necessary. Project managers may possess sufficient knowledge for some technical decision making but may not have sufficient business or technical knowledge to adequately determine the best course of action to address the interests of the parent company as well as the individual stakeholders on the project.
Skill Set
All project managers have skills, but not all project managers will have the right skills for the given job. For projects internal to a company, it may be possible to develop a company-specific skill set or company-specific body of knowledge. Specific training courses can be established to support company-based knowledge requirements.
For complex projects with a multitude of stakeholders, all from different countries with different cultures, finding the perfect project manager may be an impossible task. Today, we are in the infancy stage of understanding complex projects and the accompanying metrics, and we may not be able to determine the ideal skill set for managing complex projects. We must remember that project management existed for more than three decades before we created the first Project Management Body of Knowledge (PMBOK® Guide), and even now with the fifth edition, it is still referred to as a “guide.”
We can, however, conclude that there are certain skills required to manage complex projects. Some additional skills needed might be: how to manage virtual teams; understanding cultural differences; managing multiple stakeholders, each of whom may have a different agenda; understanding the impact of politics on project management; and selecting and measuring project metrics.
Governance
Cradle-to-grave user involvement in complex projects is essential. What is unfortunate is that user involvement can change because of politics and the length of the project. It is not always possible to have the same user community attached to the project from beginning to end. Promotions, changes in power and authority positions because of elections, and retirements can cause a shift in user involvement.
Governance is the process of decision making. On large complex projects, governance will be in the hands of the many rather than the few. Each stakeholder may either expect or demand to be part of all critical decisions on the project. This must be supported by proper metrics that provide meaningful information. The channels for governance must be clearly defined at the beginning of the project, possibly before the project manager is assigned. Changes in governance, which are increasingly expected, the longer the project takes, can have a serious impact on the way the project is managed, as well as on the metrics used.
Decision Making
Complex projects have complex problems. All problems generally have solutions, but not all solutions may be good or even practical. Good metrics can make decision making easier. Also, some solutions to problems can be more costly than other solutions. Identifying a problem is usually easy. Identifying alternatives may require the involvement of many stakeholders, and each stakeholder may have a different view of the actual problem and the possible alternatives. To complicate matters, some host countries have very long decision-making cycles, for the identification of the problem as well as for the selection of the best alternative. Each stakeholder may select an alternative that is in the best interests of that particular stakeholder rather than in the best interests of the project.
Obtaining approval can take just as long, especially if the solution requires that additional capital be raised and if politics play an active role. In some emerging countries, every complex project may require the signature of a majority of the ministers and senior government leaders. Decisions may be based upon politics and religion as well.
Fluid Methodologies
With complex projects, the project manager needs a fluid or flexible project management methodology capable of interfacing with multiple stakeholders. The methodology may need to be aligned more with business processes than with project management processes, since the project manager may need to make business decisions as well as project decisions. Complex projects seem to be dictated more by business decisions than by pure project decisions.
Complex projects are driven more by the project’s end value than by the triple or competing constraints. Complex projects tend to take longer than anticipated and cost more than originally budgeted because of the need to guarantee that the final result will have the value desired by the customers and stakeholders. Simply stated, complex projects tend to be value-driven rather than driven by the triple or competing constraints.
1.3 GLOBAL PROJECT MANAGEMENT
Every company in the world has complex projects that they would have liked to undertake but were unable to because of limitations such as:
No project portfolio management function to evaluate projects
A poor understanding of capacity planning
A poor understanding of project prioritization
A lack of tools for determining project value
A lack of project management tools and software
A lack of sufficient resources
A lack of qualified resources
A lack of support for project management education
A lack of a project management methodology
A lack of knowledge in dealing with complexity
A fear of failure
A lack of understanding of metrics needed to track the project
Because not every company has the capability to manage these complex projects, they must look outside for suppliers of project management services. Companies that provide these services on a global basis consider themselves to be business solution providers and differentiate themselves from localized companies according to the elements in Table 1–4.
TABLE 1-4 Global versus Nonglobal Companies
FACTOR
NONGLOBAL
GLOBAL
Core business
Sell products and services
Sell business solutions
PM satisfaction level
Must be good at project management
Must excel at project management
PM methodology
Rigid
Flexible and fluid
Metrics/KPIs
Minimal
Extensive
Supporting tools
Minimal
Extensive
Continuous Improvement
Follow the leader
Capture best practices and lessons learned
Business knowledge
Know your company’s business
Understand the client’s business as well as your company’s business
Type of team
Co-located
Virtual
Those companies that have taken the time and effort to develop flexible project management methodologies and become solution providers are companies that are competing in the global marketplace. Although these companies may have as part of their core business the providing of products and services, they may view their future as being a global solution provider for the management of complex projects.
For these companies, being good at project management is not enough; they must excel at project management. They must be innovative in their processes to the point that all processes and methodologies are highly fluid and easily adaptable to a particular client. They have an extensive library of tools to support the project management processes. Most of the tools were created internally with ideas discovered through captured lessons learned and best practices.
1.4 PROJECT MANAGEMENT METHODOLOGIES AND FRAMEWORKS
Most companies today seem to recognize the need for one or more project management methodologies but either create the wrong methodologies or misuse the methodologies that have been created. Many times, companies rush into the development or purchasing of a methodology without any understanding of the need for one other than the fact that their competitors have a methodology. Jason Charvat states:2
Using project management methodologies is a business strategy allowing companies to maximize the project’s value to the organization. The methodologies must evolve and be “tweaked” to accommodate a company’s changing focus or direction. It is almost a mind-set, a way that reshapes entire organizational processes: sales and marketing, product design, planning, deployment, recruitment, finance, and operations support. It presents a radical cultural shift for many organizations. As industries and companies change, so must their methodologies. If not, they’re losing the point.
There are significant advantages to the design and implementation of a good, flexible methodology:
Shorter project schedules
Reduces and/or provides better control of costs
Prevents unwanted scope changes
Can plan for better execution
Can predict results more accurately
Improves customer relations during project execution
Can adjust the project during execution to fit changing customer requirements
Provides senior management with better visibility of status
Provides standardization in execution
Captures best practices
Rather than using policies and procedures, some methodologies are constructed as a set of forms, guidelines, templates, and checklists that can and must be applied to a specific project or situation. It may not be possible to create a single enterprise-wide methodology that can be applied to each and every project. Some companies have been successful doing this, but there are still many companies that successfully maintain more than one methodology. Unless the project manager is capable of tailoring the enterprise project management methodology to his/her needs, more than one methodology may be necessary.
There are several reasons why good intentions often go astray. At the executive levels, methodologies can fail if the executives have a poor understanding of what a methodology is and believe that a methodology is:3
A quick fix
A silver bullet
A temporary solution
A cookbook approach for project success
At the working levels, methodologies can also fail if they:4
Are abstract and high level
Contain insufficient narratives to support these methodologies
Are not functional or do not address crucial areas
Ignore the industry standards and best practices
Look impressive but lack real integration into the business
Use nonstandard project conventions and terminology
Compete for similar resources without addressing this problem
Don’t have any performance metrics
Take too long to complete because of bureaucracy and administration
Other reasons why methodologies can fail include:
The methodology must be followed exactly even if the assumptions and environmental input factors have changed.
The methodology focuses on linear thinking.
The methodology does not allow for out-of-the-box thinking.
The methodology does not allow for value-added changes that are not part of the original requirements.
The methodology does not fit the type of project.
The methodology is too abstract (rushing to design it).
The methodology development team neglects to consider bottlenecks and the concerns of the user community.
The methodology is too detailed.
The methodology takes too long to use.
The methodology is too complex for the market, clients, and stakeholders to understand.
The methodology does not have sufficient or correct metrics.
Deciding on what type of methodology is not an easy task. There are many factors to consider such as:5
The overall company strategy—how competitive are we as a company?
The size of the project team and/or scope to be managed
The priority of the project
How critical the project is to the company
How flexible the methodology and its components are
There are numerous other factors that can influence the design of a methodology. Some of these factors include:
Corporate strategy
Complexity and size of the projects in the portfolio
Management’s faith in project management
Development budget
Number of life cycle phases
Technology requirements
Customer requirements
Training requirements and costs
Supporting tools and software costs
Project management methodologies are created around the project management maturity level of the company and the corporate culture. If the company is reasonably mature in project management and has a culture that fosters cooperation, effective communication, teamwork, and trust, then a highly flexible methodology can be created based upon guidelines, forms, checklists, and templates. As stated previously, the more flexibility that is added into the methodology, the greater the need for a family of metrics and KPIs. Project managers can pick and choose the parts of the methodology and metrics that are appropriate for a particular client. Organizations that do not possess either of these two characteristics rely heavily upon methodologies constructed with rigid policies and procedures, thus creating significant paperwork requirements with accompanying cost increases, and removing the flexibility that the project manager needs to adapt the methodology to the needs of a specific client. These rigid methodologies usually rely upon time and cost as the only metrics and can make it nearly impossible to determine the real status of the project.
Jason Charvat describes these two types as light methodologies and heavy methodologies:6
Light Methodologies
Ever-increasing technological complexities, project delays, and changing client requirements brought about a small revolution in the world of development methodologies. A totally new breed of methodology—which is agile, adaptive, and involves the client every part of the way—is starting to emerge. Many of the heavyweight methodologists were resistant to the introduction of these “lightweight” or “agile” methodologies (Fowler, 20017). These methodologies use an informal communication style. Unlike heavyweight methodologies, lightweight projects have only a few rules, practices, and documents. Projects are designed and built on face-to-face discussions, meetings, and the flow of information to the clients. The immediate difference of using light methodologies is that they are much less documentation-oriented, usually emphasizing a smaller amount of documentation for the project.
Heavy Methodologies
The traditional project management methodologies (i.e., SDLC approach) are considered bureaucratic or “predictive” in nature and have resulted in many unsuccessful projects. These heavy methodologies are becoming less popular. These methodologies are so laborious that the whole pace of design, development, and deployment slows down—and nothing gets done. Project managers tend to predict every milestone because they want to foresee every technical detail (i.e., software code or engineering detail). This leads managers to start demanding many types of specifications, plans, reports, checkpoints, and schedules. Heavy methodologies attempt to plan a large part of a project in great detail over a long span of time. This works well until things start changing, and the project managers inherently try to resist change.
Frameworks
More and more companies today, especially those that wish to compete in the global marketplace as a business solution provider, are using frameworks rather than methodologies.
Framework:
The individual segments, principles, pieces, or components of the processes needed to complete a project. This can include forms, guidelines, checklists, and templates.
Methodology:
The orderly structuring or grouping of the segments or framework elements. This can appear as policies, procedures, or guidelines.
Frameworks focus on a series of processes that must be done on all projects. Each process is supported by a series of forms, guidelines, templates, checklists, and metrics that can be applied to a particular client’s business needs. The metrics will be determined jointly by the project manager, the client, and the various stakeholders.
As stated previously, a methodology is a series of processes, activities, and tools that are part of a specific discipline, such as project management, and designed to accomplish a specific objective. When the products, services, or customers have similar requirements and do not require significant customization, companies develop methodologies to provide some degree of consistency in the way that projects are managed. With these methodologies, the metrics, once established, usually remain the same for every project.
As companies become reasonably mature in project management, the policies and procedures are replaced by forms, guidelines, templates, and checklists. This provides more flexibility for the project manager in how to apply the methodology to satisfy a specific customer’s requirements. This leads to a more informal application of the project management methodology, and significantly more metrics are now required.
Today, this informal project management approach has been somewhat modified and called a framework. A framework is a basic conceptual structure that is used to address an issue, such as a project. It includes a set of assumptions, project-specific metrics, concepts, values, and processes that provide the project manager with a means for viewing what is needed to satisfy a customer’s requirements. A framework is a skeletal support structure for building the project’s deliverables.
Frameworks work well as long as the project’s requirements do not impose severe pressure upon the project manager. Unfortunately, in today’s chaotic environment, this pressure appears to be increasing because:
Customers are demanding low-volume, high-quality products with some degree of customization.
Project life cycles and new product development times are being compressed.
Enterprise environmental factors are having a greater impact on project execution.
Customers and stakeholders want to be more actively involved in the execution of projects.
Companies are developing strategic partnerships with suppliers, and each supplier can be at a different level of project management maturity.
Global competition has forced companies to accept projects from customers that are all at a different level of project management maturity.
These pressures tend to slow down the decision-making processes at a time when stakeholders want the processes to be accelerated. This slowdown is the result of:
The project manager being expected to make decisions in areas where he/she has limited knowledge.
The project manager hesitating to accept full accountability and ownership for the projects.
Excessive layers of management being superimposed on the project management organization.
Risk management is being pushed up to higher levels in the organizational hierarchy.
The project manager demonstrates questionable leadership ability.
Both methodologies and frameworks are mechanisms by which we can obtain best practices and lessons learned in the use of metrics and KPIs. Figure 1–1 illustrates the generic use of a methodology or framework. Once we identify the clients and stakeholders, we then input the requirements, business case, and accompanying assumptions. The methodology then guides us through the PMBOK® Guide process groups of initiation (I), planning (P), execution (E), monitoring and controlling (M), and closure (C). The methodology also provides us with guidance in the identification of metrics, KPIs, and dashboard reporting techniques for a particular client.
Figure 1-1 Generic Methodology
Some people believe that, once the deliverables are provided to the client and project closure takes place, the project is completed. This is not the case. More companies today are adding, at the end of the life cycle phases of the methodology, another life cycle phase, entitled “Customer Satisfaction Management.” The purpose of this phase is to meet with the client and the stakeholders and discuss what was learned on the project regarding best practices, lessons learned, metrics, and KPIs. The intent is to see what can be done better for that client on future projects. Today, companies maintain metric and KPI libraries the same way that they maintain libraries for best practices and lessons learned.
1.5 THE NEED FOR EFFECTIVE GOVERNANCE
The problems described previously can be resolved by using effective project governance. Project governance is actually a framework by which decisions are made. Governance relates to decisions that define expectations, accountability, responsibility, the granting of power, or the verifying of performance. Governance relates to consistent management, cohesive policies, processes, and decision-making rights for a given area of responsibility. Governance enables efficient and effective decision making to take place.
Every project can have different governance, even if each project uses the same enterprise project management methodology. The governance function can operate as a separate process or as part of project management leadership. Governance is not designed to replace project decision making but to prevent undesirable decisions from being made. Effective governance must be supported by a good project management information system (PMIS). The PMIS must have agreed upon metrics and key performance indicators such that informed decision making is possible rather than seat-of-the-pants decision making.
SITUATION: At the onset of a project, the governance committee agreed to make certain decisions to assist the project manager. Unfortunately, metrics were not established to support the governance committee. The result was a schedule slippage and a cost overrun due to delayed decision making.
Historically, governance was provided by the project sponsor. Today, governance is provided by a committee. The membership of the committee can change from project to project and industry to industry. The membership may also vary according to the number of stakeholders and whether the project is for an internal or external client.
1.6 ENGAGEMENT PROJECT MANAGEMENT
With project management viewed as a strategic competency today, it is natural for companies that wish to compete in a global marketplace to be strong believers in “engagement project management” or “engagement selling.” Years ago, the sales force would sell a product or services to a client and then move on to find another client. Today, the emphasis is on staying with the clients and looking for additional work from the same clients.
In a marital context, an engagement can be viewed as the beginning of a lifelong partnership. The same holds true with engagement project management. Companies like IBM and Hewlett-Packard no longer view themselves as selling products or services. Instead, they see themselves as business solution providers for their clients, and you cannot remain in business as a business solution provider without having superior project management capability.
As part of engagement project management, you must convince the client that you have the project management capability to provide solutions to their business needs on a repetitive basis. In exchange for this, you want the client to treat you as a strategic partner rather than as just another contractor. This is shown in Figure 1–2.
Figure 1-2 “Engagement” Project Management
International Institute for Learning, Inc.
Previously, we stated that those companies that wish to compete in a global environment must have superior project management capability. This capability must appear in the contractor’s response to a request for proposal issued by the client. Clients today are demanding the following in their proposal:
Show us the number of PMP®s in your company and identify which PMP® will manage this contract if you are the winner through competitive bidding.
Show us that you have an enterprise project management methodology or framework, and that it has a history of providing repeated successes.
Show us that you are willing to customize the framework or methodology to fit the client’s environment.
Show us the maturity level of project management in your company and identify which project management maturity model you used to perform the assessment.
Show us that you have a best practices library for project management and your willingness to share this knowledge with us, as well as the best practices you discover on our project.
Decades ago, the sales force (and marketing) had very little knowledge about project management. The role of the sales force was to win contracts, regardless of the concessions that had to be made. The project manager then “inherited” a project with an underfunded budget and an impossible schedule. Today, sales and marketing must understand project management and be able to sell it to the client as part of engagement selling. The sales force must sell the company’s project management methodology or framework and the accompanying best practices. Sales and marketing are now involved in project management.
Engagement project management benefits both the buyer and the seller, as shown in Table 1–5.
TABLE 1-5 Before and after Engagement Project Management
BEFORE ENGAGEMENT PROJECT MANAGEMENT
AFTER ENGAGEMENT PROJECT MANAGEMENT
Continuous competitive bidding
Sole-source or single-source contracting (fewer suppliers to deal with)
Focus on the near-term value of the deliverable
Focus on the lifetime value of the deliverable
Contractor provides minimal lifetime support for clients with their customers
Contractor provides lifetime support for customer value analyses (CVA) and customer value measurement (CVM)
Utilize one inflexible system
Access to contractor’s many systems
Limited metrics
Use of the contractor’s metrics library
The benefits of engagement project management are clear:
Both the buyer and the seller save on significant procurement costs by dealing with single-source or sole-source contracts without having to go through a formalized bidding process for each project.
Because of the potential long-term strategic partnership, the seller is interested in the lifetime value of the business solution rather than just the value at the end of the project.
You can provide lifelong support to your client as they try to develop value-driven relationships with their clients.
The buyer will get access to many of the project management tools used by the seller. The corollary is also true.
There is a risk in hiring consultants to manage your projects if they bring their own methodology and accompanying metrics that are not compatible to your business or your needs. You must make sure that the business solution providers demonstrate that:
Their approach is designed to your business model and strategy.
The metrics they bring with them fit your business model and strategy.
You understand the metrics they are proposing.
If necessary, they are willing to create additional metrics that fit your needs.
1.7 CUSTOMER RELATIONS MANAGEMENT
Engagement project management is forcing project managers to become active participants in customer relations management (CRM) activities. CRM activities focus on:
Identifying the right customers
Developing the right relationship with the customers
Maintaining customer retention
This cannot be done entirely by the project manager. Some companies have both engagement managers and project managers. These two individuals must work together to maintain customer satisfaction. Table 1–6 below shows the partial responsibilities of each.
TABLE 1-6 Engagement Manager versus Project Manager
CUSTOMER VALUE MANAGEMENT
ENGAGEMENT MANAGER
PROJECT MANAGER
Phase 1: Identifying the right customers
Strategic marketing
Proposal preparation
Engagement selling
Assist in proposal preparation
May report to engagement manager
Phase 2: Developing the right relationship
Defining acceptance criteria (metrics/KPIs)
Risk mitigation planning
Client briefings
Client invoicing
Soliciting satisfaction feedback and CRM
Supporting CRM
Establishing performance metrics
Measuring customer value and satisfaction
Improving customer satisfaction management
Phase 3: Maintaining Retention
Conducting customer satisfaction management meeting
Updating client metrics and KPIs
Attending customer satisfaction management meetings
Looking for future areas of improvement
1.8 OTHER DEVELOPMENTS IN PROJECT MANAGEMENT
For companies to be successful at managing complex projects on a repetitive basis and function as a solution provider, the project management methodology and accompanying tools must be fluid or adaptive. This means that you may need to develop a different project management approach when interfacing with each stakeholder, given the fact that each stakeholder may have different requirements and expectations, and the fact that most complex projects have long time spans. Figure 1–3 illustrates some of the new developments in project management. This applies to both traditional and nontraditional projects.
Figure 1-3 New Developments in Project Management
The five items in the figure fit together when done properly.
New success criteria:
At the initiation of the project, the project manager will meet with the client and the stakeholders to come to stakeholder agreements on what constitutes success on the project. Initially, many of the stakeholders may have their own definition of success, but the project manager must forge an agreement, if possible.
Key performance indicators:
Once the success criteria are agreed upon, the project manager and the project team will work with the stakeholders to define the metrics and key performance indicators that each stakeholder wishes to track. It is possible that each stakeholder will have different KPI requirements.
Measurement:
Before the metrics and KPIs are agreed to and placed on the dashboards, we must be sure we know how to perform the measurements. This is the hardest part because not all team members or strategic partners may have the capability or skills to measure all of the KPIs.
Dashboard design:
