« Affinity Diagram - Kawakita Jiro or KJ Method
Kano and Quality Requirements »

Measure, Graph and Track Output - An Objective Method For Navigating Your Project Successfully

August 8, 2008 | Author: PM Hut | Filed under: Project Management Best Practices, Quality Management, Techniques

Measure, Graph and Track Output - An Objective Method For Navigating Your Project Successfully (#1 in the series An Objective Method For Navigating Your Project Successfully)
By Bill Miller

“Another 30 defects uncovered yesterday,” reports the QA Lead. “Ten defects were fixed,” reports the Tech. Lead. Taken alone these are alarming statistics, and if they persist long enough, the release date would certainly be in jeopardy.

Many software teams struggle through the QA phase with great anxiety as they normally work through the phase without a compass: nothing to tell them whether they are on track or not. How many defects are left? Will we be able to fix all the defects before the release date? Will we find all the defects before the release date? These are a few of the questions that teams have anxiety about. It’s only until a few weeks before the planned release date that they come to grips with the realization that they are in trouble.

Measure, Graph and Track Output

Over the years, I’ve developed some tracking techniques that have helped me to control the QA phase of the software development life cycle. I like to record, track, and graph some key statistics that I use to measure how well the project is progressing to schedule. The data points are recorded and graphed daily in an Excel spreadsheet and maintained weekly on a historical basis. Basically, I record the current week’s data daily in the same cell until the end of the week when the last value persists and begin the process in a new cell for the next week.

Based on the behavior of the trends, I make objective decisions for reporting status in the weekly status report. Red means our fix rate is trending to deliver the project beyond the scheduled release date unless something is done to correct it. Yellow means that our fix rate is trending off schedule, and if current trends persist, the project will deliver late. Green, of course, means that the project is delivering on schedule. I’ll detail the specific criteria for determining status later in this series.

There are 7 variables that I track during the project:

  1. Actual defects found as a line plot.
  2. Weekly defects found as a bar graph plot.
  3. Actual defects left-to-fix as a line plot.
  4. Weekly defects fixed as a bar graph plot.
  5. Expected defects to find as a straight line.
  6. Expected defects left-to-fix as a straight line.
  7. Backlog of open defects as a line plot.

To make this all work, during the estimation phase, I estimate the total number of defects to be found and fixed before the product is released. Figure A is an example of a typical graph with all the data points recorded. The features of the graph as described above are labeled with their corresponding numbers.

Project Defect Metrics

Figure A. Labeled Defect Tracking Graph

Notice the 2 straight lines that cross each other. The line starting from zero and increasing over time is the plot of the expected defects to find trend and the line starting from approximately 2000 and decreasing over time until it reaches zero is the expected defects left-to-fix trend. The reasoning behind the behavior of the lines is that when you start the project all the defects are left-to-fix and when the project completes, there are zero defects left-to-fix. Likewise, when the project starts, none of the defects have been found, and when the project completes, all the defects have been found.

The purpose of these two lines, what I call idealized lines, is to compare and to contrast them with the corresponding actual lines for found and left-to-fix over time. The behavior of the actual line data plots in comparison to the idealized lines gives you a measure of how well your project is progressing to schedule, and it quantifies the degree that the project is either ahead or behind schedule visually and measurably.

Bill Miller has 23 years experience developing and managing software projects, most of which are in financial information and network management domains. He has managed teams as large as 60 professionals, and he’s been responsible for developing and rolling out software process in multiple organizations that have been rated at CMMI Level 3. He is the author of the popular blog yuwantitwhen.com, dedicated to promoting practical methods for successful software project management. He may be reached at bill(at)yuwantitwhen(doc)com, or please visit his site at http://yuwantitwhen.com.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Friday, August 8th, 2008 and is filed under Project Management Best Practices, Quality Management, Techniques. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories