Project Plan
Project managers are typically task-oriented people with a strong sense of urgency and a keen focus on getting started and finishing. Not too surprisingly, the inclination of most PMs is to skip strategic project planning and start work.
The Activity Trap
Instead of thinking strategically to define the measurable results the project should achieve, the PM and her sponsor usually focus on the bells and whistles of the project’s tasks. This is the activity trap, and it is an evil thing. When a PM dives head first into the gunk of the activity trap, the project planning takes the form of horse-trading. "Okay, if you can add your favorite task, then I get to add mine!" Most importantly, no one has agreed on what the project will achieve. After the project starts, tasks can change at the drop of a hat because there is no clear vision of the end result; everyone has their own idea. The project’s scope and budget expand wildly as tasks are added because they sound like they should be part of the effort. The inevitable budget cutting is equally senseless. The thousands of decisions that people make during a project are not channeled toward a clear, measured result. The project manager doesn’t find out about this desired strategic result until the project is almost finished and the stakeholders are unhappy.
It’s no surprise that most bad projects -- particularly the ones that organizations repeat every few years -- are flawed because the front end planning is weak or was never attempted. It’s up to the project manager to get the real definition of success before the project starts.
The PM must ask tough questions of the project sponsor and stakeholders: How will you measure success at the end of this project? What do you really want to buy for all this money we’re going to spend? Getting answers to these questions forces the kind of conceptual thinking required at the front end of a project. Without an understanding of the desired result, the PM cannot fend off scope enlargement and define success for the people who will be doing the work. With answers to her strategic questions, the PM can drive the project toward the agreed upon measures of success.
A Different Kind of Thinking
Defining project success before you start requires conceptual thinking. We need to conceive a project as a linked chain of measured achievements. We create this chain by starting at the end of the project -- yes, the end. The last achievement is the sponsor’s definition of success. This success definition needs to be measurable and preferably quantifiable.
"Provide the best possible customer service," is neither. Sure it sounds good and no one will disagree, but it’s mush. We can’t measure whether or not we have achieved this.
"Answer 95% of our customer’s calls within 120 seconds," is measurable and quantifiable. People will argue about whether this is what they want and that’s the point; we want to define good customer service before we start the project.
After a sponsor "buys off" on this second definition of success, we will not have to argue about whether or not we succeeded. Let’s go back and look at how a PM would develop this measure of success using this customer service example. As the PM, you’re assigned a project which the sponsor describes as consisting of a new information system, training and installation for a customer service division that answers telephone inquiries. Immediately, you find yourself deluged with the technical details of hardware, programming and training that the new customer service system requires. As challenging and important as these are, they are only activities.
The success definition is not to install hardware and software. The success definition must be a strategic result. The sponsor wants to talk about activities. As project manager, you need to force a discussion of what the end result will look like in terms you and the sponsor can measure. After long discussions, you may finally unearth that the sponsor’s real desire is to reduce the number of times that a customer problem is not solved on the first call.
Now we’re getting someplace. You and the sponsor work out the measurement process and come up with a tight success measure like the one we had above; resolve 95% of all customer problems during the first call (i.e., no call backs or second calls about the same problem). Of course, finding out how stakeholders will measure a project’s success at the end is not an easy task. The measurement is never just a budget and due date. Often the project’s sponsor doesn’t know how he will measure success and the PM and sponsor are both easily snared in the same activity trap. Focusing on activities, the PM would not discover what the sponsor really wants to "buy" until the project is complete, and stakeholders and sponsors express their disappointment.
The Reluctant Sponsor: Where The Politics Come In
For all the above reasons, the seasoned PM realizes that it’s foolish to start a project until the sponsor has defined success in measurable terms. Some sponsors resist providing this definition of success. Doing so requires that they commit to exactly what they want. This is politically risky for them. Getting a clear definition of success also requires that you reconcile the conflicting desires of various stakeholders in the project.
While this process is difficult, it’s far easier to handle these stakeholder conflicts before you start than to have them plague you and your project team for the entire duration of the project. In sum, completing the front end planning of a project is no easy task. It usually involves pressing people who outrank you to make difficult conceptual decisions. It requires that you engage in "blue sky" thinking and that you resolve the conflicts between project sponsors. But the benefits are substantial. You can control project scope by asking the question, "How does this new task you want to add help us reach our measure of success?" You can give your project team crystal clear expectations about what they have to achieve. Finally, you do not have to argue about what people really want during the project or, even worse, at the end.
The Activity Trap
Instead of thinking strategically to define the measurable results the project should achieve, the PM and her sponsor usually focus on the bells and whistles of the project’s tasks. This is the activity trap, and it is an evil thing. When a PM dives head first into the gunk of the activity trap, the project planning takes the form of horse-trading. "Okay, if you can add your favorite task, then I get to add mine!" Most importantly, no one has agreed on what the project will achieve. After the project starts, tasks can change at the drop of a hat because there is no clear vision of the end result; everyone has their own idea. The project’s scope and budget expand wildly as tasks are added because they sound like they should be part of the effort. The inevitable budget cutting is equally senseless. The thousands of decisions that people make during a project are not channeled toward a clear, measured result. The project manager doesn’t find out about this desired strategic result until the project is almost finished and the stakeholders are unhappy.
It’s no surprise that most bad projects -- particularly the ones that organizations repeat every few years -- are flawed because the front end planning is weak or was never attempted. It’s up to the project manager to get the real definition of success before the project starts.
The PM must ask tough questions of the project sponsor and stakeholders: How will you measure success at the end of this project? What do you really want to buy for all this money we’re going to spend? Getting answers to these questions forces the kind of conceptual thinking required at the front end of a project. Without an understanding of the desired result, the PM cannot fend off scope enlargement and define success for the people who will be doing the work. With answers to her strategic questions, the PM can drive the project toward the agreed upon measures of success.
A Different Kind of Thinking
Defining project success before you start requires conceptual thinking. We need to conceive a project as a linked chain of measured achievements. We create this chain by starting at the end of the project -- yes, the end. The last achievement is the sponsor’s definition of success. This success definition needs to be measurable and preferably quantifiable.
"Provide the best possible customer service," is neither. Sure it sounds good and no one will disagree, but it’s mush. We can’t measure whether or not we have achieved this.
"Answer 95% of our customer’s calls within 120 seconds," is measurable and quantifiable. People will argue about whether this is what they want and that’s the point; we want to define good customer service before we start the project.
After a sponsor "buys off" on this second definition of success, we will not have to argue about whether or not we succeeded. Let’s go back and look at how a PM would develop this measure of success using this customer service example. As the PM, you’re assigned a project which the sponsor describes as consisting of a new information system, training and installation for a customer service division that answers telephone inquiries. Immediately, you find yourself deluged with the technical details of hardware, programming and training that the new customer service system requires. As challenging and important as these are, they are only activities.
The success definition is not to install hardware and software. The success definition must be a strategic result. The sponsor wants to talk about activities. As project manager, you need to force a discussion of what the end result will look like in terms you and the sponsor can measure. After long discussions, you may finally unearth that the sponsor’s real desire is to reduce the number of times that a customer problem is not solved on the first call.
Now we’re getting someplace. You and the sponsor work out the measurement process and come up with a tight success measure like the one we had above; resolve 95% of all customer problems during the first call (i.e., no call backs or second calls about the same problem). Of course, finding out how stakeholders will measure a project’s success at the end is not an easy task. The measurement is never just a budget and due date. Often the project’s sponsor doesn’t know how he will measure success and the PM and sponsor are both easily snared in the same activity trap. Focusing on activities, the PM would not discover what the sponsor really wants to "buy" until the project is complete, and stakeholders and sponsors express their disappointment.
The Reluctant Sponsor: Where The Politics Come In
For all the above reasons, the seasoned PM realizes that it’s foolish to start a project until the sponsor has defined success in measurable terms. Some sponsors resist providing this definition of success. Doing so requires that they commit to exactly what they want. This is politically risky for them. Getting a clear definition of success also requires that you reconcile the conflicting desires of various stakeholders in the project.
While this process is difficult, it’s far easier to handle these stakeholder conflicts before you start than to have them plague you and your project team for the entire duration of the project. In sum, completing the front end planning of a project is no easy task. It usually involves pressing people who outrank you to make difficult conceptual decisions. It requires that you engage in "blue sky" thinking and that you resolve the conflicts between project sponsors. But the benefits are substantial. You can control project scope by asking the question, "How does this new task you want to add help us reach our measure of success?" You can give your project team crystal clear expectations about what they have to achieve. Finally, you do not have to argue about what people really want during the project or, even worse, at the end.