A six-element model for presenting an AI proposal so a public decision body (council, board, steering group) can actually approve it: options, relevancy and focus, trust, urgency, strategic alignment, and public-sector decision dynamics. Use when preparing to bring an AI initiative to a public decision-maker for a go/no-go or funding decision.
Installs into .claude/skills of the current project.
Are you the author of Ps Decision Readiness And Public Communication?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/pilot2service-ps-decision-readiness-and-public-communication)
---
name: ps-decision-readiness-and-public-communication
description: "A six-element model for presenting an AI proposal so a public decision body (council, board, steering group) can actually approve it: options, relevancy and focus, trust, urgency, strategic alignment, and public-sector decision dynamics. Use when preparing to bring an AI initiative to a public decision-maker for a go/no-go or funding decision."
---
# 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`).