Page 24 -

A N URGENT NEED CAN BE A GOOD MOTIVATOR. Software is usually built to address an urgent

need. For the stakeholders—meaning everyone who has a concern or real interest in the
success of the project—the fact that the need is urgent helps to convince the organization
to dedicate time and energy to addressing it. For the software engineers, an urgent need
means that their work will be appreciated and used in the foreseeable future. And for the
management of the organization, it means that there is a clear direction in how they need
to run things.

But urgency can also be the source of a project’s most difficult problems. Urgency causes
people to panic, and to potentially gloss over important parts of the project. People will
rush into gathering requirements (or, even worse, rush into building the code!) without
thoroughly understanding the needs of the people who want the software built.
If a project manager does not really understand the context in which the software is being
built, then the only thing that the project team sees is the urgency; they lose track of the
needs. They can see the individual problems that they are working to solve, but they may
lose track of the big picture.

Unless the team understands the needs that drive the project, they may end up with a nar-
row focus, causing them to waste time addressing problems that are of little importance to
the stakeholders. It’s easy to build great software that solves the wrong problems, but the
only way to build the appropriate software is for everyone in the project to understand
and agree on both why and how that software will be built before the work begins. That’s
the purpose of project planning.

Understand the Project Needs

When a stakeholder does not feel that his needs are being met, he usually puts pressure
on the project manager to provide an early version of the software, so that he can person-
ally verify that the team really understands why the software is being built. This is a big
source of communication failure between the people who need the software and the team
members who are building it. When the stakeholder asks for an early version or a proto-
type of the software, he is usually asking for evidence that his needs are understood and
being addressed. When programmers hear this request, however, they interpret it to mean

that the person is interested in the details of what they are doing, and that he wants to be
given a tour of the solution as it is being developed.
This may sound funny to some seasoned software engineers. Such a basic lack of communi-
cation couldn’t really be that widespread…right? But most software professionals have had
to sit through uncomfortable meetings where a designer or programmer gives a demo or
walkthrough of all of the great work he did, only to be surprised that nobody seems to care.

The reason nontechnical people seem so bored in demos and walkthroughs is because
they came to see confirmation that the technology team understands their needs. Instead,
they got a lecture in software design, which they did not want. This situation can be frus-
trating for everyone involved: the software engineers feel unappreciated and conde-
scended to, while the stakeholders feel like their needs are not being taken seriously.

16 CHAPTER TWO