Should every car be built to the same quality as a Rolls Royce? Should every software upgrade be delayed until all the bugs are removed?
I don’t think any program would ever be complete if we sought perfection.
Quality decisions are not just a matter of the reliability of the end product – they can also affect the scope and project approach.
Quality does not simply mean that a product, such as a bicycle, is built well. Quality in project management refers not only to the product (the tangible deliverable), but also the numerous processes that intertwine in order to achieve that goal. So quality is not just an end, it is also a means.
The lens of quality needs to be applied to everything that we do as a program manager. This is not just a philosophical or ethical point; it is a bottom-line business point. Your sponsor may tolerate paying more than anticipated (this happens quite a bit, actually…), or may tolerate things taking longer than they were supposed to (see previous note), and they may even tolerate accepting a product that is of a smaller scope than originally targeted, provided that this is something that everyone is OK with well ahead of time. But this is certainly not the situation you aim for as a program manager.
We believe such unpleasant situations can be avoided relatively easily. A quality process need not be cumbersome. We recommend a three step process:
- Define quality standards in advance
- Review deliverables against standards
- Ensure delivery is in line with the overall aims
The goal of quality management is ensuring that what the program delivers will achieve the overall program’s objectives. This sounds simple enough. But most programs struggle to follow the three step process outlined above.
What experiences have you had struggling to meet quality standards?