 |
 |
 |
 |
2.6P Plan Quality
(2.6P.P1)
Quality is ultimately defined by the client and represents how close the project and deliverables come to meeting the client’s requirements and expectations.
The old adage about quality being in the eyes of the beholder is true - quality is ultimately measured by your client. It is not up to the project team to determine the level of quality required for the project. The project team needs to understand the client's requirements and expectations - and then meet those expectations.
This is a critical concept about quality. Sometimes there is a tendency to think that 'quality' means the best material, the best equipment and absolutely zero defects. However, in most cases, the client does not expect, and cannot afford, a perfect solution. If there are a few bumps in the project or a few defects in the deliverable, the client can still say that the solution was delivered with a high level of quality. On the other hand, a flawlessly designed, defect-free solution that does not meet the client's needs is not considered high quality. The purpose of quality management is to first understand the expectations of the client in terms of quality and then put a proactive plan in place to meet those expectations.
Since quality is defined by the client, it may seem that it is completely subjective. However, there is a lot about quality that can be made objective. This requires first breaking down the generic term of 'quality' into the specific aspects of quality that are important to the client. Then, you look at each of the individual aspects and determine one or more metrics that can be collected to measure the characteristic. For instance, one of the features of a quality solution may be that it has a minimum amount of errors. This characteristic can be measured by counting errors and defects after the solution goes live.
Managing metrics and managing quality are related. It is very difficult to improve the quality of your deliverables or your efficiency of your processes if you are not gathering metrics. Metrics are used to give some indication of the beginning state of quality (quality of deliverables and quality of project processes) and whether quality is increasing or decreasing. In addition to determining the level of quality on a project, metrics can also be used to provide objective criteria to determine if your project was successful. This is the purpose of the project scorecard.
In addition to understanding the client’s definition of quality, it is important to recognize other stakeholder’s interests as well. Depending on the roles of the stakeholders, they may have other quality requirements that need to be satisfied. For instance:
-
The company – The solution meets strategic goals
-
Buyers - The solution meets specifications
-
End users – The solution helps them do their job better, faster, easier
-
IT support organization – The solution is stable, has few bugs, is understandable and can be modified easily
Click here to better understand the nature of quality management - 2.6.2.1P Understanding the Nature of Quality Management.
Small Projects (2.6P.P1)
Small projects are not long enough to review and improve the internal work processes to make them a higher quality (quality assurance). Therefore, small projects should just be concerned about quality control steps. Each deliverable produced should be reviewed and approved. The final review (perhaps the only one) is with the client. The review will focus on the overall quality of the deliverable. If the deliverable can be tested, the review will also include a discussion of the testing process, and a review of the actual test results.
This does not mean that you should be sloppy or deliver poor quality solutions on small projects. However, the work required to establish a formal quality management process, including quality control, quality assurance and gathering metrics to support the program, is normally not cost-beneficial for small projects.
Metrics on Small Projects (2.6P.P2)
For the most part, project managers on small projects should only concern themselves with capturing metrics that are required for all projects across the entire organization (if there are any). These usually consist of basic information such as how the project is progressing in terms of cost and duration. At the end of the project, these numbers can be compared against the original estimates to help determine how well the project performed against expectations. Client satisfaction metrics can also be gathered after the work is completed. Any other metrics that are required for all projects (if any) should be captured and reported as well.
There is usually not a need to capture more sophisticated metrics on the project deliverables since the deliverables are usually also fairly small. You do not need to collect metrics for process improvement since there is not enough time to make improvements or take any actions based on the results of the metrics.
