making quality planning concrete

8/4/2019 Making Quality Planning Concrete

http://slidepdf.com/reader/full/making-quality-planning-concrete 1/3

Making Quality Planning ConcreteBy Alan Koch, PMP, Global Knowledge Course Director

Most of what you do while planning a project is concrete. For example, there are specificobjectives 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 qualityis 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.

y 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 thatcontains 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 aDefect 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 thedensity you deliver into production.

y Defect Removal Effectiveness (# of defects removed divided by # of defects that existedat 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 325additional 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%.y 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 removalactivities. 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 reviewswere 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? Supposethat 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 projectscomprised 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. Inaddition, 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 canmake 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 thatwere 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 thecustomers, 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 removing1500 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,000LOC, 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 youmake 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? Potentialchanges 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 codereviews. 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 theseactivities 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 thosereviews, 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 arecatching 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 willhelp 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 notavailable 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 actionableQuality Plans for your projects and deliver not just the product that is needed, but the qualitylevels as

making quality planning concrete

Documents