Page 39 -

eventually delivered, it seemed to take much more effort than was necessary, and the
team is relieved to be rid of it.

The Mid-Course Correction
A change in the project priorities partway through the project is one of the most frustrat-
ing ways that a software project can break down. After the software design and architec-
ture is finalized, the code is under development, the testers have begun their preparation,
and the rest of the organization is gearing up to use and support the software, a stake-
holder “discovers” that an important feature is not being developed. This, in turn, wreaks
havoc on the project schedules, causing the team to miss important deadlines as they fran-
tically try to go back and hammer the new feature in.
This discovery often comes about very late in the project, when a preliminary build of the
software is delivered to the stakeholder. Often a team member had already brought the
problem to the stakeholder’s attention early on in the project. But it was not detected at
the time because the stakeholder may not have fully recognized the nature of problem, or
he might not have been comfortable bringing the problem up because it would have
involved criticizing a design that represented a lot of effort. Either way, the team is now
demoralized because it knows it would have been much easier to build the right software
in the first place instead of having to change halfway through the project.
Good project planning helps avoid this problem. A vision and scope document describes
the features to be developed using straightforward language, and each of the features
clearly fulfills a need that the project stakeholders recognize. Stakeholders are not techni-
cal people; they might not be fully comfortable reading technical documents, but they are
usually very good about talking about their needs and can generally recognize when those
needs are taken into account. A project plan developed with the team’s buy-in and based
on the vision and scope document keeps the project on track and allows everyone to spot
problems early on and fix them.

Many design or programming problems can be traced back to an engineer who does not
fully understand the needs that are being fulfilled. This is usually not the engineer’s
fault—perhaps the need itself was never brought up. Having stakeholders review and cor-

rect the vision and scope document before the software is designed helps the team recog-
nize those missing needs early on in the project.
The Detached Engineering Team
In many organizations, there is an artificial wall between the people who need the soft-
ware and the people who build it. The engineering team often sees itself as a separate unit.
The priorities of the people in the organization who need the software don’t really figure
into the way the engineers plan and carry out their work. This seems justified because it
will take the team a certain amount of time to do their work, and no amount of bargaining
with the business side will change that.

SOFTWARE PROJECT PLANNING 31