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?
The message should be as factual and emotion-free as possible:
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.
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.
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.
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.
