How to Manage Errors in a Delivery

Quality failure happens. Sometimes even the most careful and conscientious companies deliver a lemon. The difference between the pros and those who have bit more to learn is the response to the quality failure.

Assume Responsibility
First – assume responsibility. Instead of arguing with the client, thank them. Sounds like it’s elementary, but at the end of a long project, after several scope changes some people get protective over their projects. Then give the client a deadline in which you’ll get back to them with more information. Then perform your due diligence. If time is critical for them and the error doesn’t keep them from QA-ing the rest of the delivery, tell them to continue and their testing and let you know of any other errors.

Due Diligence
Figure out what kind of error is occurring. There are a few kinds of quality failures:

1. Errors in the delivery where the objective is clear, but the delivery doesn’t reflect the objective.
2. Errors in the communication from the client of their expectation or from the company of their intention.

Research what the error impacts. Find out what aspects of the delivery are affected and estimate how long it will take to fix it in it’s entirety so the delivery is airtight (flawless).

Take this opportunity to get evidence to find out the source or cause of the error. If it’s a matter of a delivery error, it could just be sloppiness. It happens- but the more solid a process you have in place for QA, the less possibility it has of occurring.

If it’s communication mistakes- discern whether the error was on their end or your end. This is important because if it’s on your end- the fix will most likely have to be gratis. If it’s their end- you have a better chance of getting the client to pay for part of all of the work to fix it. Make sure you have documentation to back it up (come armed with evidence).

Approach Client
Only after you have a solid idea of what exactly is the cause of the error is, the extent of it, how you’re going to fix it and when you’re going to deliver the fixed version. Be prepared for some blowback. Especially if you're looking for the client to subsidize the fixes.

Perform Fixes
Resist the urge to rush the fix out the door again and get onto other projects. Imagine the egg on your face if your subsequent delivery has more errors, or hasn’t addressed the original errors properly.

After the fix is complete, perform another round of QA on all aspects of the project – even if you don’t think that the fix could have affected that aspect of it. This is for two reasons.

1. If it’s software- the code could impact it.
2. You might find other errors the client didn’t see yet.

Take Away
After the fix is complete and delivered, look at the errors in your QA that allowed this to happen. It not only is prohibitive from a cost perspective to perform fixes after client delivery - more importantly it is detrimental to your professionalism and makes you look like monkeys.

If the error was objective or intention based- look at your documentation process. Maybe your process needs to include another set of documents such as use cases.

Conclusion
No one is above error. Solid processes can help save the day and keep the errors from happening, but a strong and effective reaction will help get your team out of the dog house in the eyes of management, and the client.

Special Thanks to John Murray who was mysteriously unreachable last Wednesday and seriously hung over on Thursday.