Who wants to deliver a quality product?
Kim R. Hinton, PMP, Merck and Co. Inc.
What you deliver at the end of your project is your calling card, the final impression upon which your reputation rests. As a first-rate project manager, you want the final product to be clear, easy to implement and valuable to the client. In this paper, we will review what constitutes a quality product and why planning quality into the final product is important. The paper will also provide the reader with practical techniques that can be used to produce quality deliverables at the end of every project. Throughout the paper the term product will be used to describe the outcome of a project. This term has been purposely left generic because the output can come in many forms such as software, process maps, documentation, consumer goods, etc. The products may be different but the quality concepts discussed here apply to all outputs.
What is All the Fuss About Quality?
Webster defines quality as “a degree of excellence or a distinguishing attribute.” James R. Evans and William M. Lindsay, in their book The Management and Control of Quality, described quality assurance as any action directed toward providing consumers with products (goods and services) of appropriate quality. While Hamid Noori and Russell Radford, in their book Production and Operations Management: Total Quality and Responsiveness, define total quality management in terms of four basic principles (1) intense focus on customer satisfaction, (2) accurate measurement of activities, (3) continuous improvement of products and processes, and (4) empowerment of the people. Lewis R. Ireland, a PMI Fellow and distinguished author of the book Quality Management for Projects and Programs,defines quality in its purest form as the totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs. Finally, the PMBOK® Guide portrays quality in terms of the three processes required to ensure that the project will satisfy the needs for which it was undertaken. Those three processes being quality planning, quality assurance, and quality control.
At What Point Should Quality Assurance Be Initiated?
Despite what many believe, the quality explosion is not a new concept created in modern business models. In October 1887, William Cooper Procter, grandson of the founder of Procter & Gamble, told his employees “The first job we have is to turn out quality merchandise that consumers will buy and keep on buying. If we produce it efficiently and economically, we will earn a profit.” Mr. Procter hit on the two keys of quality, customer satisfaction and built in quality throughout the production process. It is not cost effective for quality to be inspected or tested into a product post-production. The cost will surely be greater than the benefit. Exhibit 1 shows the potential cost of correcting a product that is not quality at various stages in the production process.
As you can see, quality processes in place during the production planning and design phases avoid significant costs because rework at these phases are internally focused and typically require relatively small amounts of staff time.
During prototyping, more is at stake because expenditures are made to produce the prototype. Rework or a new prototype can become costly.
During production, tremendous costs may be incurred when inspection or testing uncovers major design/pre-production flaws that were not detected earlier. The cost to correct a defect in production can be more than 50% of the total cost to produce the final product. This is not the ideal phase to insert the initial quality checkpoint.
However, product flaws caught after production are by far the most costly. If a defective product makes it to the customer the repercussions can be devastating. The chart is conservative in portraying the costs associated with a production flaw at this phase. The costs to correct can involve legal liability to the customer and damage to the company's reputation as well as cost to replace or repair the product.
So how can we achieve quality throughout the project/process? Let's look at the points when quality is essential in Exhibit 2. The inputs to the process must be of high standards since they will be the foundation upon which the final product will be laid. During the input stage of a project, it is essential to standardize to ensure all inputs meet established minimum quality guidelines. During the process stage, the quality inputs must then be reviewed, tested and controlled to ensure they continue to meet and exceed the quality guidelines set forth at the onset. Finally, during the output stage, final checks and balances will ensure the deliverable meets its stated goal and has quality built into every step.
Using this illustration, here are a few proven techniques to assist project/production managers to plan quality into every phase.
Technique 1—Facilitate Kick-Off Meetings
The all important kick-off meeting allows everyone on the team to understand the vision of the project, understand their role in reaching the vision, and is the first opportunity to insert quality into the process and eventually into the product.
At the kick-off meeting, the team has its first opportunity to bond as a team and to exchange ideas about the project. It is at this meeting that the project manager must prepare the team to think about the end product and the steps to produce the best product that team can produce. Brainstorming ideas and white boarding the team's thoughts will facilitate an open discussion around best practices. Use the energy in the room to charge the project right from the start.
Technique 2—Develop Traceable Requirements
Development of the requirements is an important step in the process. However, if those requirements are not traceable to the design documentation, development and eventually testing, the best designs can become useless. There needs to be a clear track from what is desired of the product and what is actually produced. There are many commercial requirements management tools on the market and some of them are quite good at tracking and managing requirements especially when the requirements are not one to one throughout the life cycle of the project.
Why trace a requirement? This can best be answered by illustration. A customer requests that the provisioning software being produced have the ability to highlight the screen automatically when a change in service has been requested. This is a priority requirement for the customer, a must do. This requirement is then rolled up into a broader design specification that deals with screen design items such as color, location of text and font attributes. Some of these rolled up requirements are high priority and some are low priority. In development, the budget is overextended and some development cuts are made, one being this design specification in its entirety. The software then completes its testing and is delivered to the customer who is now very dissatisfied. The one requirement that was articulated from the start was not delivered. If that requirement had been traced, the software would have flagged the programmer that a high priority requirement was being eliminated and the project manager could have made an informed decision about the requirement.
Technique 3—Create Templates
Templates serve a variety of purposes. They reduce cycle time to produce a deliverable by reducing or eliminating the need for the same product to be produced over and over again from scratch. With a template there is no need to reinvent the wheel so team members can spend their time perfecting their output.
They provide a strong foundation upon which the customized deliverable is built. A good portion of the time spent producing the final product is determining what that final product should look like. With a template as the standard input, the team member can use an already proven design and simply customize it to meet the needs of the current customer.
Templates also produce standard products that become familiar to the client, the team and the project manager. Everyone is busy these days. Imagine how much time could be saved if all documents of a certain type looked the same way no matter who produced them. This would allow quick decisions to be made about the disposition of the document and would facilitate a speedy review.
Finally, they are the corner stone of a quality product if the template is well designed and used consistently.
Technique 4—Use Statistical Control Tools
Tools such as stratified frequency plots, scatter diagrams, cause and effect diagrams, multi-variant analysis and control charts assist in identifying variation in the process and facilitate root cause analysis to minimize the effect of the variations on the final product. How and when each of these should be used varies. So let's take a look at each.
Stratified frequency plots are often used in manufacturing environments to analyze the results of a continuous process. For example you could stratify cycle time by type of product or the number of errors by day of week. From a quality perspective this will allow the analyst to isolate the problem and zoom in on a solution to correct the variation.
The scatter plot, again most efficiently used in manufacturing, looks at the relationship between two factors and can be applied to two or more groups. For instance, the scatter diagram in Exhibit 3 shows the relationship between cycle time to complete a job and amount of experience the worker has in years for both the day shift and the night shift.
This tool helps the analyst to quickly see the patterns. In this scatter diagram, the analyst can conclude that cycle time is higher in general on the day shift (the diamonds) and that cycle time increases with experience.
In the example above, the analyst in turn would investigate why these trends are contrary to what should reasonably be expected by performing a cause and effect analysis. The most popular tool used to analyze cause and effect is the fishbone diagram (appropriately named for its appearance) or Ishikawa diagram (after its inventor).
Multi-variant analysis is used to complement process analysis (scatter diagrams) and stratification (frequency plots). They help to explain the correlation and variance identified.
Control charts assist the process analyst determine if the process is in or out of control. With the use of upper and lower control limits, process variation can be assessed and controls can be put in place to reduce the variation in the process steps.
Since this paper is not focused on statistical tools, to answer specific questions about use of the various tools further research is recommended.
Technique 5—Perform Design Reviews
It is not enough to involve the customer in the requirements gathering. Customers, the designers, the developers and any other entity with an interest in the final product must be involved in the design. Once they are involved, they become stakeholders. Stakeholders should also be approvers of the design.
They should be involved throughout the design process but it is most important for them to be involved near the end of design to ensure the design is sound, meets the needs of the parties and is implementable. One way to do this is to hold a series of design reviews. Design reviews can be done by sending the design documents out to the interested parties with a review by date. All feedback is then incorporated and a revised design document is sent out. If the second document is acceptable the parties sign off on the document to show approval of the design. If not, the cycle of revise and re-review begins again until it is signed off completely. This method can be time consuming and costly. The other method is to hold a design review meeting where all the parties meet at once and discuss the design in detail. This method has proven to be the preferred method because all changes can be done at once and the parties, in theory, agree to the changes. Sign-off is usually quicker in the case of review meeting but the meeting can take a long time to schedule if many people are involved.
Technique 6—Test the Product
Enough can't be said about testing. Even though it has been proven time and time again testing a product identifies issues and allows for swift corrective action, some products are still getting out to the customer with this important step removed. The most prevalent reason for not performing a test of the final product is time. It never ceases to amaze me how there is never enough time to do a proper job of testing but there is plenty enough time to perform rework after the customer has received an inferior product and is dissatisfied.
There is a misconception that testing can only be done with software deliverables or systems. This is not true. You can test documentation and process maps or any other non-technical product as well. Let's explore how, using a process map as the deliverable. Testing begins with a solid test plan and test scripts. The test plan in this case would include scheduling the appropriate amount of time into the project schedule to sufficiently cover testing the product. It may also include who should test the process and how the feedback will be handled. The test scripts would include a series of questions aimed at making sure the process is complete and all possible process avenues have been identified and documented in the process map. Depending on the product this step may take some thought but the increase in quality will well out weigh any struggle to get there.
Technique 7—Control Versions of the Product
Up front in a project, versioning needs to be discussed and a version control process needs to be implemented. When the project team gets into the throws of delivering the product, all thoughts of controlling versions could be lost. Without this solid foundation of how versions will be maintained, the deliverable is in jeopardy.
If I have any misbelievers in the power of version control, let me impart to you a little anecdote that actually happened on one of my project teams. I had three teams working on different parts of a training manual for a piece of software we were deploying. There was version control but it was date based. Early on the morning before this manual was to be delivered to the customer, an issue was discovered that required a significant change to all three parts of the document. This information was shared across the three teams and they were off to work the changes into the document. One team made the changes, saved, then went to lunch. When they returned from lunch they realized they had missed a couple of the changes that they needed to make. They grabbed what they thought was the most recent version by the date and made the changes and emailed it off to me to consolidate with the other pieces. They grabbed “Training man1 11-3.” They should have grabbed “Training manual1 11-3.”
We learned a valuable lesson that day—version control doesn't mean date the version. From that moment on, when I get involved in multiple versions of a product, I use a standard naming convention and numbering scheme that includes the date as a double check.
ProjPlan—Type of document
V1.1—Version or revision number*
* Until the document is sent out for review to a wider audience, revision numbers are 0.1, 0.2, 0.3, etc. The version that is sent out for review is 1.0. Once it has been distributed for review, subsequent versions are 1.1, 1.2, 1.3 etc., until it is sent out for review or wide distribution again at which time it is change to 2.0. This pattern continues until the product is completed and the finished product is then marked final and the version numbers are removed.
Technique 8—Control the Scope
I challenge that the single greatest factor of poor quality deliverables in projects is scope creep. When resources are limited, a well thought out plan is established and the team is working to plan, a quality product should follow. But when additional work is introduced the team dynamics changes. People begin to rush or eliminate the steps that would otherwise ensure quality like testing and product review sessions (both mentioned earlier) in order to step up to the new workload. It is the responsibility of any project manager worth his or her salt to manage changes to the project and negotiate either more time or more resources for the project to ensure a quality product. Think about it, how much faith should people have in an estimate of work, if every time they make changes the team can absorb the extra work without compromise?
Technique 9—Perform Internal and External Reviews of the Draft Deliverable
Similar to the design reviews mentioned earlier, review of final draft deliverables is imperative. The first set of reviews should be with the internal team. I have often brought the whole team together to discuss each line of the final product for consistency and to ensure the product is well thought out and clear to the reader.
The next step is external reviews with the contributors to the document. This step will be a sanity check of the deliverable and will ensure buy-in on the content.
The final step is to go to the sponsor or owner of the project and review the contents of the deliverable with them and explain how the document should be used or implemented.
Technique 10—Pay Close Attention to Packaging Detail
I have assigned a team member during the final days before a product is delivered to the customer to what I call aesthetics duty. Their sole responsibility is to look at the document to make sure it looks perfect. They will not read the document. They will look for stray bullets, misused caps, and other style items that could potentially detract from the effectiveness of the final product.
As we have seen it is not prudent to inspect quality into the final product. Nor is it ideal to begin performing quality assurance after receiving the inputs to the process. To create a quality product takes building quality into all phases of the project/production. By following this end-to-end quality model, a project/production manager can reasonably expect to deliver quality every time.
Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA