« Managing the Thing: Change Management
Developing the Project Management Plan »

Making Quality Planning Concrete

September 8, 2007 | Author: PM Hut | Filed under: Quality Management, Techniques

Making Quality Planning Concrete
By Alan Koch, PMP - Global Knowledge Course Director

Most of what you do while planning a project is concrete. For example, there are specific objectives the project must meet, a list of tasks to do, explicit costs to consider, and contractual relationships to maintain.

But Quality Planning is a “soft” concept that it is difficult to think about it in concrete terms. This makes it harder to plan for than budgeting and scheduling. This challenge comes from the difficulty in measuring quality with the same precision as other project variables.

Therefore, if you want to plan for and manage quality with the same focus as you do for budget and schedule, then you must learn to measure it with the same precision. And measuring quality is within your reach.

Quality Measures

There are a variety of objective quality measures that can provide you with insight, depending on the objectives of your project. Naming and measuring things should be the beginning of your ability to understand them and gain control over them. Let’s look at three of the many measures that are available to you.

  • Defect Density (# of defects divided by product size) This is a measure of quality in terms of how many defects a product contains. A 2,000 Function Point system that contains 22 defects has a Defect Density of 11 defects per 1,000 Function Points (11 D/KFP). A system of 25,000 lines of source code that contains a total of 50 defects has a Defect Density of 2 Defects per 1,000 Lines of Code (2 D/KLOC). You can measure the density of defects you detect and correct during any activity in your project, as well as the density you deliver into production.
  • Defect Removal Effectiveness (# of defects removed divided by # of defects that existed at the time) Also called “Yield”, this is a measure of how well your project activities remove defects. If your Peer Reviews of code detected 375 defects, and a total of 325 additional defects were detected in later testing and reviewing and in production, then you can calculate the yield of your Peer Reviews as 375/(375+325) or 54%.
  • Defect Removal Efficiency (# defects removed divided by the number of engineer hours to find and fix them) This is a measure of the cost-effectiveness of your defect removal activities. If your engineers spent a total of 100 hours on the Peer reviews and the resulting bug fixes that removed 375 defects, then the efficiency of your peer reviews were 3.75 Defects per Hour (3.75 D/H).

Quality Planning by the Numbers

How can you use these three metrics to make your Quality Planning more concrete? Suppose that one of your project’s objectives is to improve delivered product quality by at least 25% over the average of prior projects. The following steps would lead you to a good Quality Plan:

  1. Compute the average defect density achieved on those prior projects. If those projects comprised a total of 150,000 lines of source code, and they delivered 750 defects combined, then the average defect density at delivery was 750/150 = 5 D/KLOC. In addition, if they detected a total of 1500 defects during system testing, then you can assume that System testing usually detects a density of 1500/150 = 10 D/KLOC. You can make the same computation for any reviews or other testing that you have data for.
  2. Compute the average defect removal effectiveness for the various testing and reviews that were done on those prior projects. If those projects removed a total of 5000 defects during peer reviews, 1500 defects during System Test, and delivered 750 defects to the customers, then the average effectiveness of those activities were: 5000/(5000+1500+750) = 69% for Peer Reviews, and 1500/(1500+750) =67% for System test.
  3. Compute the average Defect Removal Efficiency of each activity on those prior projects. If those projects spent 1000 hours removing 5000 defects during Peer reviews, then the Peer review efficiency was 5000/1000 = 5 D/H. And if they spent 2000 hours removing 1500 defects during system test, then their testing efficiency was 1500/2000 = 0.75 D/H.
  4. Set goals on the current project for delivered defects as well as defects detected at each phase. The project’s objective is to reduce delivered defects by 25%, so your target is to deliver (1.0-0.25) x 5 = 3.75 D/KLOC. If the estimated size of the product will be 10,000 LOC, then we must deliver no more than 37 defects.

Quality Activities

Of course, achieving the project goal of 25% reduction in delivered defects will require that you make some changes in your quality-related activities. If you do the same things as before, then you are likely to achieve the same results! But what kind of changes should you make? Potential changes fall into four categories that you can mix-and-match to get the results you need.

  1. Add more defect-removal activities to the project. If you have not been including peer reviews, then add some. If you have been reviewing designs but not code, add code reviews. Of course you need to balance the cost of these new activities with the benefit you expect from them. If you don’t have effectiveness and efficiency numbers for these activities from your organization, the best you can do is to base your decision on industry averages.
  2. Replace some defect removal activities with more effective ones (or more efficient ones, which would allow you to do more with the same engineering hours). If prior projects reviewed 20% of the code and had good effectiveness and efficiency numbers for those reviews, then do more reviews this time (maybe 75% or even 100% of the code), stealing the hours from a less effective or efficient activity-like system test.
  3. Improve the efficiency or effectiveness of the activities you do. If your peer reviews are catching only 50% of the existing defects, perhaps some training and a better review process could increase their effectiveness to 60% or 70%.
  4. Inject fewer defects in the first place. This requires doing causal analysis on the defects that were delivered on those prior projects. You may be able to inject fewer defects by adopting a design methodology, establishing coding standards, installing a tool that will help programmers to be more consistent in their engineering work, or many other actions. Exactly what will pay off will depend on the nature of the defects that have historically been delivered.

Measure Quality Now

Many of the quality metrics you need are available in your prior projects’ data. Those that are not available give you clear insight into what metrics you should begin collecting in order to gain a quantitative understanding of Quality.

With a quantitative understanding of quality, you will be able to make clear and actionable Quality Plans for your projects and deliver not just the product that is needed, but the quality levels as well.

This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge delivers comprehensive hands-on project management, business process, and professional skills training. Visit our online Knowledge Center at www.globalknowledge.com/business for free white papers, webinars, and more.

© Copyright 2007, Global Knowledge. All rights reserved.

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

Related Articles

This entry was posted on Saturday, September 8th, 2007 and is filed under 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.

1 person has left a comment

[...] enough,” we must give them ways to think about quality concretely. In the article, “Making Quality Planning Concrete”, we discussed how to use metrics to quantify quality achievements. Using those techniques, we can [...]

PM Hut » Blog Archive » What is “Good Enough”? - Project Quality Management, Part 1: Planning wrote on October 14, 2007 - 11:23 am | Visit Link

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.

The Stevens Enterprise Project Management Master's Program

Project Management Categories