Quality Planning

When we do a project assessment, one of the items we ask to see is the quality plan. In our experience, the quality plan is one of the most frequently ignored areas in the overall project plan. People sometimes just assume that since the team wants to produce a high-quality product, it will happen. But if you just assume that the quality is there, you may be in for some unpleasant surprises . Not everyone defines quality in the same fashion. If you have not defined your approach to quality up front, how can you determine the level of quality in your finished product? Quality planning is the process of identifying quality standards that are applicable to your project and deciding how your project will meet these standards.

Numerous articles and books have been written on the subject of quality. You may be familiar-with the work of one of the quality movement gurus: Crosby, Juran, or Deming. Although each of these men defined a specific approach to quality, one common thread in their philosophies is that quality must be planned.

Note  

Quality management reaches very esoteric heights. Quality management programs such as total quality management (TQM) and Six Sigma strive for consistent quality modifications that result in nearly 100 percent throughput, in terms of high quality. Do an Internet search for 'TQM,' 'Six Sigma,' and 'ISO 9000' and you'll get plenty of hits for more thorough reading on this subject.

A key component of quality planning is the corporate quality policy. You need to determine if such a document exists in your organization, and if so, review the quality standards or direction on how to approach your project. If you are referencing a corporate quality policy, review that policy with your project team and the stakeholders to make sure everyone is familiar with the standards. You should also reference the quality policy in your quality management plan.

It would be impractical to quality check every single task on the project plan. Several tools and techniques are available to assist you in determining what to measure and how to measure. These decisions regarding quality measurement are documented in the quality plan.

Quality Planning Tools and Techniques

At this point you may be asking yourself 'How do I go about determining what quality activities I should include in my project?' What you need is a way to determine those areas of your project most likely to have quality issues that impact the success of the project.

Your corporate quality plan may include useful tools and techniques to determine where to focus your quality efforts. It may include standard tools that each project is expected to use.

Another area the project manager needs to consider is industry standards or government regulations. In particular, if you are producing a product that is regulated , you must be certain that it meets the criteria defined in the regulations. Failure to meet the provisions of a regulation could result in fines or jail terms. Regulations may also be in place for safety reason to protect workers and/or consumers.

Even if you do not have a corporate quality process and are working on a project with no predefined standards or regulations, you can use several techniques to determine what quality aspects of your project to measure. We will look at four of the most commonly used: cost-benefit analysis, benchmarking, flowcharting , and cost of quality.

Cost-Benefit Analysis

Cost-benefit analysis was discussed earlier in this book in Chapter 2, when we covered project selection. This technique is also useful in planning quality management. You need to identify those quality activities that will provide the most benefit at the least cost.

The benefits of quality are things like client satisfaction, less rework , and lower overall costs. IT projects often have test plans. Cost-benefit analysis can be used to help identify each point in the development phase where test scenarios should be run, as well as the type and number of test scenarios.

Benchmarking

Benchmarking is a technique that uses similar activities as a means of comparison. It is a very useful technique if you are changing or upgrading the way you currently do business. If you are changing the work environment, you want results equal to if not better than the current environment.

For IT projects benchmarking could include such items as a comparison of a new system response time with a similar application or the speed of report generation with the speed of the current system. Benchmarking is only applicable if there is valid data on the capabilities of the original system, and there are enough similarities that the comparison is meaningful.

Flowcharting and Process Diagrams

The notions between a flowchart and DFD are similar-you're trying to map a process flow- but with a DFD you are breaking things down into discreet chunks from which you can begin to develop your code.

Flowcharting uses diagrams that depict the relationship of various elements in the project. Developing a flowchart or a series of Data Flow Diagrams (DFDs) can help you anticipate where and when a problem may occur. You can build in checkpoints to assess the quality of a particular activity before the next step is started. To use a simple example from a home improvement project, you could build in a quality checkpoint to make sure the paint on the walls has dried before you hang your family photo collection.

Figure 6.2 shows a flowchart and a DFD for the process of a customer interacting with a company through a customer service website.

FIGURE 6.2 A Comparison between a Flowchart and a DFD

At first glance the flowchart looks considerably more difficult to interpret than the series of DFDs. However, you should note that the flowchart describes the flow from start to finish. DFDs start with what's called a 'context zero' diagram (note the 0 in the upper center of the starting box) and drill down into diagram levels 1, 2, and so on. The idea is that as you drill down, you get more and more information about a specific context. At some point, you've finally fleshed out the context so much that you have a solid place from which to begin coding. Some Computer Aided Software Engineering (CASE) tools have the capability of letting you create the DFDs within the CASE tool, then, with the push of a button, create the majority of the code associated with a given context.

Cost of Quality

Quality involves added work to the project, and it comes at a cost. Cost of quality is the cost of all of the work required to assure the project meets the quality standards. You can have costs associated with both the work you do to assure quality and with the ramifications of a poor quality product. The three types of costs associated with quality are prevention, appraisal, and failure.

Prevention Prevention costs cover the activities performed to avoid quality problems. These costs include quality planning, training, and any product or process testing.

Prevention costs are incurred by planning in activities like testing code at various phases: individual unit tests, integration testing that combines several modules, and in some cases a systems test that tests end to end. The purpose of these tests is to catch any potential problems early on as the work is being done.

Appraisal Appraisal costs cover the activities that keep the product defects from reaching the client. Appraisal costs include inspection, testing, and formal quality audits .

User acceptance testing is an appraisal cost. A small, controlled group of users runs scenarios to test the functionality of a new system before it is deployed.

Failure Failure costs cover the activities generated if the product fails. Failure costs include downtime, more user support, rework to correct critical problems, and possible scrapping of the project. Failure costs on a new customer support application could include additional user training or the need for extended on-site support.

Further failure costs are incurred if the product has left the organization and reached an external customer. These costs include recalls, warranty work, customer site visits , and the damage to the company's reputation.

As we mentioned in Chapter 2, quality is one of the constraints that all project managers must deal with. It really is a balancing act among the budget you have for the project, the time you're given to accomplish the project's goals, and the overall quality of the product. Quality is not free and it takes time; as project manager you need to plan for the appropriate quality steps and be prepared to explain the consequences of shortchanging quality in terms of failure costs.

The specific quality activities that you identify are documented in the quality management plan.

Quality Management Plan

The quality management plan documents the output from the quality planning tools and techniques by listing the quality activities that will be performed, the procedures used to complete the quality activities, and the resources required. This plan will be the basis for doing quality control when you are in project execution.

The procedures section of the plan includes more detailed information regarding the expected results from quality activities and the steps used to determine whether the quality standards are being met. The quality standards and the method used to measure these standards need to be clearly defined. Methods used to measure whether quality standards have been met include metrics, checklists, and exit criteria.

Metrics A metric is a standard of measurement that specifically defines how something will be measured. You can define metrics for any area of the project. Let's use a web sales application as an example. If you are going to measure quality of the checkout process, your metric might state that when the customer implements the checkout process, the system will multiply the price of each item by the quantity of items ordered and compute the applicable sales tax and shipping charges 100 percent of the time. This metric would be part of the test scenarios run against both code in the calculation unit and as part of the user acceptance test.

Checklists A checklist is a tool to list a series of steps that must be taken to complete an activity. As each step is completed it is marked off the list. This provides documentation that the steps were done and can also be used to track when the step was taken and who performed the work.

A quality checklist for user acceptance testing might contain the following items:

• Schedule 10 users to complete test scenarios.

• Develop 20 test scenarios.

• Review scenarios and obtain client approval.

• Make copies of scenarios for each user.

• Train the 10 users on how to run the scenarios and document their results.

• Review user results.

• Document defects.

  Note  

  You can hire contractors who specialize in testing processes. Also note that companies specialize in validation of a specific development process. These specialists are called Independent Validation and Verification (IV & V) companies and can be an invaluable aid in large software development and deployment projects. They perform the function of keeping everyone on their toes with eyes fixed straight ahead on the project. (See NASA's IV&V site http://www.ivv.nasa.gov/business/ivv/index.shtml for more in-depth information on this intriguing and substantial subject.)

Exit Criteria We discussed exit criteria briefly in Chapter 4 when we talked about milestones. To refresh your memory, a milestone marks a key event in the project life cycle. If your project life cycle methodology uses milestones to mark the end of one project phase and the beginning of the next phase, the milestones between phases may include quality exit criteria. In this case your quality plan should document the criteria that must be met at each phase to consider that phase complete. Software development projects frequently use a series of tests to confirm the quality of the major deliverables for each phase. These tests can be established as exit or entrance criteria. For example, a unit test can be used as a criterion to signify the completion of code development.

The quality management plan should also address how the results of the quality activities will be reviewed with the project sponsor and other stakeholders. Identification of any activities requiring formal sign-off is also documented. A user acceptance test may not be considered complete until the client or a designated representative approves the results.