Road Expo Scotland Team Talks to LiveGuide: From Design to Guidance

1. You’ve worked in traffic management for around 30 years. What led you to create LiveGuide, and to move the job from paperwork to a platform?

I’ve worked in traffic management for around 30 years, at different levels and in different roles, and one thing that has always struck me is how much information already exists around a job – but how often the people actually delivering it still have to interpret, re-enter or go looking for that information themselves. The crews are the people I think about first. They are working in a potentially dangerous environment and I don’t want them standing around any longer than necessary trying to work out where they are on a drawing, counting back from landmarks, looking through paperwork or entering long strings of information into another system.

The signs are already designed. The locations are already on the drawing. So my thinking became: why are we not using that information to tell the crew where to go? That is really where LiveGuide came from. Get to the location, deal with the sign, press a simple action and move on. Each action then builds the digital record behind the scenes.

A lot of clients and contractors understandably want evidence that work has been installed, maintained and removed correctly. Rather than making the operative create that evidence as a separate administrative task, I want it to be a natural consequence of doing the job. My phrase for it is “less in, more out”. The operative should have to do as little administration as possible, while the system produces more useful information for supervisors, clients, designers and the business.

Over the years the industry has changed enormously, and rightly so. Some of the things we did 20 or 30 years ago would simply not be acceptable now. At the same time, there are new people coming into the industry who do not yet have decades of experience to fall back on. One of the things engineering training gave me was a better understanding of why things are designed the way they are. With LiveGuide I am trying to bring that full circle: allowing the designer’s intent and experience to travel further than the drawing, while also putting some of my own experience of delivering traffic management on the road into the hands of the people doing it.

2. LiveGuide takes traffic management designs straight from CAD into a live job. How does that leap from drawing to road actually work?

The starting point was actually quite simple. I have used CONE for many years, and where a traffic management plan has been designed in real-world coordinates, those sign placements already contain valuable engineering information.

LiveGuide began with the idea of extracting that information rather than asking somebody to type it all in again. From there it has developed considerably. Without giving away too much of the engineering behind the platform, LiveGuide can take an engineering package and interpret the signs, placements, coordinates, rotations and how the job is intended to operate.

An important part of developing it has been recognising that not every designer works in exactly the same way. Some plans are fully coordinate-specific. Others may use a real-world location but contain locally drawn or schematic approaches. Some are effectively schematic plans without usable navigation coordinates at all.

So I have built the Engineering Package around different acquisition modes rather than pretending every drawing is the same.

A specific plan can retain its true engineering coordinates. A plan that needs calibration can be corrected through controlled reference information. A schematic can remain a schematic and not pretend to have navigation accuracy it does not possess. It can then gain real placement information from what happens operationally.

The important principle is that the original engineering information remains the reference. If something changes operationally, we do not simply overwrite history and pretend it was always that way.

That matters to the designer as well. At the moment a drawing can leave a designer’s desk, move through several levels of an organisation and eventually reach the crew, and the designer may never know exactly how it was delivered.

LiveGuide gives us the opportunity to close that loop. The engineering intent travels into the operational job, and changes made in the field can be recorded rather than disappearing into phone calls or somebody’s memory.

3. How does LiveGuide guide crews on the ground, and what difference do you expect it to make at the roadside?

I actually don’t want to change the fundamental job the crew does. I want to make it simpler, quicker and safer to carry out.

From leaving the depot, LiveGuide can give the crew the information relevant to their run – what they need, where they are going and the sequence in which they are expected to work. Instead of using navigation merely to get to the general job location and then reverting to a drawing, the aim is to guide them through the operational run sign by sign.

When they reach a placement, the action should be simple: install it, preset it, record an exception, remove it, or whatever is appropriate. That action is recorded immediately.

The install, preset and removal workflows are deliberately similar so the system becomes familiar very quickly. Maintenance is slightly different because you do not necessarily want somebody navigating individually to every single sign. LiveGuide can support checks in sensible blocks while still allowing an individual sign to be selected where something needs attention.

If a cone is damaged, a sign has moved or there is another issue, I want that to be a quick selection rather than a paragraph somebody has to type at the roadside. Free text is still available where it is needed, and over time commonly used information can become easier to select.

Navigation can also help with the wider journey. If a run has a known start and finish, the platform can provide journey and traffic information around that work rather than crews having to piece that together separately.

The biggest benefit I am aiming for is reducing the amount of unnecessary time and mental effort at the roadside while actually improving the record that comes out of the job.

We are only now moving into the stage where that can be properly proven in live use, so I would be cautious about quoting percentage improvements yet. But the objective is very clear: make the process easier for the crew while improving accuracy, accountability and evidence at the same time.

4. Operatives, supervisors, clients and designers all need different things from a job. How does LiveGuide serve each of them without splitting the job apart?

One of the hardest parts has been making sure there is still only one job, even though very different people need very different things from it.

An operative does not need the same interface as an administrator. A supervisor wants progress and exceptions. A client may want assurance and evidence. The engineering side needs to know what was designed and what changed.

The challenge is not creating four screens. The challenge is making sure those four screens are looking at the same underlying truth. A good example is operational progress. If one operative installs a sign, another operative on the same job should not have to phone and ask, “Has that been done yet?” A supervisor should be able to see it as well. Ultimately the client view should be based on that same event rather than somebody recreating the information later.

The end goal can be very simple: is the job installed, are the required signs in place, and when we are removing it, has everything that should come off the network actually been removed?

There are more specialist workflows as well. The gantry and Red-X work is still an area I regard as developing rather than something I would overclaim today. The concept is to create a useful visual representation of the gantry so the requested state and operational information can be communicated more clearly.

At the moment I see that particularly as a guidance and reference tool. I would like to work with the relevant organisations to develop that further rather than pretend I can define somebody else’s operational process for them.

The same principle applies throughout LiveGuide: specialist workflows can sit within the platform, but they still need to feed the same job record rather than becoming disconnected mini-systems.

5. How does LiveGuide turn the information it captures into useful evidence, for example, around signs left on the network?

A straightforward example is signs left on the network. Everybody in traffic management has seen the complaints that come from redundant signs being left behind after works have finished. Sometimes there is a perfectly legitimate reason a sign has been left temporarily. The problem is when nobody has a clear record of it afterwards.

If LiveGuide records that a sign was installed, dropped, left on site or removed, then that physical item has a history. During removal, the system can guide the crew back through the placements rather than relying entirely on somebody spotting every sign in darkness or poor conditions. Think about a long diversion route on a rural single carriageway in the middle of the night. If a sign has blown down or is lying somewhere less visible, it can be surprisingly easy to miss when somebody is simultaneously driving, interpreting a drawing and trying to identify landmarks. If you know where that sign was placed, you can at least take the crew back to the correct area and help reduce the chance of it being forgotten.

And where something genuinely has to remain, it can be recorded as such rather than disappearing from the operational picture. Those outstanding signs could then be grouped into a collection run later. That is what I mean by operational history. It is not data collection for the sake of collecting data. It is knowing what is actually out there, what happened to it, and what still needs attention.

The same applies across different phases of work. If a crew returns to a scheme later, the system can tell them what is already on site rather than treating every visit as though nothing happened before.

6. You describe the platform’s principle as “capture once, use everywhere”. What does that mean in practice, and where is LiveGuide heading next?

We are a long way beyond the original idea, but I still see LiveGuide as being at the beginning of what it could ultimately become. The core principle is already there: information created in engineering should not have to be recreated in operations, and information created in operations should not disappear when the job moves into supervision or reporting. The platform is bringing together engineering packages, operational runs, navigation, installation and removal workflows, supervision, job progress, stock and evidence in a connected environment.

There are also areas I am deliberately still developing and testing. I would rather be honest about that than present a roadmap feature as something already finished. The next stage is tightening those connections. If an engineer changes something, the operational side should understand what changed. If an operative records an exception, the supervisor and relevant client view should see the same event. If something remains on site, that should carry forward into the next operational task rather than relying on somebody remembering a phone call.

That is what “capture once, use everywhere” means to me. It is not about replacing the people making decisions. It is about removing unnecessary duplication and allowing the information they already create to work harder throughout the life of the job.

7. Road Expo Scotland will be the first time LiveGuide is shown to the wider industry. What are you hoping to hear from visitors?

Road Expo will be the first time I have put LiveGuide in front of the wider industry in this way, so I am genuinely looking forward to hearing what people think. I want designers to look at it. I want supervisors to challenge it. I want clients to tell me what information would actually be useful to them, and probably most importantly I want the crews who work on the road to tell me whether it makes their job easier.

I have spent around 30 years solving problems at different levels of traffic management, from the practical side through to management and engineering. A lot of what has gone into LiveGuide comes from situations where I have thought, “There must be a better way of doing this.”

I believe traffic management is ready for the next step in how engineering information and operational delivery are connected. There are already very good systems doing individual parts of that journey. What I am trying to build is the platform that joins more of those parts together. I hope people at Road Expo see something in it that relates to their own part of the industry.

And I want the criticism as much as the positive feedback. If somebody who does that job every night tells me there is a better way for LiveGuide to work, that is useful information. I have wanted to build something like this for a long time. Now I am looking forward to putting it in front of the people who actually understand the problems it is trying to solve. And, of course, I would be delighted if a few of them decide they want to use it.