3

In production, there was an issue which impacted many customers. The issue was resolved in an hour but the damage was already done. Recovery is in progress. We need to explain this situation to Senior management.

What details are mandatory when reporting a "customer impacted" issue? What should we be presenting or emailing to senior management?

  • This question seems to lack sufficient background or context to be answerable in a targeted way. In other words, it's too broad. Please improve the question by making it more specific. – Todd A. Jacobs Jul 27 '13 at 16:01
  • 1
    Added few more details. Hope it helps. – Sreedhar Nadadur Jul 27 '13 at 16:44
7

The message should be as factual and emotion-free as possible:

  1. Indicate the issue in a precise, straight forward, and simple way;
  2. Describe how the customer will be impacted;
  3. Indicate the the likelihood and degree of impact;
  4. Detail the cause(s) of the issue;
  5. If the issue was predicted in your risk program, outline what you did to try to mitigate it;
  6. Describe three or four alternate solutions to resolve both the issue as well as the impact to the customer; and
  7. Recommend which alternate path you think is best by way of benefit, cost, and risks.

You need to push for decision so you need to put dates on the next steps as you drive consensus. In other words, schedule the next event for continued discussion.

  • 2
    David Espina's answer is excellent. The only thing I will like to add to the root cause analysis are the steps that The team/I will be taking to prevent similar issues in the future. – the_reluctant_tester Jul 27 '13 at 22:59
  • 3
    Great points by David. Executives are going to want to know simple facts, how many customers were impacted and are you able to identify which customers so they can communicate with them. Next, is was this a once off and if not what is needed to mitigate this in the future. Remember it is not your risk, but you need to give the facts so they can make the right decisions. – Brett Maytom PST Jul 27 '13 at 23:02
  • To add another thought to this answer (+1 for answer & comments), I would recommend to merge this into your "issue resolution process" (if you have any), with a fixed communication plan depending upon the severity of the problem. – Stephan Jul 29 '13 at 13:28
  • Thank you David, Brett and Stephan for your answers on this. It is helpful. – Sreedhar Nadadur Jul 29 '13 at 16:31
0

TL;DR

We need to explain this to Senior management. My question is what details you will present to them?

It's unclear who is demanding an explanation, and whether it's actually a technical explanation that's needed or political covering fire. If the former, the expectations for the response should have been clearly communicated to you and your team. If the latter, then the content of the response really doesn't matter all that much since actual knowledge-transfer isn't the point.

POA&Ms, Root Cause Analyses, and Other Remediation Artifacts

If senior management is asking for a technical explanation, they should have told you what they want to know. If they did, use that as your guideline. If not, you should probably ask them what it is that they want to know, rather than trying to guess.

In general, large projects already have organizationally-defined formats for reporting significant issues, in-progress hot-fix status updates, or formal root-cause analyses. For example, many government projects use the Plan of Actions and Milestones (POA&M) format, while other projects may simply need to report what went wrong and what the expected time-line is for mitigation. Again, if these sorts of reporting requirements aren't already baked into your project and weren't made clear in the request for information, then you should ask senior management what's needed.

The Blame Game

If, on the other hand, the real question is "Whose fault is this?" or "Who's going to take the blame for this?" then the technical content of your response is irrelevant. If you choose to play the Blame Game (which I don't recommend), then you will need transfer responsibility elsewhere.

Even if senior management wants to play the Blame Game, I wouldn't go down that road. The professional goal of a project manager is to provide senior management with visibility into a project in order to foster strategic decision-making. Sweeping things under the rug, passing the buck, and other political flim-flammery might keep your job or your department's budget off the chopping block, but it is neither ethical or constructive.

On the other hand, any organization that prefers to "hold people accountable" rather than to learn from mistakes has doubtless made other bad decisions in the past. This may include unwisely cutting project budgets, staffing resources, or quality assurance checks. If your root-cause analysis shows that past project decisions were involved in causing the problem, it is important that these issues be made visible as part of any corrective action plan, or similar problems are likely to recur in the future.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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