The Process Group

Your Success is Our Business

Does Quality Matter?

Introduction
Whether product quality matters depends on whom you ask. Some organizations have come to believe that quality is a nice-to-have characteristic on lucky days. A few organizations treat quality as a competitive and efficiency advantage that must be achieved. 
bug1

On the whole, my experience is that most organizations value shipping something by a deadline over quality and have become used to spending between 30 and 60 percent of their resources fixing issues after the deadline. The immediate emotional rush of shipping something now trumps shipping something that works, even if customers are not happy and costs are more. 
 
The organizations that ship products with numerous bugs usually don’t have a very clear picture of the financial and project impact of rework. For example, if an organization operates with a 50% rework rate (compared to 10%), there is no clear view that 40% of the current resources could be spent on building another revenue-earning project. Managers and teams get used to the standard they operate at.
 
Why address quality — what is the payoff?
When determining whether quality should be improved, consider:
  • Your customers’ desire to order more of what you sell because it works. For internal IT organizations “more sales” means avoiding being replaced by an external supplier.
  • The total effort spent in rework throughout the project including the time for:
    • Redoing requirements
    • Redoing design
    • Repeated testing cycles and bug fixing 
    • Meetings and maintaining lists to communicate among developers, testers and managers on what bugs to fix
  • The total effort spent on software maintenance after delivery.
What could you do with the time if you reduced the total rework amount to 10% of the organization’s budget?
 
What can be done?
 

quality-practices

The knowledge level of engineering and quality practices across the software development community is, on the whole, limited. “We do Agile and some test” covers the bottom end of the range; the list of practices below covers the middle to the top end.

The following practices can be performed to clean up quality regardless of the project lifecycle model being used. If you are starting a new project, work from the top of the list. If you are in a buggy mess, pick from the end of the list for starters.

  1. Peer reviews of requirements, design information and interfaces
  2. Prototypes and simulation
  3. Peer reviews of code and interface definitions
  4. Peer reviews of test cases and test procedures
  5. Component testing
  6. Code coverage checks to determine what code has been tested
  7. Process audits to maintain the adoption of the organization’s best practices
  8. Integration testing
  9. Analysis of defect statistics to determine product state and areas for further investigation
  10. System and acceptance testing using the intended environment, user-oriented requirements and exception conditions

There are a host of other practices that exist to prevent quality problems, such as configuration management, requirements elicitation and risk management. See a good list at “What Does a Great Product Development Group Look Like?”

But there is no time for quality!
Don’t add time to the schedule for quality. Look for opportunities to replace existing rework with quality practices.

Conclusion
The goal is not to perform all quality practices immediately and aim at zero percent rework. Zero percent rework is not achievable and such a goal is not practical. Instead make a few rudimentary calculations of your quality and rework levels and aim to reduce the amount by 20%. Then select two or three practices and try them.

If you would like help addressing your quality and rework challenges, please contact us for a complimentary 45-minute chat, or just send an email.

[Forward this email to your boss! Subject: Here’s a cool tip for you] Quick Link

Simple Share Buttons
Simple Share Buttons