A smart city pilot rarely fails because the technology didn't work. It fails because nobody wrote down what "worked" was supposed to mean, the data sat on a vendor's server, and the only person who understood the dashboard moved to another job in March. The sensors are usually the easy part. The decisions wrapped around them determine whether a six-month trial becomes something residents notice, or a press release and a box of unused hardware.

This checklist is for the people who have to make it happen: a sustainability coordinator, an IT director, a city manager with a small team and no spare hours. Fifteen points, grouped in the order you'll face them.

Define the problem before you define the project

Technology should be the last thing you choose, not the first. Start with a problem your staff already argue about.

1. Write the problem in a sentence a resident would recognize. "Buses on Route 12 run more than ten minutes late on weekday afternoons" is a problem. "Improve transit efficiency through data-driven innovation" is a slogan.
2. Draw a hard boundary. One corridor, one building, one permit process, one season. Pilots that try to cover the whole city at once produce thin results everywhere and nothing convincing anywhere.
3. Collect the baseline before you install anything. Two to four weeks of manual counts, complaint logs, or existing records will define what "better" means later. Without a baseline you cannot prove anything, and you'll end up arguing about impressions.

Buy outcomes, not products

Most pilot trouble starts in the procurement documents, long before anyone plugs something in.

1. Describe the result, not the device. "Cut idling at the depot by identifying the worst fifteen minutes of each shift" leaves room for a scheduling fix, a sensor, or both. Specify the hardware and you've already closed off cheaper answers.
2. Settle data ownership and exit terms before price. Ask who owns the data, what format you receive it in, how often, and what happens on day one after the contract ends. If the answer is "we'll export it for you," get the format and the cost in writing.
3. Stage the contract with off-ramps. Payment tied to milestones, a short initial term, an option to extend. A pilot you can't leave isn't a pilot. Purchasing rules differ by jurisdiction, so bring procurement and legal staff in early rather than at signature.

Treat privacy and security as design work

Privacy is not a document you attach at the end. It is a set of choices about what you collect, where it sits, and who can see it — and those choices get harder to reverse once hardware is on a pole.

1. Build a data inventory. For each item collected: what it is, why you need it, where it's stored, who has access, and when it gets deleted. One page is enough. If a field has no answer for "why," drop it.
2. Minimize at the source. A sensor that counts vehicles is easier to defend than a camera that reads plates, and it answers most traffic questions just as well. Prefer aggregates over identities, and short retention over indefinite storage.
3. Publish a plain-language notice and a way to ask questions. A short web page and a working email address build more trust than a legal annex nobody reads. Privacy and records law varies by country, state, and province; run the plan past your legal counsel or records officer before collection starts.

Questions worth asking before any sensor goes up

• What is the least data that answers this question?
• Who inside the organization can see the raw feed, and is that access logged?
• What is the retention period, and who actually deletes the data?
• If a resident asks what we know about them, can we answer within a few days?

Staff the pilot like an operation

Vendors deliver software. Your staff delivers the pilot. Budget their time explicitly, or the work quietly lands on whoever is already busiest.

1. Name one accountable owner. A single person with authority to make small calls, not a steering committee that meets monthly. Committees can advise; someone has to decide.
2. Estimate internal hours and protect them. Assume IT, communications, legal, and the frontline crew each need a few hours every week for setup, questions, and fixes. Frontline staff often spot problems the dashboard never shows, so give them a seat from week one.
3. Train the people who inherit it. If the pilot works, it becomes someone's daily job. Write a short runbook: how to restart it, who to call, what the alerts mean. A pilot only its creator can operate isn't finished.

Evaluate on a date you set in advance

Set the review date at launch and put it in the calendar with the people who can say no.

1. Compare against the baseline, and check who benefited. An average improvement can hide a neighborhood that got nothing. Break results down by area, time of day, or user group where you can.
2. Report publicly in plain language, including what didn't work. A short summary — what you tried, what changed, what it cost, what you'd do differently — is more credible than a polished success story. Failures shared honestly make the next pilot easier to fund.
3. Decide: scale, adjust, or stop. Write down all three options and their rough costs before the review. If the answer is stop, decommission deliberately: remove hardware, archive or delete data per your retention rules, and tell residents what happened.

Keeping the checklist useful

Print it. Run through it at three moments: before you write the problem statement, before the contract is signed, and one week before the review. Fifteen minutes each time, with the owner and one skeptic in the room.

Two habits carry more weight than any tool. Keep a one-page log of decisions — what you chose, what you rejected, and why — so the reasoning survives staff turnover. And keep a resident's question in the room: if a neighbor asked what this pilot does for them, could you answer in a sentence? If not, that's the next thing to fix.

Photo: RDNE Stock project / Pexels