Quality planning involves identifying which quality standards are relevant to the project and determining how to satisfy them.
The PMBOK® 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:
- What does it mean for our product to be “good enough”?
- How can we ensure that our product will be “good enough”?
We will discuss how to find the answers to those two questions in this first of three articles on the PMBOK®’s “Project Quality Management” Knowledge Area.
Who Defines “Good Enough”?
Although the concept of “good enough” is elusive, it is not beyond our reach. The appropriate level of quality is nothing more than a requirement for the product that we will build. Like features and functions, performance and usability, the needed quality levels must be identified and documented as a part of the requirements engineering process.
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.
Defining “Good Enough”
In order to work successfully with the project stakeholders to define “good enough,” we must give them ways to think about quality concretely. In the article, “Making Quality Planning Concrete”, we discussed how to use metrics to quantify quality achievements. Using those techniques, we can convert stakeholders’ impressions about prior projects into concrete terms.
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.
Planning to achieve “Good Enough”
Establishing the quality goals for your project is only half of Quality Planning. The other half is deciding what activities you will engage in on the project in order to achieve those goals. The quality-related activities that you normally include in your projects have gotten you to the quality performance you have experienced. If your goal is to achieve the same quality as on past projects, then doing the same things makes sense. But if your goal on this project is to improve on past results, then you will have to do something differently.
Your choices for doing things differently fall into several categories:
- Adding quality-related activities (e.g., starting to do code reviews)
- Doing more of the same (e.g., review 75% of all code instead of 25%)
- Improving the activities you have (e.g., adopt better testing techniques)
- Reduce the number of defects that need to be found and fixed (e.g., adopt a more effective software design methodology)
“Making Quality Planning Concrete” (referenced above) also discusses using metrics to understand how well your quality-related activities do their jobs. This will help you to identify the activities that are working well and those that should be improved or replaced.
Documenting Your Quality Plan
Your Quality Plan should be documented as part of your project plan. Your quality targets are included in the list of project objectives. And the quality-related activities you will employ are included along with all of the other activities in your work breakdown structure.
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.
This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge delivers comprehensive hands-on project management, business process, and professional skills training. Visit our online Knowledge Center at www.globalknowledge.com/business for free white papers, webinars, and more.
© Copyright 2007, Global Knowledge. All rights reserved.
No comments yet.