A development organization, which employs several-hundred
software engineers, was looking for a comprehensive
database to store results of their technical reviews.
Several proposals were considered in the multi-million
dollar range. A special working group has been mandated
to collect and distill database requirements and
then develop the initial specification document.
After six months of hard work, the working group
fell apart, due to staff turnover and lack of senior
management interest. At this point we picked up
the initiative and introduced a solution at virtually
no cost. Our solution did not conflict with the
idea of a flexible, enterprise-wide, multi-site,
multi-department database. Rather, it served as
an initial step in the right direction. Several
years have passed. Software engineers continue to
use our tool to store and analyze the results of
their technical reviews.
A software company with a strong marketing drive
was unable to bridge a gap between the constant
flow of clients' requests "I want it yesterday"
and the rigor of the development process (no steps
could be skipped). Engineering priorities were changing
with every management session dominated by marketing
executives. Apparently, the situation required a
mechanism to make well justifiable decisions regarding
features that should be included into release versus
features that should be deferred. We introduced
such a mechanism during a one-hour workshop between
all affected parties. For the past two years our
tool has been used extensively. We were glad to
enhance our tool to follow the precise steps of
A fast growing Internet company had twenty-five
distinct software groups. Most of these groups
contributed to the same customer product releases.
However, inter-group coordination always represented
a challenge, because of remote locations and cultural
differences. The defect database in this company
was based on the well-known IEEE industry standard
and without any regard for organizational specifics.
Most of the fields were redundant. Six months
after the database was introduced, a senior manager
decided to find out whether the database was used
consistently. He discovered that collection and
analysis of metrics was hindered by the inconsistent
usage of the database.
At this point, SPM introduced a one-hour workshop
covering the process of reviewing software defects.
This process should have been introduced prior
(or at least concurrently) with the database introduction.
SPM participated in each group's staff meeting
by presenting the workshop. However, it was too
late to switch to some unified usage model, mainly
due to the thousands of existing defects already
stored in the database, which did not comply with
any predefined model. Even after a year of collecting
and publishing metrics, a number of groups were
still using their own, homegrown procedures.
In general, when introducing a tool and a process,
the tool should support the process. This example
describes some common problem when the tool (defect
database) is introduced first. SPM can support
client companies in all phases of tool and process