From Pilot to City Contract: Why Successful Tests Fail to Scale

The most common reason is not technical failure but the absence of a funded, governed path from pilot to contract, often called the valley of death. Pilot and grant money pays for a bounded test, so financing ends just as the product becomes mature, while procurement is governed by separate tender rules, budget cycles, and documentation duties. Fragmented security expectations across departments and jurisdictions compound this. The fix is to define the scale-up gate, name one accountable owner, secure the post-pilot budget line, and align security, IT, and procurement on shared requirements before the pilot begins.

Run an extended pilot across two or three genuinely different sites whenever you must validate integration, compatibility, and behavior in varied conditions before committing citywide funds. A single-site pilot hides interoperability problems with existing infrastructure that only emerge across heterogeneous environments. The extended pilot also lets you test accuracy on diverse data, observe operator workload under realistic false-alert rates, and begin moving the system from monitoring into response. Only a successful extended pilot followed by a limited deployment justifies the full rollout and the framework contract.

Use a total cost of ownership model built from capital costs for licenses, hardware, and integration plus operating costs for support, model retraining, and staff, then layer in multi-year price escalators and a contingency. Model the return by estimating the loss the solution avoids over a defined period rather than relying on vendor claims. Demand all-in year-one pricing that includes implementation, training, and support, and require the budget authority to approve the multi-year figure before the pilot closes so the contract does not stall in the valley of death.

Recognized security baselines and early-stage validation programs let agencies assess a provider's security posture before full authorization is complete, so capable smaller vendors can begin work sooner while completing certification. Procurement should also accept modular, standards-compliant solutions and shared framework vehicles that reduce the cost of entry for smaller firms. The bar stays intact as long as security requirements are embedded in the contract language itself, matched to data sensitivity and risk, and are enforceable, rather than expressed only as aspirations in marketing material.

Protect the city with clauses covering data export rights and full data return, audit and logging access, records retention matched to the municipal schedule, all-in and multi-year pricing with escalators, defined service levels and response times, a model-retraining and degradation plan, and a clear exit path with knowledge transfer so the city is not locked into one integrator. Include security requirements written into the terms and conditions themselves so they are enforceable, and reserve the right to re-bid or switch suppliers if measured performance degrades.

A single accountable owner should hold the decision, but it must be an informed owner. That person sits where security, IT, and procurement meet, because scaling fails when these three operate in silos. In practice this is often a senior program or security lead who can convene the chief information security officer, the IT operations owner, and the procurement officer, confirm the budget line exists, and enforce the scale decision gates. The decision should be evidence-based, driven by the scale-readiness checklist, and reversible if stop conditions remain open.