What drives quality?

Posted on by

Many methods for product quality improvement start by investigating the problems, and then working their way back to the point where the problem started. For instance audits and Root Cause Analysis work this way. But what if you could prevent problems from happening, by building an understanding what drives quality, thus enabling to take action before problems actually occur?

Update: Detailed posts available for “What Drives Quality”:

As an affiliate of the Software Engineering Institute (SEI) I investigated factors that influence the quality of software products. My aim was not to come up with a generalized set of quality factors, in stead I focused on those factors that were considered important for the client that I was working with at that time. So the quality model that I developed was never intended to be generally applicable, though my expectations is that many of the factors in the model that drive quality could also be important for your organization (therefore I’m sharing it with you :-) ). The model contains both technical phases (e.g., requirements, design, implementation, test) and management activities (e.g., line management, process management, project management).

Picture: Quality factor model

The quality model was validated by reviews with people from the client organization, and with international experts in the area of quality. Finally, with the use of Bayesian Belief Network I have developed an approach to define business cases for quality improvement. This metric based quality improvement approach is usable for both high maturity organizations that already have data, but also for lower maturity organization that are starting to deploy measurements and want to make sure that theit quality improvements are driven by business value.

In future postings I will be covering all of the areas from the quality model. A first posting will be on the factors that drive requirements quality. It will for instance cover quality factors like “requirements commitment”, and “scope stability”. Stay tuned!

 

  • Natarajan Sankaran

    We always claim that our focus should be on improving the Quality but in reality the organization never spent such efforts during project realization ,Always we work on corrective measures once the defects is found by customer and no such preventive measures are getting installed.May be the organization practising six sigma will have better yield,now a days there is a Agile fever everywhere and focus is only to reduce product lead time to market with “Just enough” quality.

    • http://www.benlinders.com BenLinders

      Fully agree with you. It is cheaper to prevent problems from happening, and to deliver the right quality. Six Sigma helps you to build the business case for (quality) improvements, while agile incorporates mechanisms to continuously improve your products, and the way you work as a team.

      I have seen combinations of Agile and Lean, which succeed in delivering products earlier to customers, with the right quality. Savings, both in money and in a more effective and efficient workforce can be huge.

  • Pingback: What Drives Quality: Requirements | Ben Linders

  • Pingback: What Drives Quality: Architecture and Design | Ben Linders

  • Pingback: What Drives Quality: Coding | Ben Linders

  • Pingback: What drives Quality: Review and Inspection | Ben Linders

  • http://lucianadrian.wordpress.com/ Lucian Adrian

    An attempt to put quality in software products just by using the process is hard, if there is no buy-in from the people who actually write the code and do the implementation. In this race towards shorter and shorter implementation times, estimates are done without taking into account the time needed to put quality in.
    When estimating, people just put the “write code” time, or just the time strictly needed for doing that step, without considering all the lessons learned during their work experience. If a more experienced person says “it will take me 4 days”, with quality in mind, there might be some junior who will say “I can do it in 2″, but this one does not have all the quality building time included. Guess what will management choose ?

    • http://www.benlinders.com BenLinders

      A process alone is never enough to improve. It’s the combination people-processes-tools, and in that order. Train and coach your professionals, and provide them room to develop themselves. Processes will help to synchtronise activities, and they can contribute to share best practices. But not to get people to work in a certain way.

      In a discussion on time-money-quality, it helps if you can quantify all of them. “I can do it in two days, but there will be 25% more defects from customers, which will cost you xx euro’s . The decision can still be to do it in two days, and to introduce the product with a lower quality, e.g. to be first on the market, or because the lower quality is acceptable for customers. But you’ve accepted that the total cost of ownership will be bigger, due to the maintenance and support costs that will come later.

  • Pingback: What drives Quality: Testing | Ben Linders

  • Pingback: What drives quality: Senior Management | Ben Linders

  • Pingback: What Drives Quality: Project Management | Ben Linders

  • Pingback: What is a “process”? | Ben Linders