Define the Problem
As was discussed previously, you need to identify the problem to
be solved by the project. It helps to visualize the desired end result.
What will be different? What will you see, hear, taste, touch,
or smell? (Use sensory evidence if things can’t be quantified.)
What client need is being satisfied by the project?

Develop Solution Options
How many different ways might you go about solving the problem?
Brainstorm solution alternatives (you can do this alone or
as a group). Of the available alternatives, which do you think will
best solve the problem? Is it more or less costly than other suitable
choices? Will it result in a complete or only a partial fix?

Plan the Project
Planning is answering questions: what must be done, by whom,
for how much, how, when, and so on. Naturally, answering these
questions often requires a crystal ball.

Execute the Plan
Obvious. Once the plan is drafted, it must be implemented. Interestingly,
we sometimes find people going to great effort to put
together a plan, then failing to follow it. If a plan is not followed,
there is not much point in planning, is there?

Monitor and Control Progress
Plans are developed so that you can achieve your end result successfully.
Unless progress is monitored, you cannot be sure you
will succeed. It would be like having a roadmap to a destination
but not monitoring the highway signs along the way.
Of course, if a deviation from the plan is discovered, you
must ask what must be done to get back on track, or—if that
seems impossible—how the plan should be modified to reflect
new realities.

Close the Project
Once the destination has been reached, the project is finished,
but there is a final step that should be taken. Some people call it
an audit, others a postmortem (sounds a bit morbid, doesn’t it?).
Whatever you call it, the point is to learn something from what
you just did. Note the way the questions are phrased: What was
done well? What should be improved? What else did we learn?
We can always improve on what we have done. However, asking
“What did we do wrong?” is likely to make people a bit defensive,
so the focus should be on improvement, not on placing
blame.

When all the work has been completed, the closeout phase requires
that a review of the project be conducted. The purpose is
to learn lessons from this job that can be applied to future ones.
Two questions are asked: “What did we do well?” and “What do
we want to improve next time?”
Notice that we don’t ask what was done wrong. This question
tends to make people defensive, and they try to hide things
that may result in their being punished. In fact, a lessons-learned
review should never be conducted in a blame-and-punishment
mode. If you are trying to conduct an inquisition, that’s different.
The purpose of an inquisition is usually to find who is responsible
for major disasters and punish them. Lessons-learned sessions
should be exactly what the words imply.
I have learned during the past few years that very few organizations
do regular lessons-learned reviews of their projects. There is
a reluctance to “open a can of worms.” And there is a desire to get
on with the next job. The problem is that you are almost sure to repeat
the mistakes made on the previous project if no one knows
about them or has an understanding of how they happened so that
they can determine how to prevent them. But, perhaps most important,
you can’t even take advantage of the good things you did
if you don’t know about them.
It has been said that the organizations that survive and thrive
in the future will be those that learn faster than their competitors.
This seems especially true for projects.

Once the plan has been developed and approved, the team can begin work. 
This is the execution phase, but it also includes control, because, while 
the plan is being implemented, progress is monitored to ensure that the 
work is progressing according to the plan. When deviations from the plan 
occur, corrective action is taken to get the project back on track, or, 
if this is not possible, the plan is changed and approved, and the revised 
plan becomes the new baseline against which progress is tracked.

This phase includes tactics and logistics. If you are going to build
boats upside down, you must work out the details of how it will
be done. A fixture must be constructed that will hold the boat
and allow it to be turned over without being damaged. This is
called “working out the tactics.” It also includes the sequence in
which the work will be done, who will do what, and how long
each step will take.
Logistics deal with making sure the team has the materials
and other supplies needed to do their jobs. Ordinarily we think
about providing teams with the raw materials they need, but if
the project is in a location where they can’t get food, work will
soon come to a grinding halt. So provisions must be made for the
team to be fed—and possibly housed.

In history, defense contractors were under great pressure
to build weaponry at an intense level. To accelerate construction
of ships and planes in particular, many new assembly
methods were invented. Avondale shipyards, for example, worked
on the method of building ships. The traditional way had always
been to build the ship in an upright position. However, ships built
from steel required welding in the bottom, or keel area of the
boat, and this was very difficult to do. Avondale decided to build
its ships upside down, to make the welding easier, and then turn
them over to complete the structures above the top deck. This
strategy was so effective that Avondale could build boats faster,
cheaper, and of higher quality than their competitors, and the
strategy is still being used today, nearly seventy years later.

Some years ago, a project manager in one of my client companies
called me and said, “I’ve just had a conference call with key
members of my project team, and I realized that we don’t agree
on what the project is supposed to accomplish.”
I assured him that this was common.
“What should I do?” he asked.
I told him that he had no choice but to get the team members

all going in the same direction by clarifying the mission of the project.
He asked me to facilitate a meeting to do this.
At the meeting, I stood in front of a flip chart and began by
saying, “Let’s write a problem statement.” Someone immediately
countered by saying, “We don’t need to do that. We all know
what the problem is.”
I was unmoved by this comment. I said, “Well, if that is true,
it’s just a formality and will only take a few minutes, and it would
help me if we wrote it down, so someone help me get started.”
I’m going to be a little facetious to illustrate what happened
next. Someone said, “The,” and I wrote the word on the chart,
and someone else said, “I don’t agree with that!”
Three hours later, we finally finished writing a problem
statement.
The project manager was right. The team did not agree on
what the problem was, much less how to solve it. This is fundamental—
and is so often true that I begin to think we have a defective
gene in all of us that prohibits us from insisting that we
have a good definition of the problem before we start the work.
Remember, project management is solving a problem on a large
scale, and the way you define a problem determines how you
will solve it. If you have the wrong definition, you may come up
with the right solution—to the wrong problem!

In fact, I have become convinced that projects seldom fail at
the end. Rather, they fail at the definition stage. I call these projects
headless-chicken projects because they are like the chicken
that has had its head chopped off and runs around spewing blood
everywhere before it finally falls over and is “officially” dead. Projects
work the same way. They spew blood all over the place, until
someone finally says, “I think that project is dead,” and indeed it
is. But it was actually dead when we chopped off its head in the
beginning—it just took a while for everyone to realize it.
Once the project is defined, you can plan how to do the work.
There are three components to the plan: strategy, tactics, and logistics.
Strategy is the overall approach or “game plan” that will be
followed to do the work.

There are many different models for the
phases a project goes through during its
life cycle. One of these captures the alltoo-
frequent nature of projects that are not managed well and is
shown in Figure 1-2.
I have shown this diagram to people all over the world, and
they invariably laugh and say, “Yes, that’s the way it works.”
I suppose the comfort I can take is that we Americans are not the
only ones who have the problem, but the bad news is that there
are a lot of dysfunctional projects if everyone recognizes the model.
At the simplest level, a project has a beginning, middle, and
end. I prefer the life-cycle model shown in Figure 1-3, but there are
other versions that are equally valid. In my model, you will notice
that every project begins as a concept, which is always “fuzzy,” and
that the project team must formalize the definition of the job before
doing any work. However, because of our ready-fire-aim mentality,
we often start working on the job without ensuring that we have a
proper definition or that the mission and vision for the job are
shared by everyone. This invariably leads to major problems as the
project progresses.

One of the common causes of project failures is that the project
sponsor demands that the project manager must finish the job by
a certain time, within budget, and at a given magnitude or scope,
while achieving specific performance levels. In other words, the
sponsor dictates all four of the project constraints. This doesn’t
work.
The relationship among the PCTS constraints can be written
as follows:
C = f(P, T, S)
In words, this says, “Cost is a function of Performance, Time, and
Scope.” Graphically, I like to show it as a triangle, in which P, C,
and T are the sides and S is the area. This is shown in Figure 1-1.
In geometry, we know that if we are given values for the
sides of a triangle, we can compute the area. Or, if we know the
area and the length of two sides, we can compute the length of
the remaining side. This translates into a very practical rule of
project management: The sponsor can assign values to any three
variables, but the project manager must determine the remaining
one.
So let’s assume that the sponsor requires certain performance,
time, and scope from the project. It is the project manager’s job to
determine what it will cost to achieve those results. However, I
always caution project managers that they should have a paramedic
standing by when they give the cost figure to the sponsor
because she will probably have a stroke or heart attack, and the
paramedic will have to revive her.
Invariably, the sponsor exclaims, “How can it cost that
much?” She had a figure in mind, and your number will always
exceed her figure. And she may say, “If it’s going to cost that
much, we can’t justify doing the job.” Exactly! And that is the decision
she should make. But she is certain to try to get the project
manager to commit to a lower number, and, if you do, then you
only set up yourself—and her—to take a big fall later on.
It is your obligation to give the sponsor a valid cost so that she
can make a valid decision about whether or not the project should
be done. If you allow yourself to be intimidated into committing to
a lower number, it is just going to be a disaster later on, and you are
far better off taking your lumps now than being hanged later on.
Of course, there is another possibility. If she says she can afford
only so much for the job, then you can offer to reduce the scope.
If the job is viable at that scope level, then the project can be done.
Otherwise, it is prudent to forget this project and do something
else that can make profits for the company. As someone has said,
there is a higher probability that things will accidentally go wrong
in a project than that they will accidently go right. In terms of cost
estimates, this means that there is always
a higher likelihood that the budget will
be overrun than that the project will
come in below budget. This is just another
way of stating Murphy’s law, that
“whatever can go wrong will go wrong.”

It is common to have individuals serve as project managers and
require also that they do part of the actual work in the project.
This is a certain prescription for problems. If it is a true team, consisting
of several people, the project manager inevitably finds herself
torn between managing and getting her part of the work done.
Naturally, the work must take precedence, or the schedule will
slip, so she opts to do the work. That means that the managing
does not get done. She hopes it will take care of itself, but it never
does. After all, if the team could manage itself, there would be no
need for a project manager in the first place (remember our argument
about whether project management matters?).
Unfortunately, when the time comes for her performance
evaluation, she will be told that her managing needs improving.
Actually, she just needs to be allowed to practice management in
the first place.
Yes, for very small teams—perhaps up to three or four people—
a project manager can do some of the work. But, as team sizes increase,
it becomes impossible to work and manage both, because
you are constantly being pulled away from the work by the needs
of your team members.
One of the reasons for this situation is that organizations don’t
fully understand what project management is all about, and they
think that it is possible for individuals to do both. The result is that
nearly everyone in the company is trying to manage projects, and,
as is true in every discipline, some of them will be good at it and
others will have no aptitude whatsoever. I have found that a far
better approach is to select a few individuals who have the aptitude
and desire to be project managers and let them manage a
number of small projects. This frees “technical” people (to use the
term broadly) to do technical work without having to worry about
administrative issues and allows project managers to get really
good at their jobs.

When is managing a project not project management? When only one person is involved.
A lot of people are sent to my seminars to learn how to manage projects, but they are the only person working on their projects.
Now it is true that a one-person job can be called a project, because it has a definite starting point, target, end date, specific performance
requirements, defined scope of work, and a budget. However, when no one else is working on the project (including outside
vendors), there is no need for a critical path schedule. A critical path schedule is one that has a number of parallel paths, and one of
them is longer than the others and determines how long it will take to complete the job or, ultimately, whether the given end date can
be met. When you’re working on a job by yourself, there aren’t any parallel paths—unless you are ambidextrous!
One-person projects do require good self-management, or good time management, but all you need is a good to-do list,
which comes from a task listing. However, unless you are coordinating the work of other people, you aren’t practicing true project
management.