The story

Pear MS started as one form, in 2010.

It took sixteen years to become a system. This page tells you how.

2010

The form that started it

A daily progress report.

In 2010 we built a structured Daily Progress Report tool for a North Sea offshore-wind installation campaign. A digital form bound to a project database that lived on the vessel — paper replaced with one source of truth, captured at point of work. It kept improving, revision after revision, as the crews told us what they needed.

We weren't trying to invent anything. The tool replaced a paper sheet that the night-shift engineer had been filling in for years; the database replaced a folder of monthly summaries the project office stitched together at the end of every month and never looked at again.

What surprised us was what happened the moment the data started flowing into one place. We could suddenly answer questions the project leadership had been asking for years and never had a clean way to: which crews are losing the most hours to weather, broken down by shift? How long does a typical jacket installation actually take, controlling for vessel and wind? Which control measure was in place when this near-miss happened — and was the same measure missing from the three near-misses before it?

The answers were always there. They just lived in seven different folders, in nine different file formats, on five different vessels, with three different versions of the truth.

One source. One touch. Total trace. — the rule that emerged in 2010, written into Pear MS sixteen years later

2010 — 2025

Sixteen years of patterns

The same problem, on thirty-two projects.

Over the next sixteen years our team worked on projects across the UK, the German Bight, the Irish Sea, the Kattegat, the Dutch IJsselmeer, and — most recently — the US East Coast. Different contractors, different turbine OEMs, different regulators, different vessel fleets. The same operational problem.

Every project rebuilt the same workflow from scratch. Every project carried forward roughly 30% of the lessons from the last one and re-learned the other 70% the hard way. Every project's data went into a folder when the campaign ended.

What we started doing, first as a side project and then more seriously, was paying attention to what each campaign left behind: what worked, what failed, what got re-learned. The oldest lessons reach back past our own form, to the literal foundations of offshore wind and MT Højgaard’s pioneering installation campaigns. MTH no longer operates in offshore wind; the team carries that first-mover legacy on. By 2024 that experience spanned 32 named installations across two decades of campaigns. Broad enough to spot the patterns. Long enough to trust them. And close enough to the work that we can still trace any lesson back to the project, the shift, and the activity it came from.

The patterns were stubborn. Risk assessments are written, then the work begins, then the conditions change, and the RA never gets revised. Incidents are investigated to "human factors" because the form has a tickbox for it. CAPA actions are closed by the same person who opened them, the same week, with no verification. Daily progress is logged against codes that were defined for a different contract and never updated.

Over sixteen years we watched these patterns repeat across every project our team worked on. They were not a contractor problem. They were not a regulator problem. They were a tooling problem — the operational systems made the right thing slightly harder than the wrong thing, and over thousands of small decisions, the curve bent the wrong way.

2025 — 2026

The decision to build

Why now, and why not earlier.

For sixteen years our work was simple to state and hard to do: serve the industry's projects and help keep people safe and the environment pristine. The system question stayed in the background. We assumed that sooner or later a serious vendor would ship the IMS the work needed.

The tools that arrived never quite fit the work. Enterprise EHS suites came adapted from other sectors, with hazard taxonomies and price points that sat awkwardly on an offshore-wind deck. Lightweight checklist apps served the small end well but left the structure behind. Crews in the middle kept improvising, and so did we.

By late 2025 we decided the most useful thing we could do with the knowledge those years gave us was to build it, and to build it with the industry rather than at it. Pear MS is that build. Every design rule it enforces traces back to something those projects taught us, usually more than once, on more than one project, over many years. The goal is not to declare anyone wrong. It is to help an industry we care about get even better at keeping its people safe and its waters clean, in collaboration with the contractors, operators and regulators who do the work.

The acronym in the name is the operating procedure. People, Environment, Assets, Reputation — in that order, immune to whoever owns the company this quarter, written into the brand so it cannot be quietly reordered. The engineering rule is the same: one source, one touch, total trace.

What we are not

The honest limits.

A short page on what Pear MS is not, because the longer it stays unsaid the less you can trust what it is.

Pear MS is not

A generic EHS suite. The hazard taxonomy, control catalogues, and progress codes are calibrated to offshore-wind installation and early operations. Adapting it to other sectors would mean rebuilding the calibration, which we are not doing.
A replacement for an organisation's management system. It is structural support inside one — the IMS-shaped tool the data was always asking for, not the certificate.
A VC-backed scale-up chasing land-grab. Small team, deliberate cadence, customer-funded growth. We don't have a sales department; you'll be talking to the people building it.
A general-purpose risk-assessment library that could be deployed in any industry next week. Every assumption inside the schema is grounded in offshore-wind operational reality. Adapting it elsewhere would be honest work, not a config switch.

If you're looking for one of the things on that list, we're not the right vendor and we'd rather tell you in the first email than the third meeting.

If the patterns above sound familiar, let's talk.

We'd rather hear about the operational problem you're stuck on than recite our feature list. Tell us your sector, your projects, and the question your current system can't answer — we'll tell you whether Pear MS is the right shape for the problem.

Start a conversation