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.
Scanned 9/6/2026
Install to Claude Code
npx -y skills add Pilot2Service/AI-Business-Designer --skill ps-decision-readiness-and-public-communication --agent claude-codeInstalls 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 automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/pilot2service-ps-decision-readiness-and-public-communication)More formats (shields.io, HTML) on the badges page.
---
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`).
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!