Ps Decision Readiness And Public Communication

Decision-Readiness and Public-Sector Communication for AI Proposals

Purpose

A well-argued AI business case can still fail to get a decision — not because it's wrong, but because it wasn't built to be decided on by a public body. Public-sector decision-making has structural features a private-sector pitch doesn't have to account for: multiple stakeholder interests that all need to be visibly balanced, a public accountability and transparency bar, and decisions made under scrutiny that will outlast the meeting they were made in. This skill gives a six-element model for building decision-readiness into the proposal itself, adapted specifically for AI initiatives (which carry extra unfamiliarity and trust burden compared to a routine infrastructure or service proposal).

Anchored in

Adapted from the owner's own public-sector commercialisation methodology (a six-element decision-readiness model originally built for general post-pilot exploitation decisions) — see ../../references/source-notes.md for exactly what was kept, generalized, and left out. Applied here specifically to AI proposals, which the source material does not cover.

Method

Work through all six elements before the proposal goes to the decision body — a proposal missing even one tends to stall, not fail outright, which is often worse (it sits in limbo rather than getting a clear no you can act on).

1. Provide real options, not one recommendation dressed as three

Public decision-makers need to visibly choose between genuine alternatives, not rubber-stamp a foregone conclusion — both because it's better decision-making and because a visible choice is more defensible afterward. For an AI proposal, this usually means presenting at minimum: do nothing / a smaller or manual-first alternative / the proposed AI solution — each with a real cost, risk, and impact comparison, not a strawman "do nothing" option built to lose.

2. Provide relevancy and focus — resist the urge to show all your work

A team that did five months of AI opportunity scoring, technical scoping, and vendor comparison wants to show it. A decision-maker needs the two or three facts that actually drive the choice, in a form they can scan in the room. Lead with an executive-summary-level view; put the scoring detail, technical architecture, and vendor comparison behind it for those who want to go deeper.

3. Create trust — AI proposals start from a trust deficit

Because AI is newer and less well understood than most infrastructure decisions a public board reviews, assume extra skepticism by default, and address it directly rather than assuming competence will speak for itself:

• Publish the methodology and data sources behind any claim, not just the conclusion.
• Where possible, include independent review, a pilot result, or a comparable case from another public body — a first-of-its-kind claim is a harder sell than "this worked elsewhere and here's the evidence."
• Build in a visible feedback or complaint channel for the AI system itself, not just for the project.

4. Create urgency, tied to the actual public-sector clock

Generic urgency ("the market is moving fast") lands weakly with a public decision-maker. Tie urgency to what actually moves this audience: a budget-cycle deadline, an expiring funding window, a service-quality problem citizens are already raising, or a compliance deadline. State it as a real, checkable fact, not a rhetorical push.

5. Align explicitly with strategy and policy

Show the connection between this AI proposal and the organization's existing strategic plan or policy goals in the proposal itself — don't assume the decision-maker will make that connection unprompted. If no clean connection exists, that's worth knowing before the meeting, not during it (see ps-ai-opportunity-screening-for-public-value step 1 on mandate).

6. Design for how public-sector decisions actually get made

Unlike a single-sponsor private decision, a public decision typically needs to survive scrutiny from multiple, sometimes conflicting, stakeholder interests simultaneously (see ps-stakeholder-and-political-landscape-mapping), needs to be defensible on the record after the fact (assume it may be FOI-requested, audited, or publicly reported on), and often needs staged approval rather than one up-or-down vote (a smaller pilot approval now, a scale decision later). Structure the ask accordingly — often the right ask is narrower and more staged than the team's full ambition, precisely because that's what actually gets a yes.

Choosing the right format

Match the artefact to the audience and moment, not by default:

• A short, high-level summary for a body that needs to decide quickly or is seeing this for the first time.
• A visual, narrative-driven version for building broader buy-in or public communication.
• A structured formal document when the decision needs to be recorded and defensible on paper (see ps-procurement-and-public-funding-navigation step 3 on documentation burden).
• The fullest, most detailed version only for the working team and technical reviewers, not the decision body itself.

What this skill does NOT do

• Doesn't write the underlying business case — see ps-public-value-business-case-framing and ../../../../business-case-and-analysis/skills/business-case-builder/SKILL.md.
• Doesn't replace stakeholder mapping — do that first with ps-stakeholder-and-political-landscape-mapping so element 6 has real input to work with.
• Doesn't guarantee approval — a well-built proposal can still get a legitimate no; this skill improves the odds of getting a clear, timely decision either way, not a specific outcome.

Refinement notes

The six elements are a direct generalization of the owner's own practitioner framework — not synthesized from public literature the way some of this pack's other skills are (see ps-ai-opportunity-screening-for-public-value's Refinement notes for the contrast). If the owner has more example language or case outcomes from real engagements, they belong here as the next refinement layer.

Continue from here

• Business case to present: ../ps-public-value-business-case-framing/SKILL.md
• Stakeholder input for element 6: ../ps-stakeholder-and-political-landscape-mapping/SKILL.md
• General business-case builder: ../../../../business-case-and-analysis/skills/business-case-builder/SKILL.md
• Storytelling craft for the pitch itself: ../../../../prototyping-and-demonstration/skills/opportunity-visioning-with-pr-faq/SKILL.md

References

• ../../references/source-notes.md — full detail on what was adapted from the source and what was left out.

Reminder: frontmatter has only name and description. Everything else goes into skills_index.json (run scripts/generate_index.py).