The PMBOK(R) makes it sound simple enough. But for many of us, the relevant quality standards are not immediately obvious. In fact, many of us find ourselves with little other than the vague impression that the quality of prior projects was not good enough.
If we are to do appropriate Quality Planning, we must figure out how to answer these two pressing questions:
This is often not easy to do! Although our project stakeholders have clear ideas about some of their requirements, they are often unclear about others. For example, when asked about response times, they may want the system to respond to all user actions instantaneously. Since this is impossible, the Requirements Analyst will embark on a line of questioning to settle on the response times that are both acceptable and achievable.
Quality tends to be one of the attributes of a product that people have not though deeply about. They want absolute perfection. But because people build software, we know that ideal is out of reach. Therefore, the Requirements Analyst must question the stakeholders to ascertain the levels of quality that are both acceptable and attainable.
It is important to note that this information must come from the project stakeholders. The Quality Assurance group cannot dictate "good enough". Testers cannot set their own standards. Industry averages (although they are useful points of reference) tell you nothing about your project's needs. Even your organization's policies merely establish minimum targets. Only the people who know how the product will be used in the real business environment can determine the levels of quality that will meet their business needs.
If our stakeholders judge the quality of those prior projects to be "acceptable", then we have ready-made targets for each new project. If the quality of those prior projects fell short of their needs, then we know we must do better than those past projects. The question at issue is this: How much better must we do?
In order to define what "good enough" would have been on those past projects, we must understand specifically how they fell short. What are the drivers of the stakeholders' judgment that quality was not acceptable? Were too many defects delivered? Did one or two specific defects stand out as being serious problems? Was the project late due to interminable testing? Were there usability problems? Performance problems? Gaining a thorough understanding of the precise nature of the quality lapses will give us a basis for defining "good enough" for each new project.
The final step is to ensure that "good enough" is achievable on the project. If prior quality lapses were serious and numerous, then it is unlikely that you will be able to correct all of them immediately. So your strategy must be to make incremental improvement with each project.
For example: In the next project, correct a quality problem that had a large impact on the stakeholders. Then on the following project, correct another quality problem (while maintaining the earlier quality improvements). Soon you should be able to meet all of the quality needs of your project stakeholders.
Your choices for doing things differently fall into several categories:
Plan for quality just as you plan for anything else, and you will be more likely to achieve the quality standards that your customers need.
1. A Guide to the Project Management Body of Knowledge (PMBOK Guide), Third Edition, Project Management Institute, Inc, 2004, Section 8.1.
(R) "Project Management Body of Knowledge" and "PMBOK" are registered trademarks of the Project Management Institute, Inc.