My 2nd book What Drives Quality is available on Amazon, in my webshop, and in all other major bookstores.
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?
Detailed posts are available for “What Drives Quality”:
- Requirements
- Architecture and Design
- Coding
- Reviews and Inspection
- Testing
- Project Management
- Senior Management
- Operational Management
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, instead 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, coding, review and inspection, and testing) and management activities (e.g. senior management, operational management and 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 their quality improvements are driven by business value.
There’s my book on what drives quality which helps you to prevent software problems from happening by building an shared understanding what drives software quality. It enables you to effectively take actions, saving time and money!
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!
What Drives Quality: The Book
The book What Drives Quality helps you to prevent software problems from happening by building a shared understanding what drives software quality. It enables you to effectively take actions, saving time and money! This blog has been included this book.
(updated on Feb 15 2017: All detailed posts on what drives quality have been linked into this article)
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.
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.
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 ?
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.