Root cause analysis: getting past the first plausible answer
Root cause analysis works out why something went wrong deeply enough that fixing it prevents a recurrence. Its main difficulty is stopping too early, at an answer that sounds satisfying.
An executive summary is not an introduction and not an abstract. It is the whole argument compressed to a page, written for someone who may never read the rest.
An executive summary is a self-contained account of a longer document, written so that a decision can be made from it alone. That last clause is the whole definition. If a reader has to turn to page fourteen to understand what you are asking for, the summary has failed at the only job it has.
It appears at the front of business plans, proposals, reports and business cases, and it is almost always written badly — because most people write it first, as a warm-up, when it is the one section that can only honestly be written last.
The test is simple and unforgiving: hand somebody the summary alone and ask them what you want and why. If they can answer both, it works. If they say "it seems to be about the new warehouse", it does not.
The order matters more than the content, because readers of executive summaries stop early. Put the answer at the top and the reasoning underneath, which is the reverse of how you thought about the problem and the reverse of how the full document is structured.
Writing the executive summary last is not a scheduling preference. Until the analysis is done, you do not know what the conclusion is, and a summary written in advance quietly turns into the thing the rest of the document has to justify. Several bad business cases have that exact origin.
When the document is finished, write the summary from scratch rather than by pasting sentences out of the body. Pasted summaries read as disjointed because each sentence was written to follow a different sentence. Start with a blank page and answer the question: what does this say?
A page is the working limit. The constraint is what makes the summary useful; anything longer stops being a summary and starts being a shorter version of the document, which nobody asked for.
Include numbers, but few of them. Three figures a reader remembers beat twelve they skim: the cost, the return, the timeframe. Anything else belongs in the body where it can be presented properly with its assumptions.
The same underlying document needs different summaries depending on who is deciding. A board wants the financial exposure and the risk. A prospective client wants to know what they get, by when, and what it costs them. An investor wants the market, the traction and the ask. The body can stay the same in all three cases; the summary should not.
If you write proposals or reports regularly, keeping the structure in a document you copy each time saves the fifteen minutes usually spent rediscovering the order. Ettex Docs holds that as a normal document you duplicate and edit, and comments let a colleague push back on the recommendation before it goes out — which is when that feedback is worth having.
It will not write it for you, and that is deliberate rather than a limitation we are apologising for: the whole value of an executive summary is that a person decided what mattered enough to go on the page. A generated one reads like a generated one, and the reader you are writing for notices.
A short, self-contained version of a longer document that states its conclusion and the reasons for it, written so that a decision can be made from it alone.
One page for most documents. Two if the full document runs to fifty pages or more.
Last. Written first, it becomes a conclusion the rest of the document has to defend.
An introduction sets up the reading. A summary replaces it — it has to work for someone who reads nothing else.
Yes, briefly, with how each is handled. Omitting them is more damaging to credibility than naming them.
Rarely. The body can stay fixed while the summary is rewritten for what that particular reader has to decide.
Write the executive summary last, put the answer in the first two paragraphs, keep it to a page, and finish with the decision you want. Then test it by handing it to someone who has read nothing else.
Root cause analysis works out why something went wrong deeply enough that fixing it prevents a recurrence. Its main difficulty is stopping too early, at an answer that sounds satisfying.
A code of conduct says how people here are expected to behave and what happens when they do not. Its value is not aspiration — it is having decided the hard cases before one arrives.
A project charter names the objective, the boundaries, the sponsor and the person authorised to run the work. Its main use comes months later, when people disagree about what was agreed.