How do we best respond to potholes in roads? Let’s use this example to contrast problem-led verses a vision- or goal-led design approach. The latter will take us in surprising directions… in the smarter city we can not only fix potholes… we can enable future mobility!

[I don’t pretend that this analysis below is comprehensive — feel free to fill out any gaps yourself.]

Problem-Led Approach

Here is an example of problem-led thinking. The focus is on the problem and shifts quickly to the technologies and ‘clever ideas’ that could solve the problem.

[Note: There are many issues with this ‘point problem’ — ‘point solution’ approach which I won’t expand on here. The biggest is that problem solving doesn’t naturally evolve into holistic solutions but instead can entrench barriers to better, holistic, integrated outcomes.]

The Problem

Potholes are causing damage to cars. How do we detect potholes and respond quickly?

The Point Solution

In our solution, we propose two complementary technologies. We call this a point solution because it is specific to the problem.

• Develop an app for citizens to report potholes.
• Use scanning technology to detect potholes and gradual road deterioration.
  • Scanners could be attached to garbage trucks, autonomous robots, or dedicated council vehicles.
  • Scanner technologies could include for example: laser, cameras, multi-spectral cameras, ultrasound etc.
• Apply artificial intelligence techniques to analyse scans and predict when embryonic potholes will need attention.

Vision- or Goal-led Approach

In a vision- or goal-led approach, rather than focus on the problem we focus on the opportunity to improve the lives of citizens through minimal cost/disruption — in this use case — disruption by potholes. We also focus on making our government or service’s response to potholes more efficient and productive. Together these goals help make our city more liveable, productive and efficient.

In a vision-led approach we look at plausible, ideal futures and ideal end states. We also focus on the intangibles of ideal customer experience, and efficient, productive processes rather than focus on particular technologies. In the former we can find future-proof elements. For these reasons, we don’t focus on technologies that are yet to been invented, e.g. self-repairing roads.

Goals

These are our ideal, plausible end states. Note they are customer-focused and future-proof.

1. Minimum cost/disruption to citizens caused by potholes.
2. Minimise number of vehicles being damaged.
3. Minimum disruption to citizens during pothole repair.
4. A cost-efficient response by pothole repair services.

Goals around excellence in customer experience are usually future-proof.

Functional Requirements

Now we can start around these goals and develop requirements for our data and technology. These are called functional requirements and as such are technology independent. The actual selection of the data and technology comes at a later stage.

1. Ability to detect existing dangerous potholes quickly and the ability to detect progressive road deterioration. [Goals 1 & 2]
2. As soon as a dangerous pothole is detected — by whatever means — we want to warn other vehicles of the danger — by whatever means — so they don’t fall into it. [Goals 1 & 2]
3. We want to efficiently schedule pothole repair for potholes that develop gradually. That is we want to measure gradual deterioration and predict the optimum repair date. [Goal 4]
4. We want to inform citizens, businesses and other stakeholders of pending road closures for repairs. [Goal 3]
5. We want to inform and co-ordinate disparate services and stakeholders who may also want to close or dig up the same road for other purposes, e.g. sewer repairs. This minimises citizen disruption and creates cost efficiencies. [Goal 3 & 4].

Note that in Requirements 2, 4, and 5 we need the ability to quickly inform customers and stakeholders of problems with the road and in Requirements 3 & 5, the ability to book the road for exclusive use for planned repairs — again with stakeholders being kept well informed in advance. We’ll call these two functional requirements informing and booking. At this stage we don’t care how we do this communication around informing and booking or who does it. But we know it is a fundamental requirement to meet our goals around excellent customer and stakeholder experience and cost efficiencies.

Genuine future-proofing

Note also, that at this point both our goals and requirements of informing and booking are all future-proof; they won’t change with technology developments.

Holistic System Context — beyond potholes

Now, let’s broaden our perspective one notch beyond potholes. Lots of things can make a road unavailable for use due to unplanned events (e.g. potholes) or planned events (e.g. repairs). Here are some examples.

Unplanned events that block the road include:

• Potholes, floods, fire, fallen trees, car accidents, power line breakages, sewer or water mains breakage; damaged bridges; emergency responder vehicles (ambulances, fire brigade).

Planned events that block the road include:

• Road, sewer, water, power, communications repairs; street parties; parades; garbage collection trucks on narrow streets etc.

Holistic System Context — beyond roads

We can of course broaden our perspective beyond roads to the broader transport network: rail, sea and air routes. Rail tracks can be disrupted and closed by similar issues to roads, e.g. fire, flood, fallen trees, deterioration and damage. Ferries can be disrupted by high seas and aircraft blocked by weather systems. In all cases we’d like to inform all affected parties and customers what is happening as early as possible so they can alter their travel plans accordingly. [Once again our focus, for now, is not how this is achieved or by who — we are exploring the functional requirements for our system.]

Holistic System Context — beyond the transport network

Roads, rail lines, sea and air lanes are all part of the transport network. Their is a functional requirement to inform customers and stakeholders when these networks are disrupted by unplanned and planned events. There is also a functional requirement to book or reserve most of these items for exclusive access during times of repair, for example.

But mobility requires more than the network. Vehicles need spaces to stop, to park, to pick up and drop off. When they do, those stopping or parking places — just like a road closed due to a pothole — become temporarily ‘closed’, i.e. unavailable to other vehicles.

So our informing and booking functional requirements now apply to a whole new set of static (unmoving) mobility assets related to stopping or parking of ‘vehicles’ (car, trains, boats, planes):

• Parking spaces, loading zones, loading docks for trucks, taxi ranks, stations, ports, transport hubs and terminals.

Wrapping Up

We have worked systematically up from the humble pothole detection and repair scenario to the big picture and discovered that the future-proof requirements of informing and booking are common to 10s of mobility-related scenarios. Personally, I find this to be an extraordinary result; we have found commonality across seemingly diverse applications. And if we dove still deeper we’d find a few things:

• The large number of diverse, disconnected actors (people, organisations, entities) impacted by a simple pothole repair scenario when the road is partially or fully closed. These include local residents; service providers, e.g. deliveries, garbage removal and recycling; buses; car drivers; parades and commuters. A proper system design underpins minimal disruption and efficient operations for all these actors.
• Even more commonality across apparently unrelated mobility use cases and scenarios that we haven’t covered here.
• The data required to be shared such as location and booking information is essentially universal across all diverse use cases!

Extraordinary… we find commonality across a large number of diverse use cases, underpinning excellence in customer and stakeholder experience, cost savings and productivity improvements.

These requirements are driven by our customer-focused goals of excellence in: customer experience, efficiency and productivity. Therefore, rather than have 10s of fragmented solutions that entrench inefficiencies we can design the future-proof common thread that underpins future mobility including repairs and maintenance. Note that if that thread doesn’t exist we can’t achieve the customer-focused vision and goals.

Fragmented solutions are not designed to leverage the commonality that exists across diverse mobility-related applications. They block our vision and goals and entrench sub-standard outcomes.

Note that we could have reached these conclusions by working top down; that is, starting with vision and goals for future excellence in mobility outcomes for people and for things (logistics). Such analysis is actually more comprehensive and uncovers additional benefits not discussed here. It also leads to the functional requirements for informing and booking across every actor and entity in future mobility of people and of things but also for responding effectively to the humble pothole!

Informing and booking capability are requirements that enable vision-led excellence in future mobility for every entity and actor!

A System Design Journey…
Beware! Don’t Jump to Conclusions

In our fledgling system design process above we are still at a high-level requirements stage. We are still a long way from implementation specifics. Beware the temptation to jump to implementation conclusions such as, “This will result in a single centralised system owned and run by [insert organisation name here, e.g. government]”.

Similarly it is in appropriate to assume, “Open data is the solution.” It may be part of the solution, but you don’t know that until a system design has been completed and past some user centred design tests.

There are many different ways and business models to implement a system that delivers what we need. We get to that system by working through a proper system design process that creates blueprints co-created with customers and stakeholders.

The Role of Government

A system blueprint involving diverse stakeholders can’t evolve by itself from piecemeal point solutions. For this reason, government has a key role to play in leading and facilitating a system level co-design process.

Government has an exciting key role in leading and facilitating the system co-design process on behalf of its citizens.

Government has two further responsibilities; to ensure that the system design:

• Facilitates a level playing field for industry service providers to develop and provide innovative mobility-related applications.
• Is safe and robust against rogue actors (including rogue staff of industry partners) deliberately or inadvertantly sabotaging the sytem.

And finally…

This example is just a taste. Plainly there is more to be said about requirements for informing and booking:

• What data needs to be shared between whom and how will we do it?
• What are the commonalities and differences across use cases?
• What exactly has to be built and who owns and maintains each component?
• What is the role of government and of industry in all this?
• Can we design a system and ecosystem that creates a level playing field for service providers?
• Can we design a future mobility system that is better and safer than today; robust against rogue actors?

To learn more, contact the author, Neil Temperley.