Quality is one of those matters much discussed, but practiced mostly in the breach. Organisations proudly proclaim quality products—they talk the talk—but when it comes time to walk the walk, what do they typically do? They fall back on the old stand-bys of tradition, intuition and trial-and error.
The reasons for this are many: the unrelenting pressure of the quarterly bottom line, excessive self-confidence (arrogance) of management, reluctance to change and try something new and so on. Perhaps the most ubiquitous—and easiest to remedy—is the absence of knowledge and a clear method for quality improvement—that is, a roadmap of specific, proven steps.
A seven-step model for project quality management may be the solution to procrastination and missteps. The model comprises a progressive series of actions—a journey—that addresses customers, requirements, specifications, quality assurance activities, quality assurance plans, quality control and continuous improvement.
It is compliant with quality management guidance contained in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and adheres to the basic quality principles promulgated by W. Edwards Deming and Joseph Juran.
1. Identifying Your Customers
Customers are the foundation of quality—-not products and certainly not quarterly financial statements. Without customers, there are no products or financial statements. The first action in managing project quality is to identify customers. Simply, this may be a list of organisations or people who buy current products. However, that’s too simple. It’s not at all complete.
Customers exist in three categories: external, internal and hidden. External customers, those outside the organisation or project team, buy or use the product or supply essential resources. Internal customers, those inside the organisation or project team, participate in producing the product, often in a chain of sequential activities. Hidden customers lurk in the shadows. They are not directly involved in production or use of the product, but they may have regulatory obligations or be concerned about the product to a degree that compels them to influence its production or use.
Customers must be exhaustively identified by analysing the contract or project charter, analysing the project team and organisation, analysing product use and analysing the means of production. Overlooking a customer may result in a show-stopping surprise when that customer later appears.
An exhaustive customer list may be complete, but it also may be confusing because of sheer numbers. The next action in managing project quality is to prioritise the list of customers. Not all customers are created equal. In the effort to identify all possible customers, a project team may include some of only trivial importance. Prioritising the list will help a project team focus on customers who may truly determine success of the project.
Customer prioritisation should be accomplished in a disciplined way. This is not the time to have a meeting and ask people around the table what they think. An effective tool for prioritisation is the L-shaped matrix, which permits pair-wise comparisons of all customers and generates a bias-free, ordered list.
2. Identifying Requirements
Customers are important because they are the source of requirements. Meeting customer requirements is one of the classic definitions of quality. The next action, identifying requirements, can be a challenge. Some requirements are clearly stated in the contract or project charter. However, these documents usually include requirements of external customers, not internal or hidden customers.
Project teams must carefully analyse each customer to identify requirements. Sometimes an interview with the customer may suffice. Other times, more comprehensive analysis may be necessary, as customers don’t always know what they want or what is possible, or they are not able to articulate their requirements well.
Requirements, like customers, are not all created equal and must be prioritized. An effective tool for prioritising requirements is the full analytical criteria method, which uses a series of L-shaped matrices to analyse requirements from the views of individual customers. Combining the results into a single matrix provides a bias-free prioritisation that is not possible by less formal means.
Requirements are not vague musings of interest, but they are rather generally stated.
The next action is to make all requirements explicit—to turn them into specifications that are measurable to the degree that they can be used to guide project performance and determine project success. Some specifications may already exist in the contract or project charter. Others must be defined individually from requirements. The key is to produce a list of things that are specific and measurable, and that are agreed to by customers and the project team.
4. Quality Assurance
The actions taken so far are matters of quality planning. The next actions are matters of quality assurance. Specifications are performance targets. How does a project team get there? Just start work and hope for the best? Maybe take corrective action as failure becomes apparent? Absolutely not.
The project team must carefully analyse each specification and develop an operational definition that unambiguously describes what is expected. The team must then develop metrics-means of measurement—that they will use to evaluate progress toward the target established by the specification.
Last, the team must define actions to be taken to ensure that performance meets the target. These actions-these quality assurance activities—are the checks that the team will apply during project performance to ensure that results are what they should be. They include a collection of data and comparison of the data with planned results.
5. Quality Assurance Plan
The next action is to assemble all quality assurance activities into a quality assurance plan. Formats for such plans may vary among organisations, but the common elements should be the same. A quality assurance plan should include a reference to a specific work package or work breakdown structure element, a description of the requirement, a description of the specification, a description of the quality assurance activity (what is to be done), an indication of when the activity should occur, and designation of the person who is responsible for completing the activity.
6. Quality Control
The next actions are matters of quality control. Defining planned, systematic activities to ensure that the performance is consistent with the plan is quality assurance. Taking measurements, collecting data, analysing results and acting on those results is quality control. Many time-proven tools exist that allow project teams to perform quality control functions such as collecting data, understanding data, understanding processes, analysing processes and solving problems. Project teams must do all these things and they must use effective tools to do them right.
7. Continuous Improvement
Conforming to specifications may seem to be all that’s necessary for project success. It is not. Such a view considers the customers of the project for sure, but it does not consider the competitors of the project team-the people and organisations whose goal in life is to take those customers away and make them theirs. Competitors take away customers by providing better or cheaper products. And they often do this through improved processes and methods.
Continuous improvement is the last action to be taken in managing project quality, but it is not a “last” action; it is something that goes on forever and never, ever ends. A classic and perhaps the best tool for continuous improvement is the plan-do-check-act cycle, which provides a framework of four disciplined steps to be applied as a continuous loop.
A Model for Improvement
All of the actions described here are shown graphically in the seven-step model (Figure 1).
Figure 1. Seven-Step Quality Model
Like many models, it is a much-abbreviated depiction of a rather complex process. It provides a framework for success, but only for those who choose to apply it. It’s no good if you don’t use it. There are many reasons for not doing project quality management, but they all come down to people. Consider the following conversation:
Worker: Boss, I’ve got an idea for improvement.
Boss: So you’re saying what I’m doing is bad?
Worker: No, no. I’ve just got an idea about doing something better.
Boss: So you want me to tell my boss that what I’ve been doing is not as good as it should have been? That’s bad.
Worker: Never mind.
There’s no nice way to say this. In hierarchical organisations, which hold sway in both public and private sectors, the boss is always right. Customer satisfaction is a great concept, but the bottom line controls all. Teamwork is a great tool for others, but bosses demand obedience. Suggestions are always welcome, but it’s often “shut up and do what you’re told or you’re fired.” Not exactly a quality paradigm, but oh-so prevalent in today’s world.
The solution lies in the Gotta-Wanna Rule: “You gotta wanna get better.” You must want to improve. You must feel driven to improve. Quality is not something that happens by itself. It is not something that someone else does for you.
Quality: It’s what you do that counts.