 |
 |
 |
 |
2.6.1T Plan Quality / Techniques
Understand the Characteristics of Quality for Your Project (2.6.1T.P1)
It is hard to define product or service quality at a high level because the term "quality” is nebulous and means different things to different people. You must take the time to define the lower-level characteristics of quality for each specific service or deliverable. If you want to ensure that a service or product meets the client’s expectations of quality, you have to understand the underlying characteristics of quality.
The following table shows some examples of specific quality characteristics:
|
Product Quality - The Product is: |
Service Quality – The People are: |
|
Reliable |
Responsive |
Have Confidence in the Costs and Benefits of Quality (2.6.1T.P2)
One of the basic tenets of quality management is that the overall benefits of building a quality solution will more than outweigh any incremental costs. For an explanation of the cost of quality, the benefit of quality and the cost of poor quality, see 2.6.2T Cost and Benefits of Quality.
Don’t “Goldplate” (Deliver More Requirements than the Client Requested) (2.6.1T.P3)
You should always strive to carefully set expectations and then meet those expectations. However, if you are not confident in your ability to deliver, you may also have heard it is better to under-promise, but over-deliver. This is actually a good thing if it refers to your ability to deliver your work earlier than promised or for less money than you estimated. However, it is not the right thing if you deliver more requirements or a higher level of quality than the client requested.
The term goldplating refers to delivering more quality than what the client requested. Even though it might seem that this is a good thing, it is wrong for two reasons. First, the primary focus of the project should be to make sure that you deliver what the client wants - on time and within budget. By adding in additional work, you increase the risk that the project will not meet its deadline or budget. If you end up missing your deadline date, you will not find sympathy if you explain that the date was missed because of adding more work than the client agreed to.
Second, if you goldplate, you are taking it upon yourself to make a business decision on what is of most value to the client. There may be some good reasons why the quality level was defined by the client. There may be more value in having the solution completed early and for less cost. The point is that this is a client decision and not one that the project manager should make.
Under-promising and over-delivering should only apply to delivering earlier or for less money than was anticipated. It should not include delivering more requirements than were asked for, or delivering to a higher level of quality than the customer expected. The client may, in fact, ask you to include more requirements in the solution. If the client does ask for more, the new quality requirement should be processed through scope change management. However, the client may have other uses for the savings that are more important to him. If you can complete the project earlier or for less money than was budgeted, let the client make the decision on what to do with the good fortune.
Make Sure Quality Management Focuses on Processes, Not People (2.6.1T.P4)
The focus of quality management is to build the right processes so that the entire team can produce the deliverables that meet the client’s expectations. Therefore, if a particular deliverable has a quality problem, the project manager and project team should focus on how the project work processes can be improved - not on trying to determine who is to blame.
Most problems with quality are the result of poor or inadequate work processes, not because of the malicious act of a particular person. In fact, it is thought that at least 80% of quality problems can be resolved by changing and strengthening business processes. Less than 20% of problems are under a team member’s control. Furthermore, the processes that your organization utilizes are largely determined by management. So, when workers or team members have quality problems, it is important for managers to identify the weak or broken processes involved and fix them. This is a management responsibility – not the responsibility of the staff. This does not mean that everyone cannot be involved (see the technique below). However, the setting up and enforcement of business processes is primarily a management responsibility.
To bring this idea close to home, the project manager is responsible for the processes used to manage and execute the project. If you find that you have quality problems on your project, you should look at ways to strengthen the work processes so the quality problems can be avoided (QA) or at least discovered as early as possible (QC).
Stress That Quality is Everyone's Responsibility (2.6.1T.P5)
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 (2.6.1T.P6)
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 …)
-
Building quality into the work processes (analysis, design, …)
-
Building quality into project management deliverables
-
Building quality into project deliverables
This multi-faceted and ongoing approach is the best way to build quality deliverables on a consistent basis.
Identify and Minimize Rework (2.6.1T.P7)
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.
Utilize Solid Quality Problem Resolution Techniques (2.6.1T.P8)
If you collect metrics on your processes and your deliverables, you may find that you are not meeting your quality commitments. There are a number of techniques that can be applied to identify the causes of the quality problems and determine which causes are of the highest priority to resolve. These techniques are the same ones that you can apply for any problem-solving exercise. Three popular techniques are described as part of the TenStep process - Manage Issues / Techniques section. They are cause and effect analysis, root cause analysis and Pareto analysis. You can find more information on fixing quality problems at 4.5.2T Manage Quality / Resolving Quality Problems.
Use Statistical Process Control Techniques to Ensure a Process Stays in Control (2.6.1T.P9)
When you look at the causes of product defects (errors), you will notice that they fall into two general categories. Dr. Edward Deming called these errors “special cause” and “common cause”.
Special cause errors are those that the local users of the product can find and fix. These include malfunctions, lack of training, misuse of equipment, vandalism, etc.
“Common causes” can cause large variations in quality and include systematic problems that the local users may not be aware of. For instance, common cause errors can include minor imperfections in equipment, poor product design, slow wear and tear on equipment, processes that are working but not optimized, etc. These are “common” problems, but they are very hard for the local users to detect.
Statistical Process Control (SPC) techniques can be used to monitor, manage, analyze and improve process performance by helping to eliminate the special causes of variation (the quality problems that can be detected most easily). For more information on Statistical Process Control and the use of Control Charts, please refer to 2.6.3T Statistical Process Control.
