DEVELOPING TECHNOLOGY FROM EXPERIENCE ON THE GROUND

It has been a while since our last update in May, but we have been busy behind the scenes at RH Consultancy, including the continued development of our RavenLine technology.

I have spent a large part of my working life in different countries and environments, including conflict zones, remote locations and some very busy cities. Over the years I have worked alongside field operators, security teams, consultants, journalists, local staff, drivers, medical personnel, operations rooms and the clients ultimately responsible for everyone involved.

When you have seen an operation from all those different sides, you quickly learn what people actually need and what merely looks good sitting on a computer screen.

That experience is now being used to help us develop our own technology.

There is a lot of talk about AI at the minute. Every second company appears to be developing something that will change the world, solve every problem and do half the job without a person being involved.

I am not against AI. We use it and we would be foolish not to. It can speed things up, help us work through ideas and support parts of the development process.

What it cannot do is replace experience.

It has never stood at the side of a road wondering why a vehicle is late. It has never lost communications with a team, worked through a deteriorating security situation or had to make a decision with limited information. It has never had to take responsibility for that decision afterwards either.

That is the part which can easily be missed.

Technology needs to work for the person using it. It should make a task easier and give the client a better understanding of what is happening. If it creates more work, needs constant explanation or only works properly under perfect conditions, then there is a problem.

Perfect conditions rarely exist on operations.

Internet access may be good in the office and poor or completely unavailable further out. A person may be trying to use a system inside a vehicle, at a remote site, in bad weather or while dealing with several other things at once.

That has to be considered from the beginning.

The operating environment also makes a massive difference. You cannot take one fixed idea and assume it will work everywhere.

An organisation operating in an area prone to earthquakes or flooding will have very different concerns from a team working somewhere where drones or indirect fire are the main dangers.

A mining company may have people spread across a large and remote area, with long travel times, difficult roads, heavy machinery and limited communications. The security issues will also be mixed with safety, community relations, local employment and the movement of staff and equipment.

Then take somewhere like Nairobi. It is a major city with good infrastructure and strong business growth, but operating there brings a completely different set of challenges. Traffic alone can change a journey plan within minutes. There are also issues around crime, public disorder, access to sites, staff movement and the time it can take support to reach someone across the city.

None of these environments is necessarily more important than another. They are simply different, and the people involved need something that reflects where and how they are actually working.

This is why we keep coming back to simplicity.

Simplicity does not mean basic, and it certainly does not mean lowering standards. It means not asking somebody to complete ten steps when three will do the job. It means understanding what information is genuinely useful and what is simply being collected because the system allows it.

We have all seen systems with endless menus, dashboards and functions that nobody uses. They can look impressive during the sales demonstration, but six months later staff have gone back to WhatsApp, spreadsheets or bits of paper because those are quicker.

That is the reality we are trying to avoid.

Our own development involves plenty of testing, changing things and going back over them again. Sometimes an idea works. Sometimes it does not. Occasionally something we thought was important turns out to be unnecessary once we look at it from the user’s side.

That is all part of the process.

We are taking experience from different countries, industries and types of operation and putting it to use. We are also listening to the people who will eventually use the technology, because the person on the ground will often spot a problem that is invisible from an office.

We still have plenty of work to do, and I am happy with that. I would rather take our time, test things properly and develop something useful than rush out another product surrounded by big claims and AI language.

For us, the test is fairly straightforward.

Will it work for the person on the ground, in the environment they are actually working in?

If the answer is no, we go back and work on it again.