Why Achieving Zero Defects is Possible
A colleague once shared a rule of thumb with me that he learned in his training as a software development professional: “In software development, only three numbers matter: Zero, One, and Many.”
I have found this general rule to be fundamentally true in many software development projects with only a few exceptions. However, this had me thinking about what differentiates a “successful” development project from one that “fails,” or is disappointing in the implementation. To ensure successful, defect-free development projects, I propose an additional line to this rule of thumb…
“And the most important number, by far, is ZERO.”
Let me explain.
A software project is best driven from solid business goals, determined from either pain points or pursuit of competitive advantage. Therefore, a well-managed project first performs a thorough organizational and technical analysis of business expectations so the business goals are confirmed and very clearly understood. When these goals are fully met and properly supported by process and technology, the customer gets exactly what they asked and paid for – software that is fit for business use.
The customer has an expectation that its software will work the way it was envisioned at the agreed upon timeline. And, rightfully, does not expect to be dragged through the details during the process. The customer expects the end result of the project in which it is vested, both in process and technology, to be “fit for business use.”
It is the job of the development team to convert these business goals into a specific implementation plan. The key to this plan is to document clear, complete, and comprehensive requirements that are technically feasible and testable. The only way that “fitness of business use” can be achieved, by any preferred development partner, is through technical requirements that allow the end product to be measured by “conformance to the requirements.” Because anything non-conforming is a defect. And any defect could lead to failure.
While this process can sometimes go awry, for this discussion, let’s assume it has been done effectively. So now the technical team knows what they need to create. The quality team knows what they need to test. The production team knows what they need to operationally support. Technical requirements, both functional and non-functional, are the measure of success. This combined team can only succeed if the work product fully “conforms to requirements”.
As the work proceeds, defects are detected (with a defect being defined as a “failure to conform to requirements”). Typically, these defects are classified based on their impact or severity in the system and are usually resolved based upon a priority of “fix the most egregious defects first”.
Now comes the moment of truth for the team.
Time and resources are constrained and mostly consumed. Yet, there remains a pile of unresolved medium and low severity defects. The negotiation, usually driven by project managers, is “how many defects will the customer accept when we go live, because we have no confidence that we can fix them all”. Almost all of you reading will relate to this and think, “Yes, I know this is how it goes”.
This, in my view, is absolutely dead wrong.
The most important number for final defect count in a development project is ZERO, because ZERO is the goal that the entire team must have from the inception of the project. ZERO defects at production release is what the customer rightfully expects us to deliver.
Now you are thinking something like, “Sure, when pigs fly…”
Let me tell you that our teams have this culture. We always start with the team goal of delivering a work product that fully, completely, 100% complies with requirements at the time of production. An esteemed colleague of mine and Senior Manager at SDLC Partners, Gaurav Thakur, states it best, “We believe in doing the job right – the first time. With that, we have a set performance standard to achieve ZERO Defects. Anything more, whether one or many, is unacceptable.”
Achieving ZERO defects is not only possible…it’s being done regularly! So how is it possible?
First and foremost, it is a matter of the teams believing not only is it possible, but that it is the goal to which they WANT to commit. As we discuss this within our team, we run this “thought experiment”:
In x weeks, imagine sitting in this room together and that the production release was yesterday. We have two possible future realities:
- We have worked hard. We are tired, but we still have a remaining list of defects (which the client will be calling “bugs”). We will be under pressure to fix these or we will be struggling to find a believable excuse to ignore or defer these defects. Neither is professionally acceptable; but this, unfortunately, is the way software development projects usually go and we must accept it.
- We have worked hard and smart. We have a well-oiled team of developers and testers who have all of the tools, processes, and techniques to run an efficient and effective defect resolution cycle. These professionals are supported by the Requirements Analysts and the Production team who are there to promptly and accurately address any issues that fall outside the realm of “conformance to requirement” We are tired, but happy because we have ZERO defects in our queue. We can quietly report to the customer that they received everything they asked and paid for, as proven by the 100% compliance to the requirements that they signed. We are proud because we have performed to the highest standards of professional execution excellence. The customer is happy to have found a preferred development and execution partner who finally “gets it right the first time”. Our Project Managers have nothing to negotiate. We have attained the most important number on any development project, ZERO defects at production.
Having envisioned this future reality, I have yet to meet a professional who did not strongly prefer the second option, once they are convinced that it is possible. Done well, ZERO can be accomplished without significant increase in project time and resources – the magic comes in how the team works together and what tools and techniques are applied.
How we accomplish this goal is a topic for a future paper.
For now, let me leave you with this thought:
As professionals, we deal with uncertainty and risk every day. While we strive to make our customer and company executives happy, events make this difficult and the job becomes less satisfying. Job satisfaction comes from doing good work, in a manner that is not a compromise. We do good work because it is something that we are professionally proud to have created. The single measure of this success that matters the most in software development is ZERO DEFECTS AT PRODUCTION.