An engineer's technical proposal is repeatedly sent back for more detail and still not approved. What is usually wrong with its structure?
Show the full answer Hide the answer
What is usually wrong
It describes a solution before establishing the problem, so reviewers spend the discussion re-deriving what question is being answered — and each of them derives a different one.
The second failure: no explicit decision being requested. A document that ends without naming what the reader must approve produces discussion rather than a decision, and it will be discussed again next week.
The structure that gets decided
- The problem, with evidence. What is broken or missing, measured. Two paragraphs.
- What decision is being requested, stated near the top rather than at the end. Reviewers read the top.
- The constraints, so that reviewers do not propose options that were never available.
- Options with genuine trade-offs, including "do nothing" and including the one you did not pick.
- The recommendation with its reasoning, and what would change it.
- Cost, risk and what happens if it is wrong.
- Detail in appendices, so the main document is readable in ten minutes.
Why it keeps being sent back
Frequently because the reviewers are not aligned on the problem, and asking for more detail is what people do when they are uncomfortable and cannot say why. More detail does not fix it; agreeing the problem does.
The practical move is a short pre-read conversation with the two or three people whose objection would block it, before the document is circulated. Most review comments are surfaced there, and the document arrives having already absorbed them.
The property that distinguishes a proposal that lands
It is honest about the weaknesses of the recommendation. A document that presents one option with only benefits reads as advocacy, and reviewers respond by hunting for the omitted downside. Naming it first removes that dynamic and is more persuasive, not less.