Draft for review
Start with the decision
When a new mobility need arises, it is tempting to start by comparing equipment, platforms or features. We suggest taking a step back: describe the decision that the operating team needs to make more effectively. This conversation helps distinguish essential requirements from attractive extras and creates shared evaluation criteria. The following questions are a working guide rather than a prescription for every setting.
1. What problem are we trying to solve?
A statement such as “we need more information” leaves too much open to interpretation. Specify who needs that information, in what situation and for which action. Detecting an incident earlier and coordinating a response, for example, is a different objective from studying traffic patterns. Describing a use case helps align expectations before developing requirements or requesting proposals.
2. How will we know things have improved?
Defining the intended outcome also means describing the starting point. What can we observe today, and what change would be useful? Different objectives require different measures. Agree how evidence will be collected, who will review it and over what period. Evaluation should go beyond checking that equipment has been installed or that a dashboard displays data.
3. Who will use and maintain the solution?
Operations, maintenance and service owners may have different needs. Involving them early helps identify support hours, required capabilities and tasks that must become part of everyday work. A demonstration can showcase a feature; talking with future users helps establish whether it fits the actual process.
4. What will it need to work with?
Before defining a purchase, review existing systems, information flows, responsibilities and constraints. What information comes in, what goes out and who responds when it is missing? The aim is not to anticipate every technical detail, but to make implementation dependencies visible. Important assumptions should be documented and assigned to someone who can verify them.
5. What must we learn before scaling up?
Where uncertainty remains, a limited trial can help test assumptions. To be useful, it should start with questions and evaluation criteria, not simply a list of equipment. Agree what will happen after the results: continue, adapt or stop. A trial without a subsequent decision can create activity without reducing uncertainty.
A practical first step
Bring together the people who define, operate and maintain the service. Prepare one page describing the problem, users, intended outcome, dependencies and unanswered questions. It does not replace technical analysis: it helps direct that analysis and supports better questions throughout the project.




