"Tools that are transperent to environment and support the process." - Dale Hubbard 

Successful Project

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.
Successful Project

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 client's process.

Successful Project

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.

  copyright of Software Process Multimedia, Inc