Stress That Quality is Everyone’s Responsibility

The project manager has overall responsibility for the quality management process. Some projects may also have specific roles for a quality assurance person or for testing experts. However, even if you have specific people who have responsibilities for quality, project quality is not the responsibility of one or two people. It is everyone’s responsibility.All of the team, including the client, has a stake in ensuring that the deliverables produced are of high quality. Everyone is also responsible for surfacing ideas for improvement to the processes used to create the deliverables.

Make Sure Quality is a Mindset, Not an Event

On some projects, quality is seen as a particular step in the process, or perhaps a series of activities at the end of the process. However, to be effective, the team needs to adopt a continuous quality mindset. The team members need to take ownership of the deliverables that they produce and ensure that the deliverables are built with quality when they are first created. They also must not get defensive when others review their work. Team members must realize that a quality process allows the entire project team to produce quality deliverables, with a minimal amount of errors and rework.

Project quality starts with planning but the execution of quality must be carried out throughout the project. A multifaceted approach to quality will include the following items:

• Establishing a Quality Management Plan early in the project
• Building quality into the team (training, communication, etc.)
• Building quality into the work processes (analysis, design, etc.)
• Building quality into project management deliverables
• Building quality into project deliverables

Identify and Minimize Rework

Strictly speaking, if you have a rigorous quality process in place, there should be no reason for a discussion of rework. In fact, rework is the result of not having rigorous enough quality processes in place to begin with. But, let’s be practical as well. No project can afford to spend the time and effort that would be required to guarantee that every deliverable is perfect the first time. Even a company operating at a ‘Six Sigma’ level has some small probability of error.

So, let’s assume that you have a sound Quality Management Plan in place. You still have to deal with rework. With some project methodologies that focus on getting deliverables created regardless of initial quality, rework may be built into the nature of the project. There are a few things to keep in mind about rework.

• Rework is not the same as your normal process of gathering feedback on deliverables. If you create a document and you circulate it to gather feedback, the resulting changes are not considered rework. These changes to the document are your way of making sure that you have a good document to begin with. However, if you publish your completed document and then find errors in the content, the resulting updates would be considered rework.
• Although you may accept rework as part of the nature of the project, it does not mean the project manager and project team should not strive to eliminate it. Your goal should always be to eliminate defects and rework by continually improving your processes.
• If there is to be rework, focus on finding it as early in the life cycle as possible. Remember that errors in the analysis will propagate into errors in design and errors in construction. If you don’t find the errors until the Testing Phase, there might be rework required throughout the life cycle (Analysis, Design and Construct Phases). On the other hand, there is less of a chance of propagating requirement errors downstream if you take the time to check for errors during the Analysis Phase and each subsequent project phase.
• You can track rework to determine how much of your project time is spent “thrashing” or working on the same problems twice. For instance, in the testing process you can track the number of errors that are fixed. When these errors are corrected, you may find that the change does not work to fix the problem adequately, which will cause rework. You may also find that the fix of one change may break something else. This second, unintended error will cause rework as well. You can track the total number of errors fixed, as well as the total number of errors that require rework. If the team gets tired and works long hours, rework will typically go up. You will want to drive the rework errors to zero, if possible.
• Rework is not the same as a scope change. Rework is caused by problems in the quality management process. Rework is needed to bring a deliverable up to the level of quality it should have been at to begin with. Scope change refers to modifying part of the solution because of a new requirement. The effort and cost associated with rework needs to be absorbed by the project. Effort and cost associated with scope changes should be agreed to and paid by the client.

www.tenstep.com