Skip to content
Projects Strategy Community

Build Quality In – Lean Principle #2

This is a series of articles about the seven Lean Principles. The second is “Build Quality In”.

We have learned to use imperfect products. In that, China and Microsoft Windows have been quite helpful. The problem is how many repeated times you have needed to buy the same product over and over, fixing it, worrying, and getting annoyed about its bad quality.

I have said this many times: Quality is the only thing that remains when a project ends. All the other Subject Groups (in ISO 21500 terminology) or Knowledge Areas (in PMBOK terminology) end when the project is over. What remains is only the final product and its built in quality.

Quality products save many, many dollars – more than the small amount that you have had to pay to deliver your project as a quality product. But they don’t only save money, they save time. Time that can be used to perform new useful tasks and build new products.

Quality can’t be optional, quality is a must. Quality has a price, but it is worth it.

The Total Cost of Ownership (TCO) should always be considered in any serious Business Case.

Many times, Development Teams share tasks on new developments with maintenance of current applications. The more hours you are able to reduce from maintenance, due to a good built in quality, the more hours you can invest in real value tasks for your business.

“Build in quality” means trying to do things right the first time while minimizing reworks. Minimizing reworks means being sure what is demanded before starting work, working in little cycles (to lose as little effort as possible in cases that are required as reworks), getting intermediate customer acceptances of little deliveries, etc. Because when there are reworks, things are mended with solutions that were not initially the most clean, and later there is less time to do things right and build in quality.

Build in quality requires: different environments (development, test and production), good change management processes, segregation of duties (a no-hands-on policy for developers in production), customer approvals in test environment and secure releases (without changing anything from the release tested), post-implementation reviews and final customer acceptance on live environments, step-backwards plans in case something unexpected has happened, etc.

Does your organization support you for “build quality in”?

Not subscribed yet? Do it NOW!

Author: angelberniz (All Rights Reserved by the author)

Source: Original Text (based upon first hand knowledge)
Image: © Pressmaster –
Help us to improve it: how-to, discussion