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 introduction.