Page 25 -

A project that starts out like this is likely to experience scope creep, delays, and even out-
right failure. What’s worse, nobody in the organization will really even understand why
the project had so many problems. All they will see is a team that built software that didn’t
work properly and had to be repaired or even rewritten. This is a very bad situation for a
software engineering team to end up in. Even when a team is technically proficient and
capable of delivering high-quality, well-written software, when faced with a problematic
project, most managers will intuitively feel that the team is incapable of delivering soft-
ware without major quality problems.
What usually stalls a project is a lack of good project management. To prevent problems, the
project manager must identify the people who are making decisions that affect the project
and understand why they need the software built. By talking to them and writing down their
needs, the project manager can set the project on its proper course—and give the stakehold-
ers the feeling from the very beginning that the team is taking their needs seriously.

Drive the Scope of the Project
When the project begins, the project manager has a unique role to play. The start of the
project is the time when the scope of the project is defined; only the project manager is
equipped to make sure that it’s defined properly. Everyone else has a role to play later on:
users and stakeholders will provide expertise, requirements analysts will write specifica-
tions, programmers will build the code, etc. Everyone involved in the project has some
input into the scope, but only the project manager is solely dedicated to it.
Defining the scope is the most productive thing a project manager can do to get the project
underway. It is usually counterproductive to do any other project activity before every-
body agrees on the scope, because that activity could fall outside of the scope without any-
one realizing it. For example, many programmers will immediately begin coding proof-of-
concept prototypes before even talking to the users or stakeholders; many stakeholders
will encourage this because they intuitively feel that they cannot make decisions without
seeing something in front of them. But building a working model is a very time-consum-
ing way to figure out that a feature is not needed. If time is a concern, this is definitely not
an efficient way to build software.

By focusing on discussing the scope and writing a vision and scope document, the project
manager can ensure that the team starts out moving in the right direction. This should not
be hard—when the project begins, everyone is highly suggestible. Nobody is really in her
area of expertise yet: the code is not ready to be built, requirements are not known well
enough to be gathered, and designs and test plans cannot even be approached yet.

Instead, there is a great deal of knowledge floating around in peoples’ heads. To make sure
that knowledge is captured, there must be a single person responsible for gathering it. This
is the main role for the project manager at the start of the project. Once he starts talking to
individual people about what they expect to see in the project and writing down their
thoughts, the scope will start to coalesce and people will start feeling comfortable with the
direction in which it is going. This can happen very quickly once the project manager
starts asking questions and writing down the answers.

SOFTWARE PROJECT PLANNING 17