Improving Quality Nuggets: Rule 3

This one rule in a multipart series. Please see the intro article for the full list of rules.

Rule 3: Not knowing your deliverables are free of defects is sometimes only marginally better than having the defects.

The simple question of whether or not a deliverable is completed could be binary question. However, we know that “completed” can mean many different things. It could be done in a minimum viable way. It could be completed with a high degree of diligence and at the highest quality level.

In a large project which spans multiple teams (which could even be multiple vendors) we might see significant integration testing. In this case, we don’t want to have our team be the cause of delay or failure (of even the perception of such). This will quickly fatigue and sour our customer if we are the frequently cause of delay or even frequently suspected of causing delay as a perception.

During an integration test when an issue is discovered it might be a valid issue and this needs to be addressed quickly. However, there are many times during a root cause analysis of a failed integration test where there will be multiple suspects of the cause of the issue. In this case knowing the state of your deliverables with certainty in meeting the requirements will quickly allow the troubleshooting to move away from the falsely suspected deliverable and onto productive remediation efforts.

Efficiently demonstrating that you know your deliverables well and it is not the cause of downstream issues is a great service to the customer. To illustrate the point, I’ve sometimes said not fully knowing how and why your deliverable works is nearly the same as the deliverable not working when we are investigating and trying to rule out issues in a root cause analysis. We don’t want to be unfairly blamed for the cause of issues and chew up time because of our poor understanding or incoherent documentation.

I worked with a team at a project site in Times Square in New York that embraced this concept. One of the ways we would cajole those with deliverables of unsure quality would be to repeat the phrase “But it worked yesterday!”. Someone had uttered this phrase at some point in the project. This implied it doesn’t work today even though it did work yesterday but we don’t know why. Knowing with certainty the state of your deliverables is an additional value to your customer beyond them being defect free.

Go to Next Rule

Return to Intro and Rule List

Disclaimer: The opinions expressed are solely mine. They do not necessarily reflect the view of any of my employers nor relating to their business or policies.