Page 236 -

Measuring quality
One straightforward way to measure the quality of the software is to measure the total time
and effort required to test the software. This metric covers all of the effort expended, from
the time that the programmers deliver an alpha build that they consider complete to the
time that the test activities yield results that the senior managers agree are acceptable for
release (see Chapter 8 about the release readiness process). This measurement should
include not only the testing activities, but also any work programmers do to fix defects that
are found. If the testing team finds requirements or scope defects, this number should also
take into account time and effort spent on activities performed by the project manager,
requirements analysts, stakeholders, users, and anyone else involved in fixing that defect.
Any tools and techniques that you put in place in order to improve the way software is
built should reduce the time and effort required to test the software. To use this measure-
ment, use the schedule to figure out both the calendar time and the effort required to test
the software as a percentage of the total calendar time or effort required for the entire
project. You can then compare these numbers to other projects of similar complexity. If
these numbers decrease over the course of several projects, your improvements are work-
ing. In many cases, the change will also lead to fewer delivered defects (but it can take a
while to observe that effect).
It is important to select projects for comparison that match the current one in complexity.
This means that the comparison projects should use similar technology, require similar
expertise from the team, and preferably use many of the same team members. This works
especially well when comparing maintenance releases of a single software project.

Bring In an Expert
Sometimes the best way to make sure that your changes are implemented effectively is to
bring in an expert. There are many consultants who will assist in improvement efforts and
train your organization to implement the tools introduced in this book. Sometimes, cor-
roborating your improvement initiatives with an expert’s opinions is just what people in
your organization need, to feel reassured that the ideas have merit.

Experts and consultants are especially helpful in training people in a wide range of specific

techniques, including estimation, inspections, code reviews, unit testing, and project plan-
ning practices. They can also be pivotal in helping to establish metrics, testing, or require-
ments efforts. What’s more, there are many pitfalls that inexperienced project managers
and organizations can fall into: experts can identify these pitfalls and help you avoid them.
In this way, bringing in a consultant or expert can more than pay for itself.

Perhaps most importantly, experts’ training sessions are morale boosters—there is little
that can get a team more excited about a new technique than training them all at the
same time on it. Everyone feels like they have a common understanding, and the culture
changes to accept that idea much more quickly than it would have, had it only been intro-
duced by someone internally.

228 CHAPTER NINE