Decisions about technology are usually made by people who do not use it: boards, trustees, partners, finance directors, committees. Whether a proposal succeeds depends largely on how it is presented to them.
This is a skill rather than a knack, and it is learnable.
Lead with the decision
The commonest failure is building up to the request through explanation. By the time the ask arrives, attention has gone.
Open with what you want decided, what it costs, and what happens if the answer is no. Everything after that is supporting material for the people who want it.
A useful opening shape: "I am asking for approval of £24,000 to replace the job management system. The current one is no longer supported, and if it fails we cannot schedule work. The alternative is to accept that risk for another year."
Three sentences, and the audience knows what they are deciding.
Talk about consequence, not mechanism
Non-technical decision-makers are not less intelligent; they are working with different information. What they can evaluate is consequence.
Not: "the server is running an operating system past its support date and has no patching path."
But: "if that machine is compromised or fails, we lose access to job records and cannot invoice until it is rebuilt, which would take about a week. There is no supplier who will support it."
The second version contains the same facts and is decidable.
Frame risk as likelihood and consequence
Technical risk language does not travel. Severity ratings and vulnerability scores mean nothing outside the field, and they cause people either to panic or to discount everything.
State it as a board would state any other risk: what could happen, how likely it is, what it would cost, and what would reduce it.
Be honest about uncertainty. "I cannot tell you the likelihood, but the consequence would be severe and the cost of preventing it is modest" is a legitimate and persuasive position.
Decision-makers are not avoiding your proposal because it is technical. They are avoiding it because they cannot evaluate it, and defer is the safe answer to anything unevaluable.
Answer the questions they will ask
Every non-technical decision-maker has the same five questions, whether or not they voice them. Answer them before they are asked.
What happens if we do nothing? The most important question and frequently unaddressed. If the answer is "nothing much for two years", say so — it is more credible than urgency you cannot substantiate.
What does it cost, in total? Not the purchase price. Implementation, training, ongoing licences, support, internal time. Presenting a partial figure that grows later destroys trust for every future proposal.
What could go wrong? Name the risks yourself. A proposal with no acknowledged risks reads as either naive or evasive.
Is there a cheaper option? Have considered it, and be able to say why it was not chosen. "We looked at doing nothing, at a partial fix, and at this" is a strong position.
Who is responsible? Named. Boards approve things people own.
On analogies
Useful sparingly, and dangerous when overextended.
A good analogy carries the specific point being made and no more. Backups as insurance is fine for the decision "should we pay for this". It breaks down immediately if extended, because insurance pays out and backups only restore what they captured.
The failure mode is that a broken analogy leads people to a confident wrong conclusion. Somebody who thinks they understand and does not is harder to correct than somebody who knows they do not.
Use one, make the point, and move on.
Structure for people who will not read it all
Assume the paper is read in the ten minutes before the meeting.
A short summary that stands alone: the decision, the cost, the recommendation, the consequence of not acting. Then the detail for those who want it. Then technical material in an appendix, present for credibility rather than for reading.
Anyone reading only the first paragraph should be able to vote sensibly.
Do not overclaim
Technology proposals are frequently oversold, and boards have learnt this. Modest, specific claims are more persuasive than transformational ones.
"This will save about six hours a week in the office and remove a category of invoicing error" is credible. "This will transform how we operate" invites scepticism and is usually unmeasurable afterwards.
Being right about a modest claim buys you credit for the next proposal. Overclaiming spends it.
Afterwards
Report back on whether the predicted benefit materialised, honestly, including where it did not.
Almost nobody does this, which is why technology proposals are viewed sceptically. A person who says "we projected six hours a week and it is running at four, here is why" is the person whose next proposal is believed.
Our consultancy team works with boards and management teams to put technology decisions in terms they can act on. Start a conversation.
