I love a good “war story” – good or bad – when it is in regard to project management processes. I think I learn more from these real-world examples than from other content on the subject matter.
One such story that has stuck with me from my MBA days was one in which a pharmaceutical manufacturing company had a maddening quality issue. You may be familiar with a version of this apparently true story as well.
On the assembly line, the packaging machinery would occasionally miss inserting product into the box as the box sped by. This resulted in some number of empty boxes being loaded into the shipping containers at the end of the assembly process. Every week the company received irate phone calls from its customers demanding replacements for the empty boxes in their shipments. And every week time, effort, and cost were required to replace the mis-shipped items.
An engineer was assigned to work on the problem until it was corrected. He devised a solution whereby the empty boxes were detected by weight, and as they were about to be packed into the shipping container, a puff of air was released to knock them off the assembly line. His solution was designed to allow only boxes containing product to be placed into the shipping containers.
Unfortunately, his solution was not foolproof, and although there were fewer quality issues with the shipments, some empty boxes still managed to get into the shipping containers.
The engineer spent weeks trying to solve the problem. Finally, the company called in a recently retired senior engineer to work on the problem. The retired engineer analyzed the problem, made a quick adjustment, and left ten minutes after arriving on site. He stated that the problem was solved.
The other engineers scurried to the assembly line to see what the old engineer had done. To their astonishment, his sole adjustment was to change the puff of air to a solid airflow. Any empty box that passed the airflow was immediately knocked off the line.
The retired engineer did not attempt to fix the initial over-engineered solution, but was able to apply common sense to the quality issue. His quick solution gave the company time to analyze and correct the larger quality issue of why product sometimes missed being placed in the boxes in the first place.
My previous two articles were on the topic of managing quality in IT project delivery (refer to “5 Principles for Managing Quality” and “These are the Costs of Poor Quality”). In my own experience, Project Managers and IT staff in general, tend to over-engineer solutions to problems of quality on their projects. This need not be. Solutions to quality issues are often just an application of common sense.
On one such project, our client’s oversight contractor demanded that we write our User Acceptance Test (UAT) scripts at the keystroke and enter-button detail (for reasons that are too detailed and mundane to explain here). The more detailed the UAT scripts, the more easily their practitioners could run the tests. I argued that if we were required to write the test scripts to that detail, then we didn’t need their high-priced practitioners. We could hire eighth graders, pay them twice the minimum wage, and save tens of thousands of dollars. (No, I didn’t really say this, but I certainly thought it.)
Here was the issue. We had estimated that to cover the requirements in the Requirements Traceability Matrix with a full suite of test cases, we would need to script over 6,000 scenarios. Over the years, we had developed a process and a format for scripting test cases that worked well with experienced testers. However, the oversight contractor felt that because their testers did not know the system, they needed scripts written with more detailed instructions.
I modeled a few scripts according to what they were asking. One of our typical ten-line scripts would have required as many as 100 to 120 lines of instruction to satisfy their request. Our workload was about to increase tenfold, which could not be accommodated in the schedule or the budget. At the same time, we knew that scripts that were too detailed would put the testers through rote motions and rob them of the critical thinking that was needed to conduct a solid UAT.
Our solution to this over-engineered request from the oversight contract: We wrote the scripts according to our proven process; we trained their practitioners on the system; and we placed two experienced team members on site with them for the duration of UAT to answer any questions that came up.
It worked. We wrote over 6,000 test scripts. The UAT testers learned the system inside out. They completed their testing on time and uncovered some potentially harmful defects. The project remained on schedule and on budget.
I have no idea if the puff of air story is true, but it is certainly illustrative. I do know that the UAT story is true, and it illustrates that when we apply the people aspects of project deliver (in this case, common sense), we will achieve quality results.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.