Project Management Institute

The project manager wears no clothes

Spiro Maroulis, PracticeFields

Winston J. Ledet, PracticeFields

Imagine this: The construction of a new plant finishes on time and under budget, except it takes four years before it is producing nearly as much as its designed capability. Or this: A major telecommunications company spends millions upon millions on the development of a customer service and billing system, only to abandon it after three years and go with a more “out the box” solution. How could these situations been avoided? Better “project management” right? Not exactly.

The most commonly proposed way to improve projects is to improve “project management.” This inevitably leads to more focus on using detailed planning and controlling tools. However, to today’s project manager, these tools are like the proverbial “emperor’s new clothes.” The better they dress with fancier Gantt charts, more powerful software, and more intricate earned value reports, the more evident it becomes that they are completely naked with regards to the most important project metric—value delivery.

Beyond “On Time, On Budget”

A Canadian energy company decided that an enterprisewide resource planning software program was necessary in order to efficiently manage their business. In addition to helping mange the business at the corporate level, the program would allow the engineers, operators, mechanics, and purchasing personnel at each of the plants to automate the existing paper system used to plan maintenance work and track materials inventory. After a careful evaluation process the corporate office selected a vendor and laid out a plan to roll out the implementation to all of their plants. They brought in the consultants, did some customizations, and proceeded as quickly as possible with the implementation. The project was managed in a professional manner. The vendor had a proven product and a proven methodology for implementation. Most of the requested functionality of the program was delivered when expected and without much cost variance.

However, no one bothered to explain to the plant workers at the plant why it the system was necessary. No one asked them for input on what they needed to do their work. No effort was made to create buy-in during the process. Aside from one training class after the system was implemented, no one showed them how the system could help. Currently, the process of doing the maintenance work at this company’s plants is less effective than ever. Plant workers are always inventing new ways to bypass the system they do not know how to use, or may not even have official access to, in order to get their work done. Parts are hidden. Materials and time are purposely charged to the wrong jobs. Operators are either unable or unwilling to use the “notification function” of the system to let mechanics know about equipment problems. Eighteen months after the implementation, this company is still struggling to incorporate this $30 million dollar effort into the way they do business. Actually, since so few people have been using the system, the corporate office has decided to save on software licensing costs by limiting the number of users.

This project is just one of many that illustrate that projects managed by the “on time, on budget” mantra alone—even with the common caveat of “and meets requirements”—are at best headed for mediocrity and at worst destined for abject failure. Projects are change events intended to create new value—new goods and services that in some way improve our organizations and societies. Unfortunately, somewhere between conception and implementation, teams forget that projects are about something greater meeting its constraints.

Over and over during the project simulation in our workshops and in the real work practices of clients, we witness adherence to two fundamentally faulty (and maybe even subconscious) premises. The first is that the scope given to a team is pretty much correct and complete. Regardless of whether they truly believe it or not, project teams still behave as if the project were handed down by the “scope gods”—all knowing, all seeing, geniuses who not only can predict the course of markets, but also possess a keen understanding of the minutia of every technology required for completion. This premise is obviously wrong and even laughable to anyone who has ever sponsored a project. You know that you make guesses, and sometimes wild assumptions, to come up with a preliminary design and plan. More in depth learning always occurs—and is suppose to occur—as the project progresses and matures.

The second premise is that time to market is the most critical factor for success. Though the value of time is frequently very important, it is never the only factor that determines total end-product value. (If you doubt this notion, ask the folks at Apple how valuable their two-year lead in the personal digital assistant market was when they created the widely panned Newton.) Even worse, many managers ignore the fact that schedule and budget overruns are not the cause of their problems, but instead they are frequently the result of a failure to effectively discover and manage scope. In the hurry to “get back on track,” project teams throw components of project value other than time and cost out the window.

Exhibit 1


End-Product Value = Project Value

The focus of today’s project management literature and actual project management practice is not on project value, but instead on project means. In The Project 50, Tom Peters claims that over 90% of the emphasis of today’s projects is on “implementation.” This emphasis, he says, comes at a great cost—neglecting to understand on the core reasons why we do projects (Peters, 1999).

Though it is hard to say if Peters’ numbers are exactly right, there are plenty of examples that support the claim that projects are not focused on value. For example, an east cost refinery executed its annual “turnaround”—a large project where they inspect and repair equipment that cannot be worked on while running. Since everyday the plant is down for a turnaround is day of missed production, turnaround teams are under tremendous schedule pressure. Additionally, because of the large amount of simultaneous work that takes place, turnarounds require a tremendous amount of control and coordination. Cost and schedule control are crucial for project success. On this particular turnaround, the project team did an excellent job of organizing the work and controlling cost and schedule. They completed all of the specified deliverables, finished two days ahead of schedule (in a three-week project), and completed the project with less than 1% budget overrun.

Was this a successful project? Unfortunately no. Despite being on time and on budget, the plant was in worse shape after the turnaround than before. Yields were below normal for weeks. Equipment failures were everywhere. There was even a large fire causing millions of dollars worth of damage (fortunately no one was hurt). It took the refinery months to recover from this “successful” project.

This example further illustrates that it is not enough to do good “project management.” In order to truly improve projects, our mindset and corresponding practices must change from “we’ll deliver what you need within the given constraints” to “what is the life-cycle value of this project and how can we maximize it?” Doing so will require recognizing that the life-cycle value of a project is made up of several components that collectively determine its ultimate success (see Exhibit 1).

1. End-product benefits. What do the stakeholders and users get out of the end product? There are three distinct subcategories here:

1. Attributes—What’s in it? What does it do?

2. Error Density—How well does it do what it was intended to do?

3. Timing—How much value was gained for being early? How much lost for being late?

2. Ongoing costs. What are the per unit costs of production? What will it cost to operate, maintain, or administer?

3. Project costs. What was the total cost of the project?

Although most project team members acknowledge that the combination of these components is the ultimate measure of success for a project, very few incorporate this notion into their actions on projects. They continue to manage only one or two subcomponents, usually the ones most easily measurable, like time and cost. In the example of the east cost refinery, the project managers and team focused on the project costs and delivery date. Had they focused more on ongoing costs and identifying key organizational needs before the turnaround, the outcome may have been different.

Incorporate Value From the Start

Tom Peters gives several good examples of managers focusing on project value. In one example, a person was assigned with the presumably mundane task of cleaning up a warehouse. She quickly noticed that a messy warehouse wasn’t the problem. The mess was created by the poor organization of the warehouse. Cleaning it once wouldn’t really do anything. Of course, she could have simply proceeded with mapping out a plan to clean up the mess be done with it, but instead she had the courage and passion to keep digging and create real value. She reframed the project into the “reorganize the warehouse” project. She took it upon herself to read a few benchmarking studies and get smarter on the subject. She sold the idea to others and recruited them for the project. Not only did the team reorganize the warehouse, but also since reorganizing the warehouse had to take into account ingoing and outgoing materials, their work ultimately to an entirely new—and much improved—distribution system (Peters, 1999).

As this example illustrates, most of the opportunity to create a value-based project comes at the very start of the project—so project managers need to start well before the project begins. Participants in our workshops have found the following principles and activities particularly helpful in focusing on value at the outset of projects:

Question the value of the project immediately. Dig as deeply as possible. Often the first reason given for undertaking a project only scratches the surface for why the project is being done. For example, if the goal is to install a new computer system, ask why? If the answer is to increase sales, ask how? If there is no clear answer, don’t just start. Maybe a makeshift pilot of the system can help you learn which components will really impact sales.

Create an elevator statement. Describe what you are working on to somebody in the time it takes to ride together on an elevator for a few floors. Do this together with your team. If you are having problems, you are probably not clear enough on the value of your project.

Identify all stakeholders. Identify all users and stakeholders and be exhaustive. Who will be the direct users of product? Who is the ultimate end-user? Who will operate and maintain it? Determine what value they hope to get from this project. Better Yet: Include key stakeholders in the kick-off meeting. Get them on board early!

Learn faster. Learning on projects is inevitable. It is not a matter of “if,” just when. Unfortunately, the experience of our workshop participants suggests that 90% of learning about value is usually discovered in the last 10% of project. How can you learn about value faster? Never stop asking about it. Better Yet: Prototype very quickly and get feedback from a couple of users you trust. Their comments will be more valuable if you give them something to see, touch, smell, and feel. Incorporate their feedback and prototype again. As you gain more confidence in your prototypes, show more and more users. Focusing project efforts around a tangible representation of the end product can have a large impact on a project team.

Communicate simple rules of thumb. Create and communicate some simple rules of thumb team members can use to determine the relative value of scope, quality, time and budget. What is a being a week early worth? How about a week late?

Attack risks aggressively. Risk destroys quality. Inevitably, when Murphy strikes, quality goes out the window and the need for recovery and completion takes over. Even worse, the “we’ll cross that bridge when we come to it” attitude ends up creating crises on the project, and keeps team members from seeing the big picture. Eliminate more risk from your project than you think necessary. Better Yet: Analyze and mitigate risks, deliverable by deliverable, together with the entire team. They know more about the details and the project devil is in the details.


The original vision of the business benefit frequently gets lost in the chaos of project implementation. Even the most diligent and advance planning and control efforts will not lead to success if organizational needs are ignored or misunderstood. Fortunately, every new project is an opportunity to start over. By emphasizing and incorporating all components of project value at the outset of your next project, you can to tap into the creativity and enthusiasm of your entire team and inspire them to create real value for your organization. After all, that’s why we take on projects in the first place.


Peters, Tom. The Wow Project. Fast Company 24 (May), p. 116.

Peters, Tom. (1999). The Project 50: Fifty Ways to Transform Every “Task” into a Project That Matters. New York: Alfred A. Knopf.

Schrage, Michael. (2000). Serious Play: How the World’s Best Companies Simulate to Innovate, Boston: Harvard Business School Press.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA



Related Content