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:
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.
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.
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.