Choose a problem residents can describe

A smart city initiative begins with a decision about what should improve in daily life and urban operations. Teams may suggest sensors, an app or a control room, but choosing technology before defining the problem makes alternatives difficult to compare. Ask who experiences the problem, where it recurs and what outcome they need. Improving transport is a broad ambition; reducing uncertainty for people waiting at one defined stop is a challenge that can be investigated. Starting from residents’ needs is consistent with the U4SSC people-centred approach, without making the proposed comparison method an official standard. [2] Seek a starting point that supports learning, followed by an evidence based expansion decision.

Use evidence beyond complaint volume

Build a short challenge list with evidence for each candidate. Possible inputs include service requests, site visits, operational records and user interviews, with dates, locations and representation limits documented. Complaint volume can reflect an easy reporting channel or repeated submissions from the same person rather than actual problem size. As a practical recommendation, separate event frequency from severity and identify groups missing from digital channels. A site visit may reveal how older residents or wheelchair users experience a location differently from the team’s assumptions. Treat early conclusions as hypotheses and record the missing checks rather than describing the whole city with untested impressions.

Compare four dimensions without hiding prerequisites

A practical matrix can compare service impact, suitable data, ownership clarity and the feasibility of a bounded pilot. Give each dimension a description and supporting evidence before introducing numerical weights that imply false precision. If the organisation later chooses weights, approve them and test how sensitive the ranking is to changes. Keep safety, lawful operation and authority as prerequisites separate from ranking: a high total cannot compensate for missing data rights or an accountable delivery organisation. A severe problem does not establish that a proposed technology addresses its cause, and available data does not establish priority. Use the matrix to expose reasoning and unresolved questions rather than replace authorised judgement.

Map responsibility across organisations

A challenge may span a municipality, service operator, regulator and technology supplier. Identify the outcome owner, data owner and response team, then specify who approves operational changes. In a service waiting example, publishing information will not by itself improve reliability if the operator has no response to interruptions. A short working session can agree a responsibility map and a clear output for each participant, without assuming powers the project team does not hold. Include operations, maintenance and customer support early. A technical model can work while cases remain unresolved because nobody owns response, closure or verification of the outcome.

Pilot a bounded part of the problem

Write the trial question, location, included users, baseline and comparison approach. An illustrative question is whether updated service information at one stop can reduce repeated enquiries while retaining an alternative for people without smartphones. This is a proposed test, not a verified result or promise. Agree what improvement would mean and how to observe side effects, such as staff workload or exclusion of a user group. Establish stopping conditions for data feed failure or an unavailable fallback. Do not attribute every change to the solution when timetables, road works or seasonal events also changed without being addressed in the comparison.

Make the comparison reviewable

The table gives hypothetical challenges for discussion, not an assessment of any Saudi city. It records the evidence still needed and whether an owner can translate findings into a service response. A smaller challenge may be a better first trial because it supports reliable learning and a defined outcome, while a broader challenge requires preparatory data work or agreement across organisations. Record reasons for deferral and the action needed for reconsideration. Do not remove a resident problem from the priority list merely because its data is harder to obtain. Improving the way that problem is understood can itself be the first enabling project.

Review the Saudi context before collecting data

Each pilot needs a review of requirements applicable to its location, data and operating model. Where personal data is processed, specialists should examine the Personal Data Protection Law and its regulations; SDAIA guidance confirms that storage itself is processing. [3] Where connected devices or a communications service are involved, the team should check current CST regulations applicable to that activity. A regulatory update announcement does not replace reading the relevant instrument. [4] Also review site permissions and relevant security requirements with the responsible specialists. The proposed matrix is a decision aid rather than a replacement for these checks, a compliance certificate or permission to collect data.

Turn the first step into a deliverable roadmap

RMG offers smart city strategy development, including current state assessment, priority domains, roadmaps and progress monitoring. [1] A useful starting discussion brings a documented challenge list, responsible owners and available data, then distinguishes pilot candidates from problems needing preparatory work. After a pilot, record the continuation, modification or deferral decision, its owner, operating cost and approval needed before expansion. Successfully operating a device is different from demonstrating a better service outcome. Discuss with RMG specialists how to turn a technology idea list into one defined urban challenge and practical steps for evaluating its effect on the service.