Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Our client asked for the root cause of a bug after we delivered our fix. Should I explain it to her? For example, should I say that the bug arose from a wrong condition check or from bad configuration of memory?
What is the best way to provide her this information?
In situations like this two important rules are in conflict:
Based on my experience, clients appreciate the outcome of the first rule, so if you are honest and tell them about the background of the issues, they'll most probably understand them (of course, there are client, who will try to use the nature of the issue at contract negotiations).
It is important to communicate the issues properly. A businessman won't understand race conditions, memory leaks, and other fancy geek terminology. You can cover these as a minor/major programming issues (this is the case where you have to keep the second rule in mind).
When you talk about the issues, show confidence and be honest. Don't forget to consult your team before talking to the client, and if you cannot answer a question right there, don't try to figure something out. Tell her, that you need more time, but you'll come back to her soon with the answers.
Actually, there are cases, when knowing more about the background of the issues can actually help your customer and you. What if your product is part of a bigger application, and a problem in your part is actually not your fault? What if you discover a use case nobody really thought about before? Be cooperative, but as soon as the conversation turns to a "blaming event", you must stop and rethink your position (ask for more time for a more thorough investigation).
I support Zsolt approach, adding one suggestion when planning the way to deliver this information to the users:
Before the fix:
After the fix:
This way, you'll accomplish two things at once: - Demonstrate to your client you (as a team) knows when something went wrong (transparency is fundamental!) - Demonstrate you're ready, you learned the lesson and the same mistake won't happen in the future.
I dare to say that the second part is more important than the first. When a user asks for a root cause, he's asserting if there's any potential similar issue in the near future.
A last comment: Avoid, with all your efforts, to explain the root cause technically. Explain it in a way your grandmother could understand. And this explanation must be in one paragraph. No more than two, otherwise the user will feel frustrated by don't understanding what you meant.
If you're running an agile shop, transparency should be a key objective. Even in more traditional PM approaches, it's usually a bad idea to sweep issues under the rug. Invisible issues can't be managed by stakeholders or the project management process, so one should always strive for transparency.
From a customer point of view, knowing that a bug was caused by an integer overflow or an unexpected nil value is rather useless information. If they want that information, fine, but I prefer to use the opportunity to address the underlying meta-questions. These generally boil down to:
Bugs are inevitable in any software system. However, in my personal experience, severe bugs are usually process failures caused by unrealistic deadlines, budget limitations, or unclear (possibly even undocumented) requirements. Root-cause analysis is a great opportunity to address those sorts of issues in a constructive way.
If you are building a house and all of a sudden a wall comes down, would you like to know the root cause of the problem or not?
Edit: Sorry if it was not clear, but what I mean is, explain it to them how you'd like to have it explained to you if such a thing happened with you, i.e. wear the client hat and think, what would you like to hear in this case? My advice is, always tell them the truth, is the best way to guarantee that they will ever come back.
Yes, and be honest. If you screwed up, just tell the client (not in that way, but tell them)
If you are honest and tell the client what went wrong, what you did wrong, or did not do, the client will appreciate it.
Show the client that you learned from it and will do better next time and how you are going to do it next time to not make the same fault again.
Trust me, always keep the client informed. In good times and bad times!
