One of the areas that often lead to blank faces during our Project Management Professional (PMP)® exam preparation courses is Project Quality Management.

On this page:

• A Challenging Area for PMP Exam Preparation
• Quality Control Challenges in One-Off Projects and Software Development
• Quality Assurance vs. Quality Control: A Perspective Shift for Software Development
• The Importance of Upfront Work and Design Discussions in Software Development
• Enhancing Test Coverage: Seeding Bugs and Scatter Diagrams
• Considering the Cost of Quality in Project Budgets

A Challenging Area for PMP Exam Preparation

For people whose project leads to a product – a device or a novel potion – stringent quality control is a routine matter. Anyone who develops medical devices – such as stents or heart pacemakers – knows they have to assure their customers that these products will not experience failure when installed.

Similarly, projects that produce components, such as nuts and bolts, are required to provide specification sheets detailing all the necessary characteristics of a product. If you have ever bought a high-end sound system, you will find pages detailing the fidelity ranges of the product. Unfortunately, the demise of the audio cassette means that such delightful measures as “wow and flutter” are a thing of the past.

Quality Control Challenges in One-Off Projects and Software Development

For project managers in these industries, basic quality tools, such as cause and effect diagrams, flowcharts, check-sheets, Pareto diagrams, histograms, control charts and scatter diagrams are old news. But in other industries, where the product is a one-off – a construction project for instance – or where making copies of the product is not a problem (e.g. software), this type of quality control is unfamiliar.

Quality Assurance vs. Quality Control: A Perspective Shift for Software Development

We have noticed this with some of our students from software development organizations. Talk about quality assurance or quality control and they feel suddenly out of their depth. But change the word quality to test and suddenly it all makes sense. While the software developer does not have to ensure that every copy of the software deliverable is manufactured within strict tolerances, the first edition has to be (relatively) free of bugs.

But even here, the basics apply. You have a choice: you can either design quality in, or inspect it in. In the book, The Machine that Changed the World, Womack, Jones and Roos recount Toyota’s consternation when they visited Daimler Benz and discovered that the average Mercedes spent as much time in rectification as it did in manufacture. This prompted lean thinking and ideas like poka yoke, where you design the product to work only one way (e.g. the USB key can only be plugged in one way).

The Importance of Upfront Work and Design Discussions in Software Development

Similarly, in the software world, you can spend time refining the design and architecture of the product – ideally prototyping some of the algorithms. Then have serious design discussions – maybe evaluating alternative solutions. Once an approach is agreed, the upfront work will translate into routine coding tasks and a less traumatic testing interval.

Unfortunately, many software houses rush the design and leave the quality of the product to be decided by the test team. For them, the basic quality tools will see some application. Test suites are often designed to stress specific aspects of the design. The idea being that a failure in one aspect of the software will not prevent tests of the other aspects from going ahead. So a test team might run a basic sanity test to confirm that the software is indeed ready for testing. Often these sanity tests are made available to developers before formal handover, to spare their blushes on the day. This is a form of Pareto analysis – identify the 20% of the tests that will flush out 80% of the bugs.

Enhancing Test Coverage: Seeding Bugs and Scatter Diagrams

Another technique that can be used is to seed the code with bugs. Suppose a large software system has 50 bugs deliberately introduced and the first test run uncovers 25 of them. This suggests that the tests are only capable of detecting half the problems and really need to be enhanced. Test teams tasked with shaking down a later evolution of a software product may carry out this sort of study on an earlier version to gain a measure of confidence in their test coverage.  They often use scatter diagrams to relate seeded and actual bugs.

Unfortunately, software testing can never exercise every possible scenario the product may be exposed to in the field. So statistical sampling needs to be employed, just like they do on assembly lines. If thousands of components are coming off the line, not all of them can be inspected. So a percentage figure needs to be arrived at that allows the most defects to be captured for the least cost.

Considering the Cost of Quality in Project Budgets

No matter how you test your products, it will involve expense and that expense needs to appear in the project’s budget, under the heading “cost of quality”.