The project manager wears no clothes
Fancier charts, software, and reports may look nice, but they're no substitutes for a wardrobe of basic value components.
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 of dollars on the development of a customer service and billing system, only to abandon it after three years and go with a more “out of the box” solution. How could these situations have 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 naked with regard to the most important project metric: value delivery.
Beyond “On Time, On Budget”
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 than being “on time, on budget.”
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. Why? 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 premise is that the scope given to a team is pretty much correct and complete. Regardless of whether or not they truly believe it, project teams still behave as if the project was 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 supposed 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.
End-Product Value = Project Value
To improve project management, our mindset 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?” Whether the end product is a new plant, an implementation of an IT system, or a new consumer product, the overall life-cycle value of a project has the same three components (see Exhibit 1).
End-Product Benefits. What do the stakeholders and users get out of the end product? There are three distinct subcategories:
Attributes. What's in it? What does it do?
Error density. How well does it do what it was intended to do?
Timing. How much value was gained for being early? How much lost for being late?
Ongoing Costs. What are the per-unit costs of production? What will it cost to operate, maintain, or administer?
Project Costs. What was the total cost of the project?
Although most project team members acknowledge that the combination of these three 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.
Incorporate Value From the Start
Most of the opportunity to create a value-based project comes at the very start of the project—so start even before the project begins. Participants in our workshops have found the following principles and activities particularly helpful:
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 anyway. Perhaps 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 the 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 percent of learning about value is usually discovered in the last 10 percent of the 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 do the prototype again. As you gain more confidence in your prototypes, show more and more users.
Communicate Simple Rules of Thumb. Create and communicate some simple rules of thumb that team members can use to determine the relative value of scope, quality, time, and budget. What is 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 is necessary. Better yet, analyze and mitigate risks, deliverable by deliverable, together with the entire team. The members know more about the details, and the project devil is in the details.
IS YOUR PROJECT “dressed for success”? Is it up to date in spiffy business duds that inspire confidence and deliver value, or is it, like the emperor's new clothes, lacking substance, easily seen through, leaving your project's nakedness on view for the world to see? ■
January 2001 PM Network