From City Pilot to Procurement: Making Innovation Last

A city pilot has an unusually forgiving environment. A small group is paying attention. The supplier’s best people are available. Someone can repair a broken data feed by hand. An executive sponsor can get a department on the phone.

That environment can reveal whether an idea has promise. It can also conceal the conditions that will decide whether it survives. The important question is not simply whether the product worked during the demonstration. It is whether the city can responsibly make it part of an ordinary working day.

This guide offers a way to organize that decision. It is an editorial framework, not a substitute for a city’s procurement requirements.

Start with the service, not the demonstration

Write the problem as something a person or service team experiences. “Install a sensor platform” is an activity. “Identify equipment failures before a public building closes unexpectedly” is a service problem.

The distinction changes the test. A working sensor is not enough: someone must receive the alert, distinguish a real issue from noise, and have authority and resources to respond. The test should include that chain.

The GOV.UK Service Standard treats solving a whole user problem and providing a joined-up experience as part of service quality. For a city pilot, that suggests a useful boundary: follow the problem through to a completed action, even if several teams are involved.

Record the present process before changing it. Who does the work? How long does it take? Which cases fail? What resources are consumed? An honest, imperfect baseline is more useful than an impressive result with nothing credible to compare it against.

Make a one-page pilot agreement

A useful agreement is short enough for the operating team to use. It should identify the service owner, the supplier’s responsibilities, the test population, the decision date, and the evidence required for a decision.

Not every measure needs to be numerical. A well-documented failure to resolve an accessibility barrier can be more decisive than a high average satisfaction score.

Avoid a single blended “success score.” A system can be popular and still fail a security requirement. It can save processing time while shifting difficult work onto residents.

Test the conditions that scale badly

A small trial often concentrates on normal cases. Operational problems frequently live at the edges: a missing identifier, a damaged device, a resident without a smartphone, or a member of staff who is absent for a week.

Deliberately include those cases. Ask the supplier to show the data export rather than promising that one exists. Ask an ordinary team member to complete the recovery procedure. Follow a request that reaches the wrong department.

For urban sensor projects, a valuable test might be replacing a failed device and reconnecting its history. For an online application, it might be helping someone resume after an interrupted session. The test should examine the service’s ability to absorb friction.

Keep a record of exceptional support. If the supplier personally fixes every failed import during the trial, count that time. A pilot that depends on extraordinary help has identified a requirement, not necessarily a repeatable saving.

Build a complete cost picture

The pilot price is usually a poor estimate of the operating cost. Include implementation, integration, migration, training, accessibility work, security review, support, connectivity, equipment replacement, and eventual exit.

Separate costs the supplier invoices from work the city absorbs. A low subscription price can coexist with a large administrative burden.

For an illustrative comparison, suppose one option has a lower license fee but requires a weekly manual export. Another includes the integration but has a higher fixed fee. The relevant comparison is not the two invoices. It is the total work and service risk over the intended period. Local teams must supply the actual figures; the example does not establish which option is cheaper.

The Digital Services Playbook connects accountable ownership, delivery, and contracting. Its practical implication here is to give one person responsibility for the whole service decision while drawing on specialists for the parts they understand.

Keep competition and continuation distinct

A successful test should create evidence. It should not quietly create an entitlement to a long-term contract.

Bring procurement staff into the planning stage so the test can fit an appropriate local route. Establish what information may be shared with future bidders, how requirements will be stated, and how the city will avoid depending on undocumented supplier knowledge.

State the need in terms of outcomes and necessary constraints. A requirement written around a pilot supplier’s proprietary workflow may unnecessarily narrow future options. Conversely, a vague request for “innovation” gives bidders little basis for a comparable proposal.

The original FastFWD program is relevant because it explicitly examined the relationship between startups, government, and buying services. By 2015, Philadelphia was seeking a toolkit drawn from participating companies’ and city staff’s experiences. The city’s own document shows that the learning problem extended beyond selecting promising firms.

Decide among three credible endings

The final review should allow the team to stop, revise, or proceed. Treat all three as legitimate outcomes.

Stop when the benefit is too small, the burden too large, or a critical constraint unresolved. Record the reason so the next team does not repeat the same test.

Revise when a specific uncertainty can be resolved through a bounded additional test. Define the new question and an end date. An indefinite extension is not an evaluation strategy.

Proceed when the evidence supports the next step and the operating conditions are ready. The decision should name a service owner, a funding route, support responsibilities, security obligations, and a realistic transition schedule.

Even at that point, continue measuring. The operating service may encounter users, volumes, or constraints that the trial did not represent.

Leave something useful behind

A pilot should leave behind a decision record, a baseline, usable data, an explanation of failures, and a description of the work needed to continue. Those are valuable even when the product is not adopted.

Think of the handover as a small operating manual: what the service does, who depends on it, what can go wrong, how to get help, and how to stop using it without losing the public record.

That last question connects procurement to cybersecurity and continuity. A city is not buying only the successful moment shown in a demonstration. It is accepting responsibility for everything that happens afterward.