Defining Your Project 49gives some information on when the project should be completed
and how much it will cost. There are also several charts that out-
line performance capabilities for the new line.
As Brad continues perusing the project requirements, he
begins to feel more and more troubled. Something’s missing,
Brad thinks to himself. It finally hits him and he begins mutter-
ing, “What’s the problem here? I don’t understand. I see that
they want me to put in a new production line and do some other
stuff. That seems clear enough. But whyam I putting in the
production line?
“Oh, great,” he groans. “A project manager for less than 20
minutes and I’m already encountering a crisis!”
How Projects Should Evolve
Brad should not feel badly about being confused. He’s troubled
because he’s fallen victim to a problem that’s common in many
matrix organizations. Someone from another department has
defined the solution to a problem, then “thrown it over the wall”
to Brad. Brad doesn’t know what the original problem is and
whether the project he’s been given is the best way to solve it.
Among other things, he feels that he’d like to know whether a
valid process was used to define the project.
And that’s OK. As a matter of fact, that’s something you
should do on your projects. So let’s help Brad by describing
how projects shouldevolve, so he can better understand the sit-
uation he’s in and ask the right questions.
Projects typically begin when we recognize that a need
exists. From this point on, however, we can often become our
own worst enemies—and can lose control very rapidly—if we
don’t follow a disciplined approach. Why? Because we’re
human. When any of us spots a problem, our natural tendency
is to want to solve it right away—often with the first solution
that pops into our heads.That’s just human nature. On the sur-
face, this approach may seem admirable, because it seems to
resolve problems swiftly and decisively. Unfortunately, it’s coun-
terproductive to good project management. A solid approach