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?

5 Answers 5


In situations like this two important rules are in conflict:

  • don't lie to the client
  • don't look bad in the eye of the client

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).

  • 1
    > Don't forget to consult your team before talking to the client ============== absolutely! I remember so many cases when manager will "forget" to ask the team and (quite often) results were less than perfect
    – Steve V
    Nov 12, 2012 at 19:20

I support Zsolt approach, adding one suggestion when planning the way to deliver this information to the users:

Before the fix:

  • What caused (a misconfiguration on the application, a typo?)
  • Why it was caused (a last minute requirement change?)
  • why it wasn't noticed (lack of proper testing?)

After the fix:

  • Is there any potential similar problem somewhere else?
  • A full review has been done o ensure there's no other similar issue hidden?
  • What actions are taken to avoid them in the future?

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.


Transparency and Root-Cause Analysis

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.

Address Process; Don't Fix Blame

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:

  1. Was the bug preventable?
  2. Can we prevent similar bugs in the future?
  3. What levers does the customer or business have to improve process quality?

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.

  • 1
    Hi eMgz, I believe the community expects your answer to be more constructive. Besides, the side question What is the best way to provide her this information? hasn't been answered on your answer. I'd suggest you to review it to get rid of the downvotes.
    – Tiago Cardoso
    Nov 12, 2012 at 15:11
  • Thanks for pointing it Tiago, actually I should have just commented that. Anyway, I edited it and explained my analogy.
    – eMgz
    Nov 12, 2012 at 16:47
  • Much better now :)
    – Tiago Cardoso
    Nov 12, 2012 at 17:04
  • 3
    I like the original analogy. I, too, often cross walk our sort of abstract business scenarios with brick and mortar scenarios. +1. Nov 12, 2012 at 18:40
  • 1
    +1 I like the house analogy and am hoping that doesn't happen where I live. ;) Also, this fits in with the idea of explaining it in laymens terms. I'm not a carpenter, so just saying "the mold caused the wood to rot away and reduced structural integrity" would be good enough explanation for me.
    – jmort253
    Nov 14, 2012 at 3:18

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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.