A Practical Guide to EHS Software Implementation
The Data Model Comes Before the Vendor
Most implementations are run as a technology purchase. The vendor is selected before the requirements are written, and the requirements are written before anyone asks what a root-cause investigation needs at point of entry.
Functional Requirement
“The system must allow mobile incident reporting.” Every vendor on the shortlist can tick this box. It says nothing about what the report captures, so it cannot separate a platform that supports investigation from one that only logs events.
Data Architecture Requirement
“The hazard category field must enforce a defined list of 12 categories, selected before go-live, with no free-text option.” This line decides whether the system can ever produce a hazard trend report worth reading.
The Six Ways It Goes Wrong
The failures follow a pattern, and they compound in sequence. If you recognise your organisation in more than two of these, you have already located the root cause.
Tool Bought Before the Data Model
Requirements produced a feature list: mobile reporting, offline mode, an HR integration. No one asked what a root-cause analysis needs at point of entry. The system can log an incident but cannot explain why it happened.
Current Pain, Not Future Capability
Asked what they want, users describe today's manual process minus the paperwork. The system replicates the spreadsheet, and a year later the same gaps sit inside a more expensive platform.
Interface Polish Over Data Quality
No one asked what the system does when a worker submits an incomplete incident report, or whether the investigation module captures contributing factors or only checkboxes.
Change Management Run as Training
Training teaches people how to use a system. It does not make them use one that adds twelve clicks to a task the clipboard on the wall handles in one.
Go-Live Treated as the Finish Line
The project team disbands at launch. Within six months the user list is out of date and the report templates miss a regulatory change, because no one owns the configuration.
Shadow IT Treated as Indiscipline
Workers report hazards on WhatsApp and track actions in Excel because the official system is slower than the physical work. A policy mandating the official system treats the symptom, not the design.
Seven Chapters, Ordered by Dependency
Each chapter produces the documents the next one needs. Requirements define the demo script. The culture assessment decides which implementation approach you can sustain. Skipping ahead produces the failure modes above.
The Sequence and the Diagnostic
The introduction sets out the six failure modes, the sequencing error behind them, and a triage table for projects already under way. The conclusion closes with a three-question test you can run against your current or planned system.
Foundation & Discovery
Map your legal obligations before writing a feature list, then specify what the system must capture at point of entry: mandatory fields, controlled picklists, and the contributing-factor field most vendor data models leave out. A vendor who cannot meet the regulatory mapping is disqualified, not downgraded.
The Human Element
Assess safety culture and change capacity before choosing a vendor: a culture that punishes reporting will reject a tool built for proactive reporting. When adoption stalls, the first question to Change Champions is whether any task now takes longer than it did before. That is a design problem no communication campaign fixes.
Choose Your Partner
Evaluate vendors on data model quality, implementation method and contract terms. Module 0 of the demo script has the vendor submit an incomplete near-miss report and show whether the system accepts it. The contract review covers change orders, service-level remedies, renewal price caps and data return terms, all negotiated before signature.
From Plan to Platform
Configure in a fixed order: controlled vocabularies, then forms, workflows, integrations, and dashboards last. Scope the legacy data migration, or archive the data instead. Before signing off User Acceptance Testing, generate a hazard trend report from the test data alone. If it is meaningless, the form design is wrong.
Measuring Success
Reported incidents rise after go-live because the new system captures what the old one missed. Freeze KPI definitions before launch, set leading indicator baselines at 90 days, judge the quality of reports rather than the login count, and hand the system to permanent owners before the project team disbands.
Start Where Your Project Is
A new implementation works through the book front to back. If your project is already under way, or you are diagnosing why a previous one fell short, find your situation and go to the chapter where the failure started.
| If your situation is… | Start here |
|---|---|
| No vendor selected yet | Chapter 2 · Foundation & Discovery |
| Requirements written, vendor not yet selected | Chapter 3 · The Human Element |
| Vendor selected, implementation not yet started | Chapter 4 · Contract and integration specs |
| Mid-implementation, requirements incomplete | Chapter 2 · Requirements section |
| Mid-implementation, change resistance | Chapter 3 · The Human Element |
| Live, adoption below 70% | Chapter 3 · The interface may be the barrier, not the users |
| Live, data quality is poor | Chapter 5 · Data migration and User Acceptance Testing |
| Live, cannot show leadership what the system delivered for its cost | Chapter 6 · Measuring Success |
Who Should Read This Book
Written for the people who choose, deploy and then live with an EHS platform for years after the project team has moved on.
EHS Managers & Directors
The people who will own the system and must write its requirements before procurement starts. The hazard taxonomy and root-cause codes are field decisions. If you do not specify them, the vendor's defaults will.
Project Managers & Implementation Leads
Teams running the deployment who need the charter, work breakdown, risk register, configuration order and Go/No-Go gate in a form they can adapt rather than build from scratch.
IT, Procurement & EHS Product Teams
People who run vendor evaluations or build EHS software and need to know which requirements decide whether a platform can support an investigation, and what the EHS function must hand them before the first vendor briefing.
Design the Data Model Before You Sign
Twenty-nine templates, from the Project Charter to the Go/No-Go Cutover Checklist, ordered so each decision is made before the step that depends on it. Use them on a new implementation, or trace back through them to find where a live one went wrong.