Log In to My ASQ Members Log In   View Shopping Cart Shopping Cart   Quality Progress Magazine Quality Progress Magazine   Make Good Great
Magazines & Journals
Software Quality Professional

Printer Friendly
Issues
I Want To
Article Access Key
  • Public Article
  • Log-In to View
  • Full, Senior, or Fellow members with no subscription.
  • Full, Associate, Forum/Division, Senior or Fellow members who are also subscribers.
  • Enterprise and Site Members have access to all issues.

December 2000
Volume 3 • Number 1

Contents

SOFTWARE PROJECT MANAGEMENT
Managing with Metrics: Theory into Practice

Much has been written about using metrics to manage a software development project. The author has conducted training in the use of software metrics and has provided consulting advice to organizations starting their metrics programs. One of the sad facts of a consultant’s life is that he or she rarely sees the results of the effort put into helping clients. Recently, the author has been providing consulting support to a project for more than two years where he has had the opportunity to observe the results of his advice.This article covers the evolution of the project team’s efforts to use a variety of measures and metrics to provide insight and support decision-making at various levels within the project.

The article begins with a brief description of the project referenced. The theoretical way to implement metrics is discussed briefly, followed by the evolution of the application of metrics on the particular project. A discussion of the success of the project team in using metrics follows, closing with an action plan for readers who want to apply the lessons of this article in their own organizations.

Key words: communications, measurement, process improvement, project tracking, quality measures, risk management

by Denis C. Meredith, Meredith Consulting

INTRODUCTION

The project that is used as an example in this article was a high-volume data capture operation using scanning, optical mark recognition, and optical character recognition with unresolved characters entered by keyers. The captured data were converted to ASCII text and transmitted to a government agency for analysis. Data capture operations were intended to be conducted over a short period of time (less than four months), which meant that things had to be almost completely right the first time–there would be little or no opportunity for maintenance releases. To reduce the risk associated with a single final delivery, the product was developed, delivered, and tested in increments, with each increment considered a release. In reality, there were a number of patches delivered during data capture, including both fixes and enhancements.