Most business-critical software does not begin with somebody saying, “We’re going to build a business-critical system.” It usually starts with something much smaller. A spreadsheet is becoming difficult to manage, a departmental form needs digitising or a handful of engineers need a better way to record their work.

It is easy to think of software used in the field as an office process running on a phone. In an office, the environment is usually predictable. The user has a reliable connection, a full-size screen and time to deal with something if it does not behave as expected. Someone working in the field may be in a plant room, on a construction site, beside a road or inside a building where the signal disappears completely. They may be wearing gloves, working in poor weather or co

Low-code has changed application development enormously, but I sometimes think the name gives people the wrong impression. It can sound as though much of the work involved in creating an application has disappeared when, in reality, a lot of it has simply changed.

One of the odd things about software is that the screen often tells you surprisingly little about the system behind it. Two engineers can be standing on different sites looking at applications that appear to do almost exactly the same thing. Both have been given a job, both complete a form, both take photographs and both submit a record back to the office. From their point of view, the experience may be almost identical, even though the organisations they work for have take

Give a developer a problem and, quite naturally, they start thinking about how it could be solved: what data is needed, what the screens might look like, how the process should flow and what should happen at each stage.

HSEQ information is most useful when it is captured close to the work. That might be at the edge of an excavation, beside temporary traffic management, during a site inspection, before a task starts, after a near miss, or when a supervisor is checking that the right controls are in place. In utility connection work, safety is not separate from delivery. It sits inside the work itself. Access, excavation, plant, electrical risks, public interfaces, subcontractors, weather, gro

A project plan gives structure. Site updates show how the work is moving. For project and programme teams working across utility connection projects, both matter. The plan sets out the sequence, resources, dates, permits, subcontractors and client requirements. Once work begins, the picture naturally develops through site activity. Access is confirmed. Ground conditions become clearer. Photos are taken. Checks are completed. Progress is recorded. A subcontractor may finish on

The amount of work around utility connections and electrical infrastructure is increasing. That is not just a feeling inside the industry. It sits against a wider backdrop of grid connections reform, clean power targets and the need to move viable projects through the system more efficiently. For the companies delivering this work, the policy language can feel a long way from the reality on site.

Service improvement in the water industry does not always start with a broken process. Often, it starts with a routine one. A maintenance check. A sampling request. A site inspection. A pollution event log. A welfare survey. A generator inspection. A stock check. A field-created job. Across water operations, these processes happen every day. They support compliance, asset condition, environmental reporting, safety, maintenance and operational control. On their own, each may l

Most HSEQ problems do not begin with someone ignoring a process. They begin with someone trying to get something done. A supervisor takes a photo of a hazard and drops it into a WhatsApp group because it needs a quick response. A site manager edits an inspection checklist because the official version does not quite fit the job. A contractor completes a PDF and emails it to the person they normally deal with. Someone saves evidence to a personal folder because they are out

Reactive repair requests are part of everyday life in the water industry. Across treatment works, pumping stations, networks and operational sites, colleagues often spot issues long before they become visible anywhere else. A failing component, damaged equipment, an electrical fault, a control issue or an asset that simply does not look right may all need to be raised for review. The problem is not usually that people fail to report these issues. The problem is what happens

At some point most operations teams realise they have more data than they can comfortably interpret. There are dashboards for delivery, dashboards for compliance, dashboards for finance. Every function has its own view of what’s happening, and none of them are technically wrong. The problem isn’t a lack of information. It’s that the information doesn’t always help you decide.

A calm HSEQ environment is usually taken as a positive sign. Fewer issues are raised, fewer escalations are required, and fewer difficult conversations take place. From the outside, it can look as though the organisation has settled into a steady rhythm, with systems in place and expectations understood. That sense of calm often feels deserved. Processes exist, people are experienced, and nothing obvious appears to be going wrong. Over time, the absence of disruption becomes

There’s usually someone in every operations team who knows how things really work. Not how they’re written down, but how they actually move. They know which client prefers what. They know which region needs extra checking. They know which report format finance will question and which one will go straight through. It doesn’t look like a risk at first. It looks like experience.

Many HSEQ decisions are sound in principle. Controls are introduced, procedures are updated and actions are taken with the right intent. When reviewed later, those decisions often appear reasonable and proportionate. The difficulty is not usually what is decided, but when.

We talk about capacity a lot in operations. Volume, headcount, workload. It’s usually framed as “we need more people” or “we need to improve productivity.” In my experience, that’s rarely where things actually slow down. It’s usually somewhere in the middle. A job gets done. The report comes in. Someone reviews it and has a question. It goes back out. It comes back again. Finance holds off. Compliance wants something slightly different. None of it is serious. Nobody’s failin

A great deal of HSEQ work never leaves a trace. It happens in conversations, small interventions, and quiet corrections that stop issues developing further. A supervisor pauses a task to clarify something that does not feel quite right, a safety advisor spends time talking through an approach rather than raising a formal issue, or a minor adjustment is made to avoid a problem that would otherwise have escalated.

Many organisations believe they have strong control over HSEQ. Processes are documented, checks are completed, incidents are recorded, and dashboards are reviewed. From a distance, everything appears orderly and well managed, and that sense of control is often genuine. The systems are doing what they were designed to do.

Most HSEQ systems are very good at recording outcomes. They tell us what happened, when it happened, and what action was taken afterwards. That structure is essential for investigations, audits and formal reporting, particularly in regulated environments where traceability matters.

By the time an HSEQ manager hears the question “which version are we meant to be using?”, it is usually already too late. The change itself was small. Sensible. Agreed without fuss. But the work moved faster than the system could keep up, and now there are two or three versions in circulation. One printed yesterday. One saved locally with a tweak added. One still sitting in the system, unchanged.