Page 132 -

while a full estimation may be necessary for large changes, there are many small changes
that do not require the project manager to gather an estimation team and hold a meeting.
For example, a change that amounts to a small bug fix may simply require that the project
manager talk to the programmer responsible for that code and ask how long it will take to
fix it.

There is some overlap here between the responsibility of the project manager and that of
the QA team. Some QA engineers may question the need for the project manager to be so
involved in updating specific issue reports in the defect tracking system—this is generally a
task that is exclusively controlled by QA. This is true both when the issue is a defect and
when it is a change; in both cases, the impact must be evaluated, to determine whether
the change should be implemented or whether the defect should be fixed.
The reason the project manager is responsible for this is because he serves as a conduit for
all of the information relevant to the change. By updating the issue report, he ensures that
he has gathered all the information relevant to the change, and that all of the information
is in one place. The issue report is still owned by QA, but it makes sense to have the
project manager directly update it rather than having to sit down with the QA team each
time a change is evaluated. As long as a member of the QA team on the CCB initiates each
change, they will still be kept in the loop.

Introduce Software Requirements Carefully

There are plenty of books that tell us that poor requirements are the most common cause
of software quality problems. Yet many project managers have had difficulty bootstrap-
ping efforts within their own teams to implement better software requirements practices.
Software requirements should make intuitive sense: before a team can build software,
they need to know what to build. In practice, however, many project managers have
found that it is difficult to convince their teams to adopt good software requirements engi-
neering practices. This is especially true for certain kinds of projects:
• Small projects in which the programmer is confident that he understands all of the
requirements already

• Projects in which “everybody” knows what the software is supposed to do
• Projects without a user interface (like batch processes or back-end calculation software)
• Any project considered “technical”— one in which one or more of the stakeholders is a
programmer
In all these projects, there is an expectation that a programmer can make all of the deci-
sions about the behavior of the software. It seems intuitive (but incorrect) that since the
programmer can already decide on the details of the implementation, he should also have
a grasp on what is being implemented. The programmer is often the most confident per-
son in the organization about his own ability to do this, which the rest of the team and the
stakeholders always find reassuring.

124 CHAPTER SIX