Section 7.1. Introduction

7.1. Introduction

The title of this chapter is "Quality From the Ground Up" because it's important to build quality into your project right from the beginning. You can try to retrofit quality into your project later on, but it's just never the same. So, now that you've defined and organized your project, we're going to discuss the ways you can build quality into each phase of your project.

No one sets out to deliver poor quality results, but it happens all the time. These days, with corporate budgets being downsized and expenditures being thoroughly scrutinized and challenged, it's even more critical that projects deliver high-quality results. Lean economic times aren't the reason you should focus on building quality into your project, but they can certainly add pressure to do so. Whether your company is flush with cash or struggling to get by, your goal as the IT project manager should be to deliver the absolute highest quality result you can within the constraints of the project. It doesn't mean you necessarily deliver the absolute highest quality of all time, but the highest quality within the boundaries of your specific project. In this chapter, we'll explore this concept in more detail.

The biggest misconception about quality in any IT project is that it costs more money. That's not necessarily true and in fact, in 99.9% of the cases, it saves the company time and money far beyond the costs incurred. A study done by IBM in 1990 on the benefits of implementing Software Process Improvement (a.k.a. quality program) showed that implementing the program cost 0.005% of total corporate resources. You might immediately start doing some math, so let's make up some numbers. If the company has $1 billion in resources, the cost of the quality program would have been $5 million. As a result of implementing this quality program, the number of defects from 414 developers dropped by 50%. This saved 4 man-years (people-years, to be more exact) in software inspection time, 41 man-years in software testing time, and 410 man-years in post-release maintenance time. To simplify the math, we used a salary of $50,000 for all the people who might be involved in software inspection, testing, and maintenance. The total number of years saved was 455. At $50,000 each, that totals $22,750,000 saved. Spend $5M, save $22.75M. Any questions? [Source: "Using Cost Benefit Analysis to Develop Software Process Improvement Strategies", Department of Defense, 2000.]

There is a positive ROI (return on investment) for quality programs that are properly implemented and managed. How much of an ROI is dependent on several factors, but the point is that they net out in the gain column. There are also other costs associated with quality from the other side: the cost of poor quality. Think about the company's reputation, its ability to sell new software or the next version, the ability to convince people to convert to their software or product or to purchase the upgrade. All of those are dependent to a large degree (though not solely) on the quality of the product. The same holds true for hardware. If you build hardware that fails or hangs or halts intermittently (or regularly), customers will be reluctant to purchase or recommend your products. If you implement a poor quality project internally, you have to deal with downtime, repairs, maintenance, hot fixes, lost productivity, and more. There is a cost to implementing quality programs, but there is usually a higher cost associated with delivering poor quality. That factor is often difficult to quantify and it's rarely added in to the cost/benefit/risk analysis, though it should be. There are tangible examples out in the real world we can point to. One in particular makes the point painfully clear. The Denver airport stayed closed for over a year due to software glitches in the automated baggage handling system. After millions of dollars wasted, it abandoned the system. What was the total cost of failure in this case? Hundreds of millions of dollars when all the time, effort, expense, and traveler inconvenience is totaled up.

It's also important to mention that while you may want to aim for perfection, you have to work with limited time, resources, and money to achieve your project's objectives, which can make perfection an elusive and expensive goal. You have to make tough choices sometimes and you never want to sacrifice quality, though that is often exactly what happens. If you implement a quality management program, your goal is to improve quality to the highest reasonable degree. In this chapter, we'll look at some of the ways you can build quality into your project without implementing an additional quality management program. However, other quality management programs are compatible with IT project management, so if your company has implemented a quality program, what you learn in this chapter will fit in nicely.

Now that you've read Chapters 5 and 6 and have defined and organized your project, you're ready to look at the components of quality in your project. When you've completed this chapter, you may choose to go back and refine/redefine some of the elements you've developed so far and that's fine. IT project management is an iterative process and making a quick second pass through the existing project materials developed to this point can be helpful. On the other hand, you may find that you've already gotten your project off to a good start and can continue forward into your project planning stages.

As we did in Chapters 5 and 6, let's begin by seeing exactly where we are. Figure 7.1 shows the IT project management overview and where we are in that process.

Figure 7-1. IT Project Management Process Overview

Quality is built into an IT project in three primary ways: planning, monitoring, and testing. We'll look at each of these areas in this chapter and then refer to them again in later chapters. The planning, monitoring, and testing elements occur in different phases of the project, so we'll revisit some of these topics again when we come to those stages of the project process. Let's also define a few terms before we head into the rest of the chapter.

  • Baseline The data used as a reference with which to compare future observations or results.

  • Benchmarking The process of setting a baseline or standard for analysis and comparison of future results or performance.

  • Grade Grade refers to the category assigned to products or results to indicate similar functional, but different technical specifications. Grade A and Grade B may work exactly alike, but one has different technical specifications than the other.

  • Quality The degree to which a set of inherent characteristics fulfill requirements. Quality is defined through functional specifications. The user's perception of quality is influenced by both functional and technical specifications (how well the project results conform to user expectations in terms of function and errors/defects).

How to Cheat at IT Project Management
How to Cheat at IT Project Management
ISBN: 1597490377
EAN: 2147483647
Year: 2005
Pages: 166

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: