One of the common cause of project failures is the project sponsor demands that the
project sponsor demands that the project manager finish the job by a certain time,
within budget, and at a given magnitude or scope, while achieving specific
performance levels. In the words, the sponsor dictates all four of the project
constraints. This doesn´ t work.
The relationship between 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.

Figure 1-1. triangles showing the relationship between P,C,T, and S

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 stroke
or heart attack, and the paramedic will have to revive her.
Invariably, the sponsor will exclaim, " how can it cost that much?" She has a figure in
a mind, and your number will always exceed her figure. 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 you 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 the project should be done. If you allow yourself to be
intimidated into committing to a lower number, you will face a disaster later on, and
you are far better off taking your lumps now than being hung 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 variable at the scope level, then the
project can be done. Otherwise, it is prudent to forget this project and do something
else that can make a profit 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
accidentally go right. In terms of cost estimates, this means that the budget will come
in bellow budget. Just another way of stating Murphy´ s law, that " whatever can go
wrong will go wrong."

There are many different models for the phases a project goes trough during its life
cycle. One model captures the all-too-frequent nature of a projects that are not
managed well; this 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
I can take comfort that we Americans are not the only ones who face problem, but
the bad news is that there must be a lot of dysfunctional projects if everyone
recognizes the model. The appropriate life cycle model is shown in figure 1-3. Notice
that every project begins as a concept and that the project team must formalize the
definition of the job before doing any work. However, with our ready-fire-aim
mentality, we often start working on the job without ensuring that we have a proper
definition or that everyone shares the mission an vision for the job.

Figure 1-2. Life cycle of a troubled project

Some years ago, a project manager in one in one of my client companies called me
and said, " I´ ve just had a conference call with key numbers 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 whit
that!" Three hours later we finally finished writing a problem statement.

The project manager was right. They did not agree on what the problem was, much
less haw to solve it. This is fundamental-and is so often true that I begin to think we
all have a defective gene that problem before we start de work. Remember, project
management is solving a problem on a large scale, and the way you define a problem
determines how come up whit 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 its head was chopped
off 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. An example of strategy
was related to me by a friend who is into military history.The actual steps to manage
a project are straightforward. Accomplishing them may not be. The model in figure 1-
4 illustrates the steps. Subsequent chapters of this book elaborate on how each step
is accomplished. For now here is a brief description of the actions involved.