QHSE Software Implementation: An Illustrative 90-Day Pilot
Start with a bounded operational workflow and evidence that it works for the people who will use it. The schedule below is an editorial planning example for a pilot, not a benchmark, vendor commitment or promise that a complete organisation can deploy in 90 days.
Editorial responsibility: Dimitris Mitsios (Founder of The QHSE Standard; product marketing at Tekmon) · Tekmon pays for sponsored placements on this site (disclosure) · How pages are made · LinkedIn
A 90-day example with acceptance gates
Adjust the calendar to procurement, configuration, workforce availability and data complexity. Advance when the agreed evidence is accepted, not simply when a date arrives.
Days 1 to 15
Approve the pilot boundary
Accountable roles: Sponsor and process owner
Choose one workflow, site and representative user group. Document current records, responsibilities, scope exclusions, source systems and a baseline. Include workers from the relevant shifts. If the current process does not work, redesign it now rather than configuring a copy of it.
Acceptance gate: The sponsor approves the scope, budget, acceptance criteria and fallback process. Unresolved legal or data-access questions have named owners.
Days 16 to 30
Configure and reconcile
Accountable roles: Process owner, administrator and IT/data owner
Configure roles, forms, status transitions and notifications in a test environment before production records exist, and test it with dummy records to find unanswerable required fields and looping approvals. Decide which historical records migrate and which start fresh; migrate a representative sample and reconcile record counts, attachments and identifiers. Specify interfaces and failure handling.
Acceptance gate: The team can trace a migrated record and demonstrate permitted and denied access. Data discrepancies are resolved or explicitly excluded from the pilot.
Days 31 to 60
Run representative work
Accountable roles: Pilot users and acceptance lead
Test creation, rejection, correction, escalation and reopening. Include offline capture if required, an unavailable approver, an interface failure and an export. Record observed results separately from vendor claims. Do not keep a parallel paper or spreadsheet record for in-scope work beyond the agreed fallback. Train by role: administrators and supervisors need longer sessions than frontline reporters, and a named super-user at the site helps colleagues. Close the run with a retrospective: what worked, what got in the way and what should change before another site.
Acceptance gate: The process owner accepts the defined scenarios; blocking defects have a safe fallback or are fixed. Users can complete their task without administrator coaching.
Days 61 to 90
Decide whether to expand
Accountable roles: Sponsor and operational owner
Review pilot measures, support demand and user feedback. Confirm administration, backup/recovery responsibility, retention and exit arrangements. Update procedures and role-specific training. Hand over a written playbook for the next site: the procedure for the piloted workflow, an administrator runbook for users, forms and reports, the escalation path for issues and a calendar of recurring reviews.
Acceptance gate: Approve expansion, extend the pilot or stop. Record evidence, residual risks, responsible owners and the next review date; reaching day 90 is not an acceptance criterion.
Where the pilot sits in a wider rollout
The 90 days above are one stage of a longer path. This example adds selection before the pilot and expansion after it. Schedules usually stretch with procurement and security review, the volume and quality of migrated data, the number of sites and interfaces, worker consultation, shutdown calendars and a pilot that has to be repeated.
- Select
- Pilot
- Roll out
Text version of this diagram
- Requirements and shortlist. Weeks 1 to 3. Owner: Process owner. Group: Select.
- Demos, trial and references. Weeks 4 to 7. Owner: Project team. Group: Select. Use the same script and scorecard with every vendor.
- Contract, security and data review. Weeks 8 to 10. Owner: Sponsor, IT, legal. Group: Select.
- Pilot boundary and configuration. Weeks 11 to 14. Owner: Process owner, admin. Group: Pilot. Pilot days 1 to 30 of the 90-day example.
- Run representative work. Weeks 15 to 18. Owner: Pilot users. Group: Pilot. Pilot days 31 to 60.
- Role-based training, site super-user. Weeks 15 to 20. Owner: Admin, vendor. Group: Pilot. Runs alongside the pilot work.
- Review and expansion decision. Weeks 19 to 23. Owner: Sponsor. Group: Pilot. Pilot days 61 to 90: expand, extend or stop.
- Expand site by site. Weeks 24 to 35. Owner: Site leads. Group: Roll out. The length of this block scales with the number of sites and interfaces.
- Handover to routine administration. Weeks 36 to 39. Owner: Admin, IT. Group: Roll out.
Milestones
- Contract signed. Reached at the end of week 10.
- Expansion decision. Reached at the end of week 23.
- Steady state begins. Reached at the end of week 39.
Dependencies
- Demos, trial and references starts only after Requirements and shortlist finishes.
- Contract, security and data review starts only after Demos, trial and references finishes.
- Pilot boundary and configuration starts only after Contract, security and data review finishes.
- Run representative work starts only after Pilot boundary and configuration finishes.
- Role-based training, site super-user starts only after Pilot boundary and configuration finishes.
- Review and expansion decision starts only after Run representative work finishes.
- Expand site by site starts only after Review and expansion decision finishes. Only if the expansion decision is yes.
- Handover to routine administration starts only after Expand site by site finishes.
What vendors document about what a pilot depends on
We checked the records of 212 QHSE, EHS and ESG software profiles through 2026-10-14. Where a profile has no statement, we found none; that does not mean the product lacks it. Every statement is the vendor's own and was not tested. The rules for each count are in our integrations study, security, trial and offline study and hosting study. No product is named and nothing is ranked.
| The record states | Pilot days | Profiles | So in the pilot |
|---|---|---|---|
| Names a system it connects to93 mention only a standard or an interface, 39 mention integrations in general and 22 say nothing. | Days 16 to 30 | 58 of 212 | Name each system in your pilot. Ask for the direction of the data, who maintains the link and what happens when it fails, and test a failed message in the test environment. |
| Mentions an APIA mention of an API is not a finished integration for your records. | Days 16 to 30 | 125 of 212 | Ask which of your records the API can read and write, the limits, and which plan includes it. |
| Documents an offline workflow52 more document a partial one. | Days 31 to 60 | 40 of 212 | Run the offline scenario on the pilot devices and record which steps were shown; keep it out of the first gate unless it is a must-pass condition. |
| States any language support5 state an interface in at least two languages. | Days 31 to 60 | 39 of 212 | Ask which language the screens, reports and exports will use for each pilot group, before you plan the training. |
| Says what can be exported at exit11 give a deletion or retention rule and 9 a backup statement. | Days 61 to 90 | 4 of 212 | Ask for the recovery and export arrangements in writing, and who is responsible for each, before the expansion decision. |
The pilot is where a claim becomes something you have seen. Where a record is silent, plan to test the item yourself, and keep what you could not test open instead of counting it as passed.
Assign decisions as well as tasks
The sponsor approves budget and expansion. The process owner approves the workflow and operating procedure. IT and data owners approve identity, access, interfaces and recovery arrangements. Pilot users and worker representatives test real work and raise barriers. A vendor implementation lead can deliver configuration, but does not replace your organisation's accountability.
Name the person who can reject acceptance, approve a workaround and stop the pilot. In a small team one person may hold several roles; record those responsibilities explicitly and separate review where the risk requires it.
Measure the process without inventing a benchmark
These are proposed pilot measures. Agree a baseline, denominator, owner and locally justified target before collection; none is an industry pass mark.
- Task completion: accepted tasks divided by assigned pilot tasks, separated by role and shift. Track why work remains incomplete.
- Record quality: sampled records missing required evidence divided by records checked. Preserve the sampling rule.
- Retrieval effort: time needed to retrieve an approved record with attachments and history using the intended reviewer account.
- Workflow reliability: failed uploads, duplicate records and unresolved interface errors across attempted transactions.
- Response quality: overdue actions, reopened actions and completed effectiveness reviews. A closed status does not by itself prove effectiveness.
- Support and adoption: tasks completed without coaching, support requests and feedback themes. More hazard reports can reflect changed reporting access; do not claim incident reduction from a short pilot.
Keep an acceptance record that survives handover
Decide what to migrate, and what to keep
Migrating every historical record is not free: each one has to be mapped, reconciled and kept. Decide record type by record type what moves, what stays in the old system as a read-only archive and what is not carried over. Migrate a representative sample first, as the plan above says, and reconcile counts, attachments and identifiers before you migrate more.
Records about people raise a further question. Article 5(1)(e) of the GDPR, which we read on EUR-Lex on 18 October 2026, says personal data is to be kept in a form that permits identification of the people concerned for no longer than is necessary for the purposes for which it is processed. Article 28(3)(g) says a processor, at the controller's choice, deletes or returns all personal data after the end of the services and deletes existing copies unless Union or Member State law requires storage. So write down the retention rule for each record type, who applies it in the new system, and what happens to the old system's copy. Which rule applies to you depends on your own law and sector.
- For each record type: migrate, archive read-only, or leave behind, and the reason.
- The retention period for each, and the person who confirmed it.
- What happens to the old system's data and its copies when the old contract ends.
- A reconciled sample: counts, attachments and identifiers match before you approve the rest.
This is an editorial planning aid, not legal advice. See the GDPR on EUR-Lex and, for the exit side of the new contract, the pricing guide's exit costs.
Size the internal commitment before day 1
The pilot's largest cost is usually your own people's time, and it is the one nobody quotes. Before the sponsor approves the boundary, get named availability in writing rather than a percentage: which process owner, administrator and pilot users, on which days, and what they will stop doing while the pilot runs. A process owner who is still carrying a full operational load will accept whatever the vendor configured rather than test it.
Separate what the vendor's implementation offer covers from what your team has to do. Configuration days, data migration, interface work, training delivery and post-handover administration are frequently priced apart or not included at all. Whoever will administer the system after handover belongs in the pilot from the start — training them afterwards means the first real configuration change is made by someone who never saw it built.
Decide in advance what stopping looks like
A pilot that cannot fail is a demonstration. The fourth gate allows a stop, so agree beforehand what happens on that path, because an abandoned pilot that is never formally closed leaves two systems of record and a group of users who have lost confidence in both.
Record the refusal against the specific acceptance criterion rather than as a general verdict, and separate three different findings that look alike at the end of a pilot: the product does not do this, we could not configure it in the time available, or the underlying process was not ready to be automated. They lead to different next steps, and only the first is a reason to change vendor.
Keep the migrated sample, the acceptance record and the reconciliation, whatever you decide. If you run a second evaluation they are the fastest thing you own, and they are the basis of the commercial conversation with the vendor whose product did not pass.
Write the pilot charter before day 1
One page, agreed by the sponsor before the pilot starts. It pulls the decisions above into a single record. This is an editorial template: adapt every line to your own pilot.
- Workflow, site and users: The one workflow, the site and the named pilot users, including the shifts they work.
- Owners: Sponsor, process owner, administrator, IT and data owner, and the person who can reject acceptance or stop the pilot.
- Availability: Named people, the days they are available and what they will stop doing while the pilot runs.
- Environment: The product, edition and version, and whether the pilot runs on the production plan.
- Data: What is migrated, the sample used and the reconciliation rule; what stays in the old system.
- Acceptance criteria: The scenarios and the measures, each with a baseline, denominator and owner; critical gates apart from preferences.
- Fallback: What users do when the system is unavailable or a gate fails, and until when.
- Stop conditions: What would make us stop, and what we keep (the sample, the acceptance record and the reconciliation) if we do.
- Exit and costs: The cost of the pilot, the cost of leaving, and the contract terms that apply if we do not proceed.
Research basis and limits
HSE describes ongoing planning, implementation, monitoring and review, with worker involvement. That management principle informs the pilot design; HSE does not prescribe this software timetable, role model or KPI set. Its legal context is Great Britain. HSE management guidance, checked 19 September 2026.
This is an editorial implementation plan, not firsthand vendor testing, certification advice or a measured ROI claim. Establish applicable sector requirements and your own assurance responsibilities before acceptance.
Pick pilot candidates from a rule-based list, then test the conditions you set
An implementation plan describes how to test a product, not which one to test, so this page carries no product list of its own. Take candidates from the guide whose rule matches the pilot's workflow: each one applies the same published rule to every researched profile (a catalogue tag plus a sourced capability) and says how many products meet it. Then add the conditions your pilot depends on and filter again with the lists below.
- For a pilot that mixes quality and safety records, start from the QHSE list; for incidents and environmental records only, from the EHS list.
- If the pilot site has weak coverage or relies on phones, check the offline capture list and the mobile access list against the preparation steps in each profile.
- If the acceptance gate needs a record to reach a maintenance, workforce or reporting system, use the integration guide and its list of profiles that document an interface.
- If a vendor proposes AI drafting or classification inside the pilot, keep it out of the first acceptance gate unless the AI guide questions have written answers.
Prepare the decision before the pilot
Related guides
- Digital Safety Management: A Practical Pilot Brief
Evaluation brief on digital safety management.
- EHS Software Selection Checklist
Evaluation brief on an EHS software selection checklist.
- Unified QHSE vs Point Solutions: Build the Cost Case
Evaluation brief on unified QHSE versus point solutions.
- Leaving a QHSE System: Data Export and EU Data Act Switching
Article on what to export when leaving a QHSE system, and the EU Data Act switching terms.
- All QHSE, EHS & ESG Software — A–Z
Directory of every researched product, in alphabetical order.