Starting innovation in a government entity: the first 90 days

In a government entity, the first 90 days should secure a written mandate, deliver one visible improvement to a real service, and leave behind the evidence and routines that let the work continue after the first champion moves on. Spend the first month on mandate and problem choice, the second on understanding and testing, the third on deciding, documenting and planning the next round. Do not start by building a lab, a strategy document or an ideas portal.

The 30-day loop in Where to start with innovation in your team still sits at the centre. Government simply needs more around it: clearer authority, more careful handling of risk, and records that will satisfy auditors, assessors and a future leadership team.

Why government needs a different start

Public bodies are not less able to innovate, but they work under particular conditions. Decisions pass through approval chains. Spending follows procurement rules. Plans are set annually. Failure can be public. Staff move between entities, so knowledge leaves with people. And many entities are, or will be, measured on innovation by national programmes or international standards such as ISO 56001:2024, the first certifiable requirements standard for an innovation management system.

The OECD's Observatory of Public Sector Innovation describes four facets of public sector innovation: enhancement, mission-oriented, adaptive and anticipatory. In the first 90 days, aim squarely at enhancement: improving a service people already use. It is the facet where results are visible within a quarter, and visible results are what earn the mandate for the other three.

Before day one: what to prepare

• A sponsor at deputy level or above who will sign the mandate and attend three short checkpoints (end of each month).
• A shortlist of three candidate problems, drawn from complaints, service data or frontline staff, each about a service the entity itself controls.
• A view of the rules. One conversation with procurement, legal and IT about what a small test may and may not do without formal approval. Most entities allow more than people assume, as long as no money is spent and no data leaves its system.
• Calendars. A core team of four to six people with one day a week protected, in writing, for twelve weeks.

Month 1 (days 1–30): mandate and problem

Week 1: the mandate. Write a one-page mandate the sponsor signs. It states the problem area, the team, the time given, what the team may test without further approval, and that day 90 ends in a recommendation, not a launch. Use a RACI to name who decides, who is consulted and who is informed. A signed page protects the team when priorities shift in week six.

Week 2: the landscape. Draw a stakeholder map for each of the three candidate problems: beneficiaries, frontline staff, other departments, other entities, regulators. Note who could block a change.

Week 3: choose one problem. Score the three candidates with the sponsor using a weighted decision matrix on criteria agreed in advance: how much beneficiaries feel it, whether the entity controls the fix, whether a test is possible within the rules, and how visible an improvement would be. Pick one.

Week 4: prepare to listen. Book eight to ten conversations with beneficiaries and frontline staff, and plan a service safari: team members use the service themselves, as a citizen would.

Comes out: signed mandate, RACI, chosen problem with reasons, research plan. Checkpoint 1 with the sponsor: 30 minutes.

Month 2 (days 31–60): understand and test

Weeks 5–6: research. Run stakeholder interviews and the service safari. Interview frontline staff as well as beneficiaries; they know where the workarounds are. Build an experience map of the service as it actually works, not as the procedure manual describes it.

Week 7: frame and generate. Write two or three how might we questions from the map. Run brainwriting so ideas are written before anyone senior speaks. Choose two ideas that fit inside the mandate's test rules.

Week 8: test. Make paper prototypes: a revised form, a new notification text, a changed counter script. Test with five or more beneficiaries. Keep the test small, reversible and within one branch or channel.

Comes out: research notes, experience map, two tested ideas with results. Checkpoint 2 with the sponsor: show what you saw, not slides about it.

Month 3 (days 61–90): decide, record, continue

Week 9: stress-test. Run a premortem on the stronger idea: imagine it has failed a year from now and list why. In government, the answers usually include a missing system change, a policy owner not consulted, or a change that depended on one person.

Week 10: refine and plan the handover. Revise the idea, then name the operational owner who will run it if approved. A change the innovation team keeps running is not a handover. See From lab to operations: the handover nobody plans.

Week 11: build the record. Assemble one evidence file: the mandate, the problem selection with its criteria, research notes, the experience map, the tests and results, the decision, and who contributed what. This is what assessors and the next leadership team will ask for. Building it as you go costs little; rebuilding it later is painful.

Week 12: decide and communicate. A decision meeting with the sponsor: adopt, extend the test, or stop. Then a stakeholder communication plan so the departments involved hear the outcome from the team, not by rumour. Close with a retrospective and choose the next problem from the original shortlist.

Comes out: a decision, a named operational owner, an evidence file, and the next cycle's problem. Checkpoint 3: the sponsor confirms the next 90 days.

Do's and don'ts

Do

• Get the mandate signed before research starts.
• Choose a problem inside your entity's own control for the first cycle.
• Agree with procurement, legal and IT what a test may do, before you need it.
• Record who contributed what, as you go. Credit matters more where hierarchy is strong.
• Name the operational owner before the decision, not after.

Don't

• Start with a lab, a building or a branding exercise.
• Launch an organisation-wide ideas campaign in month one.
• Pick a cross-entity problem first. Save it for when you have a track record; see Ecosystem innovation.
• Present results only as slides. Show the forms, the quotes, the prototypes.
• Let the evidence wait until an assessment is announced.

Illustrative example

Illustrative: an invented organisation, for explanation only.

A national licensing agency in a European capital asks its new head of service improvement to "start innovation". She has no budget line and four willing colleagues.

In month one, the deputy director signs a one-page mandate allowing tests that change wording, forms and scripts in one regional office. Of three candidate problems, the matrix favours one: applicants for a professional licence are often rejected for missing documents and must start again.

In month two, the team interviews nine applicants and four case officers and applies for a licence themselves. The experience map shows the document list is correct but buried on page three of a guidance note. Brainwriting produces 35 ideas; two fit the mandate. They test a one-page checklist and a short confirmation message sent after submission, in one office, for two weeks. Applicants find the checklist useful; the message confuses some.

In month three, the premortem warns that the checklist will drift out of date when rules change. The team names the policy unit as owner, so updates happen with each rule change. The deputy director approves rollout of the checklist to all offices and a second cycle on the message. The evidence file goes to the agency's quality team.

Questions people ask

How do you start innovation in a government organisation? Secure a short written mandate from a senior sponsor, choose one service problem your entity controls, and run a 90-day cycle of research, small tests and a clear decision, while keeping a record of everything. Build structures such as labs only after you have results.

Do we need an innovation unit before we begin? No. A small cross-functional team with protected time and a signed mandate is enough for the first cycles. A unit makes sense once there is a flow of work to support. See "We need an innovation department first." Why you don't.

How do we prove innovation results to leadership and assessors? Keep one evidence file per cycle: the mandate, why the problem was chosen, what you heard, what you tested, what happened, what was decided and who contributed. Real artefacts are more convincing than summary figures.

Where to go next

The guides behind this plan are RACI, service safari, weighted decision matrix and premortem. Read the hub's starting point, Where to start with innovation in your team, and when you are ready for a dedicated space, How to set up an innovation lab in a government entity.