Section 7.2. Quality Overview

7.2. Quality Overview

Let's begin with a definition of the word quality. If you look up the word quality in the dictionary, you'll see a number of definitions. However, the one best suited to IT project management is "the degree to which a set of inherent characteristics fulfill requirements." Notice it doesn't say that it's the absolute pinnacle, but the degree to which requirements are fulfilled. Requirements…sounds familiar, doesn't it?

7.2.1. Quality Versus Grade

It's also important to distinguish between quality and grade. Low or poor quality is always a problem, but low grade is not necessarily a problem. Grade is the category assigned to products or results to indicate similar functional, but different technical specifications. For instance, if you're building a house and you want it to be a luxury house from top to bottom, you might specify that the fixtures will be made of 14 karat gold. However, once you develop your budget, you realize those fixtures are busting your budget and you decide to use a lower grade fixture made of burnished brass. Functionally those fixtures may be identical, but their technical specifications are different. The same is true of a software program. It might be very high quality with very few errors or bugs, but if it has very limited functionality, it might be considered a low-grade product. Conversely, we've all worked with products that might be considered high grade but low qualitythey have features galore, but nothing works as well as it should or as advertised. Obviously then, quality and grade are related in the user's mind and it is the job of the IT project manager and project team to develop standards or specifications that deliver the required quality and grade.

7.2.2. Quality Management Components

There are numerous quality management systems used by companies today and everything we'll talk about in this chapter is aligned or consistent with these systems. If your company has implemented Total Quality Management (TQM), Six Sigma, or even ISO standards (to name a few), you can easily incorporate those quality systems into your IT project management process. There are four main components to quality management and these elements are consistent across all systems:

1. User satisfaction

2. Prevention versus correction

3. Continuous improvement

4. Management commitment

7.2.3. User Satisfaction

We've repeatedly mentioned the importance of user satisfaction. There are two components of user satisfaction. The first is one we've discussed, which is that the deliverables from the project meet user requirements. If you've done a good job defining requirements (Chapters 6 and 9), your project should deliver what you and the users agree it should deliver. The second component is that the requirements must be correct, meaning that the final result must actually satisfy the user's real (and not perceived) needs. This is the difference between "must have" and "would like to have" in the user world. If your project fails to deliver on the "must have" requirements, the project will be perceived by the user as less than successful (or a total failure altogether). Quality (errors, defects) and grade (functionality) are closely related in the user's mind as well. Grade is set through user requirements and quality is determined by how well the project conforms to those requirements.

7.2.4. Prevention Versus Correction

The old saying "an ounce of prevention is worth a pound of cure" is certainly true when it comes to quality. It's always easier and more beneficial to build quality into your project from the beginning. To go back once the project is underway or worse, to handle quality in the quality testing procedures as the end of your project, is the least desirable way of approaching quality. It is less costly and less time consuming to build quality into the project than to go back and try to correct things after the project is underway (or nearly completed). Quality management systems focus on preventing quality problems rather than correcting them. We'll discuss the cost of quality in more detail in a moment.

7.2.5. Continuous Improvement

Continuous improvement is another component of quality management. You may be familiar with the plan-do-check-act cycle (part of many quality systems). The point is that the process is continuous, or iterative, and you create your plans, go do your project, check the results, and take appropriate action to improve your project planning processes.

7.2.6. Management Commitment

If you recall from our discussion back in Chapter 1, projects that are most often successful are those with executive support. This is especially true when it comes to quality. If your company's focus is to get the project out the door as soon as possible and it does not value or emphasize planning, the quality of the finished product will likely suffer. Management or executives must be willing to make the investments in the project to ensure quality; this includes giving the project (and project team) enough time, money, and resources to get the job done right. Certainly there are limits on all of those, but a quality management approach recognizes that the project team cannot be held completely or solely responsible for quality; it is the responsibility of management to support quality efforts.

Applying Your Knowledge

If you want to deliver a quality project to your sponsor, project stake-holders, and users, you'll need to make sure management is aligned with your view of quality. Otherwise, you'll be specifying certain level of quality while your management team delays or denies requests for the resources you need to deliver on those quality commitments. If that happens, your project is going to wobble without the necessary resources to generate a quality result. There's only so much you can do with glue and rubber bands.

The process of planning for quality is depicted in Figure 7.2 As you can see, the initial project plan is one of two inputs to quality planning. The second input is your company's quality policy. If your company does not have a quality policy, you may still have some idea of the level of quality your company expects and what it will typically take to deliver that expected level of quality. If your company doesn't have a formal quality policy, you can write up your thoughts about expected level of quality and use those as the second input to this process, if desired.

Figure 7-2. IT Project Quality Planning Phase

Within the quality planning phase or process, there are six distinct steps that we'll outline here and then discuss in more detail in this chapter.

1. INPUTS The approved initial project plan is one of two inputs for this phase. Although you could begin planning quality as you begin defining and organizing your project, you can also start at this point once you have a fairly well defined project. The second input is information or specifications from your company's corporate quality policy, if you have one. Many companies do not have a quality policy, but if one exists, you can use it as a second input to your quality planning process.

2. ACTION The quality planning process is an overarching process that impacts all phases of your project planning. There is always a tradeoff between the cost and benefit of quality. The benefits are typically less rework and higher user satisfaction. The cost is often captured in additional planning, monitoring, and testing. There is a balance between the two and often this balance is defined by a corporate quality policy, if one exists. Benchmarking provides a basis against which you can measure quality performance in the project. Analyzing the estimated cost of quality involves capturing the cost to build quality into the project as well as the costs of poor quality. For instance, quality costs might involve the cost of planning to avoid errors and rework. The cost of poor quality might involve lost sales, poor company reputation, rework and after-release fixes.

   At any point during the quality planning process, you may need to go back to your initial project plan to make revisions or you may need to go all the way back to your users and project sponsor for clarification and/or negotiation on certain points. If you recall from Chapter 6, when creating the requirements you may find through your quality planning process that you cannot reasonably deliver some of the requirements at the specified or desired quality levels. Remember, too, that quality is one of the four key project elements: scope, time, cost, and quality. If quality must be increased, it means that something else will have to changeusually time or cost will increase. In some cases, scope may decrease and this is where negotiating with either the users or the project sponsor becomes key to project success.

3. OUTPUT The result of this process is the overall quality plan. It contains the information that will allow you to plan, monitor, and test quality throughout the remainder of the project. This plan can contain a wide array of data, depending on your project and how your company operates. Three typical components of any quality plan are quality objectives, quality metrics, and quality checklists. We'll discuss these in more detail later in this chapter.

4. ACTION The overall quality plan should be integrated into the initial project plan and prepared for review by the project sponsor.

5. CHECKPOINT The checkpoint of this phase is the approval of the revised initial project plan (which now contains a quality component). Any revisions to the initial project plan should be approved by the project sponsor and stakeholders before proceeding. You may also need to clarify or revise additional elements of the plan based on sponsor or stakeholder feedback or requirements. Hopefully, this step will result in only minor changes to your plan and not a major revision.

6. NEXT STEP Once you have an approved, revised initial project plan, you can move into the planning stages where you and the project team will develop the project details. This is discussed in Chapter 9, after we discuss putting together your project team in Chapter 8. Remember, too, that there may be times when you've gone through all these steps and may have determined that the project is not viable and should be terminated. For instance, if given the scope, time, and cost you will be unable to deliver anything close to the quality expected, you may choose to delay or terminate the project. If your budget is suddenly slashed or the scope is dramatically increased, you may decide to terminate this project and go back and start from scratch so you can better define and organize your project with these drastically different parameters.

7.2.7. The Cost of Quality

There have been numerous studies done on the costs associated with higher and lower quality. Many in the IT world have focused on software development. While there are many other kinds of IT projects that require quality, we're going to look just at software development for the moment, in part because the statistics are readily available and in part because we can all relate to using software that works well and software that drives us nuts due to errors and bugs. Many studies have been done, but the one mentioned at the opening of this chapter by IBM is significant. It's hard to argue with an ROI of over 400% for implementing a software process improvement program. There's additional data that supports the statistics cited earlier. Figure 7.3 shows the Rayleigh probability distribution (see http://en.wikipedia.org/wiki/Rayleigh_distribution for more on this subject) and a picture is worth a thousand words in this case.

Figure 7-3. The Cost of Fixing Software Defects

Clearly, defects in the design (which come directly from requirements) are far less expensive to fix earlier in the process. If you wait until the project result (in this case, a software program) is released to the customer, the cost is 100 times what it would have been back in the design stage for issues discovered by the user. The same type of cost structure applies to all types of IT projects. You have to begin with solid requirements and you have to use the processes, procedures, and metrics specified within the project to deliver a quality product at the other end. Whether your IT project involves improving network security through better intrusion and detection or upgrading servers or implementing supply chain management tools or integrating legacy applications with the Web, your IT project will benefit greatly from implementing an IT project management system (described in this book) and possibly other quality management systems appropriate to your company, industry, and focus.

If you recall, in Chapter 1 we mentioned that it's been estimated that 50% to 75% of the total cost of any project is due to errors, rework, and omissions. The errors, rework, and omissions happen throughout the project lifecycle, but the sooner they are discovered, the less expensive they are to repair. The corollary to that is that the fewer there are to begin with, the lower the cost and higher the quality of the final project.

Enterprise 128 …
Quality Versus Grade

Think back to our story of Enterprise 128, the early-to-market home computer that failed to find a following (see Chapter 1 for the whole story). Based on what you've learned in this chapter so far, what would you say the problem was? The problem was primarily one of grade. We have no idea what the quality of the product was from the perspective of whether or not it generated errors, had buggy software or hardware, halted, overheated, or crashed, and we don't know what how the requirements were written (how many errors/defects were acceptable?). We don't know any of that. What we do know is that the machine had all kinds of functionality the user didn't need or want. From the user perspective, then, the quality was probably not as much the issue as was the grade. It had too much functionality. The technical specifications were apparently not derived from the functional specifications generated through thorough market research or interviews with prospective users, but were apparently derived from what a few engineers thought would be fun, useful, or cool. Even if that machine had zero errors, never crashed, and never so much as hiccoughed, it wasn't useful to users and never really took off. A lower grade product would have done the trickif only the inventors had known, they might now be where Michael Dell is.