Decision-Forcing Proposal

Proposals get deferred not because they are wrong but because deferral appears free. A document describing a good idea invites "interesting, let us discuss further" indefinitely. A document presenting options with consequences, a recommendation, and a stated cost of delay forces someone either to choose or to explicitly decline — both of which are outcomes.

The structure

1. The decision required, in the first two sentences. What you need, from whom, by when.
2. The problem, quantified. Not "the system is difficult" but the cost per quarter — incident time, change lead time multiplied by change volume, specific features refused. An unquantified problem loses to a quantified alternative every time.
3. Options, including doing nothing, each with cost, risk, timeline and what it gives up. The do-nothing option must carry its cost, because that is what makes deferral visibly expensive.
4. A recommendation with the reasoning visible. A proposal without one pushes the analysis onto the reader, who will defer rather than do it.
5. What happens if the decision is delayed — an option expiring, a risk growing, a migration getting more expensive as the dataset grows. Time sensitivity converts "we should" into "we should now".
6. What you are not proposing, bounding the discussion and preventing the scope expansion that kills proposals.

Implementation patterns

• One page for the decision, detail in an appendix. A proposal requiring forty minutes of reading before the decision is visible will not be read by anyone with authority to make it.
• Identify the decision-maker explicitly. Ambiguity about whose call it is guarantees deferral.
• Circulate in advance with a comment deadline, so the meeting resolves disagreement rather than establishing context.
• Talk to the objectors first. This is the highest-value preparation and the most often skipped.

Industry example

Long-running platform and modernisation investments live or die on this. The technically strongest proposals are frequently the ones that stall, because they are argued on technical virtue and ask for a large commitment before any return.

The versions that get decided pair a quantified cost of inaction with an incremental delivery plan — a first slice returning something measurable — and an explicit non-goals section, because such programmes attract every deferred wish and become unfundable once they must deliver everything before delivering anything.

The pre-meeting work matters more than the document. Most deferral is not disagreement with the proposal; it is discomfort with deciding in front of unresolved questions, and those questions are discoverable and answerable beforehand.

Failure scenarios

• Asking for agreement rather than a decision, which can always be postponed.
• No stated cost of delay, so deferral is the risk-free option.
• Too long, so it is skimmed and postponed.
• No named decision-maker, so everyone assumes someone else will decide.
• Unaddressed objections arriving live, which converts a decision meeting into an exploration.
• A recommendation withheld in the name of neutrality, which is abdication and produces deferral.

Trade-offs

Forcing a decision risks getting a "no", where an open-ended proposal preserves the hope of eventual agreement. That hope is usually false, and an explicit no is more useful than indefinite ambiguity — it frees the effort and reveals what would need to change.

The structure also takes real preparation: quantifying the problem, costing the options, and pre-socialising with objectors. For a small decision that overhead is not justified, and a conversation is better.

Interview question

"Your proposal has been deferred at three consecutive forums with no objection stated. What do you change about the document, and what do you do before the next meeting?"