Notes from the Practice: Why I Built Module Standardisation Intelligence

Engineering organisations are not short of data. Every delivered module leaves behind a trail: dimensions, dry and operating weights, centre of gravity, fabrication hours, procurement costs, schedule performance, and — buried in close-out reports nobody reopens — hard-won lessons learned. The problem is that this trail is scattered across project servers, spreadsheets, individual hard drives, and the heads of senior engineers who are, increasingly, retiring.

So when a new requirement lands, the knowledge that should inform it is technically somewhere but practically nowhere. The result is what I call bespoke-by-default: every module treated as a first-of-a-kind, even when it is the fortieth of its kind. The costs of this are not abstract. They show up as weak early cost and schedule certainty, as repeated bespoke design effort, as standardisation decisions that drag because no one can quantify the reuse case fast enough to put it in front of a gate review.

The reflex answer in the industry has been "standardise more." I agree with the goal, but standardisation is not a poster on the wall or a template library that goes stale the day it is published. Standardisation is a decision — one made dozens of times a year, at concept stage, under time pressure, usually without the evidence at hand. If you want better standardisation, you have to make that decision easier, faster, and better-informed at the exact moment it is taken. That is a software problem as much as an engineering one.

MSI captures historical modules, reusable engineering solutions, fabrication knowledge, weight and cost information, and schedule performance — and then, when a new requirement arrives, it recommends the right path forward from the organisation's own delivery history.

In practice, an engineer or project lead describes a new module requirement. MSI does several things in response. It searches the delivered-module catalogue for similar designs and surfaces the closest matches. It checks the new requirement against approved standard templates. It produces preliminary estimates for dry weight (with contingency bands), centre of gravity, engineering hours from concept to FEED, fabrication cost broken down across steel, piping, vessels, procurement and logistics, and an indicative project schedule with milestones and lead times. And it generates a delivery risk profile drawn from the lessons learned attached to comparable past modules — the flags that, in a bespoke process, only resurface after they have become problems again.

The output is not a drawing set. It is a concept-stage decision support package: a recommendation report, an executive dashboard view of reuse potential and standardisation maturity, and a defensible set of early estimates that an engineering manager can take into a management gate review and a project director can stand behind. That distinction matters. MSI is built to make a business decision quickly and credibly, not to replace detailed design.

The dashboard layer is deliberately aimed upward, at the people who fund and steer programmes. Standardisation has always been easy to endorse and hard to govern, because the savings live in counterfactuals — the design effort you didn't repeat, the contingency you didn't need to carry. By tracking standardisation level and reuse across a portfolio of modules, MSI makes those counterfactuals legible: a steering committee can see how much of a programme is being built from proven envelopes versus from scratch, and where the next reuse opportunity sits. For a leadership team — or an investor looking at where engineering productivity actually comes from — that turns standardisation from a slogan into a metric you can manage.

The clearest way to show what this means is the example I use in the live demo — an FPSO chemical injection package, one of the most repeatable topsides modules in offshore production.

Considered as a one-off, a chemical injection package is a non-trivial design exercise: tanks, dosing pumps, instrumentation, containment, structural frame, the works. Considered through MSI, it is something quite different. The platform recognises it as a member of a well-populated family. It pulls the comparable packages an organisation has delivered, shows how their weights and costs actually landed against estimate, and proposes a weight and COG envelope grounded in real equipment arrangements rather than a rule-of-thumb allowance. It benchmarks the engineering hours against what similar packages genuinely consumed. And it carries forward the risk flags — the layout clash that cost two weeks last time, the long-lead dosing pump, the containment detail that failed a review — so they are visible at concept, not rediscovered at fabrication.

What used to be a blank-page exercise becomes a comparison-and-adjustment exercise. That is the whole point. The engineer's judgement is still central; what changes is that the judgement is now applied to evidence instead of to a blank page.

I designed MSI around offshore production modules because that is where my practice is deepest and where the repeatability is most obvious. But the underlying logic — delivered modules are reusable intelligence — is not specific to floating production. It holds anywhere modules repeat across projects and where early business decisions hinge on weight, cost, schedule and risk certainty.

The same engine applies to fixed-platform deck modules, equipment skids and compression packages; to offshore substation transformer bays and array-cable interface modules for floating wind; to process, separation and injection packages generally; and to pipe rack and manifold assemblies. It applies onshore just as readily — to factory-built modular construction, process and electrical modules, data halls and volumetric units, where standardisation and reuse are the entire commercial premise. Anywhere a team is tempted to design something "from scratch" that the organisation has, in truth, built many times, MSI is doing the same job: converting institutional delivery history into a fast, defensible answer to "have we done this before, and what did it actually cost us?"

For an EPC contractor, that translates directly into competitive tendering — sharper estimates, faster turnarounds, and a documented basis for the numbers. For an operator, it means standardisation programmes that can finally be quantified and steered with evidence rather than aspiration.

A word on how MSI is built, because it reflects a conviction that runs through everything in my practice. The similarity matching and estimation in MSI are rule-based and transparent. There is no black-box model issuing a number that no one can interrogate.

This is a deliberate choice, and an important one for this audience. In high-consequence engineering, an estimate is only as useful as it is defensible. When MSI proposes a weight, a cost band or a risk level, an engineer needs to see why — which historical modules drove the recommendation, what contingency was applied, which assumptions underpin it. A recommendation that cannot survive technical review is worse than no recommendation at all, because it invites false confidence. MSI uses modern infrastructure — vector similarity search over the module catalogue, language models for report generation and natural-language search — but the engineering logic that produces a number a steering committee will act on stays auditable. AI earns its place where it genuinely helps, and stops where it would compromise defensibility. That is the same discipline I bring to surrogate modelling and simulation on the consultancy side of the practice.

One of the things I wanted MSI to avoid is the enterprise-software trap: a two-year rollout before anyone sees value. The platform is designed to prove itself on a client's own module types in a matter of weeks, not quarters.

A pilot typically runs six to eight weeks. It begins with configuring the platform for the organisation's sectors and ingesting an initial set of historical modules — name, type, dimensions, dry and operating weight, cost and schedule, fabrication hours where available, and lessons learned. A standard template catalogue and an equipment library are loaded alongside. Then we run one to three recommendation studies against live requirements the client is actually facing, deliver an executive dashboard and client-ready recommendation reports, and close with a read-out to engineering and project leadership. The data comes from spreadsheets and structured exports the organisation already has; MSI supplies the templates. The deliverable at the end is not a promise — it is a working tenant loaded with the client's own modules and a set of studies they can take into real decisions.

I built MSI through IS Applied Intelligence because it sits exactly where I want the practice to operate: at the intersection of deep offshore engineering judgement and software that scales that judgement. It is part of a small family of platforms I am developing — alongside fabrication delivery and weight intelligence tools — that share one premise: the most valuable asset an engineering organisation owns is its own delivery history, and almost nobody is using it.

The industry is under pressure to deliver faster, lighter and cheaper, on energy transition timelines that do not forgive slow standardisation. The organisations that win will be the ones that stop redesigning what they have already built and start treating every delivered module as an asset that makes the next one quicker and more certain. That is the shift MSI is built to enable — from project-based design to reusable intelligence.

These are still early days. The platform is live, the demo is real, and the pilot programme is open. If you run an EPC, offshore, renewable or modular delivery portfolio and the pattern I opened with sounds familiar — the blank page that should never have been blank — I would be glad to show you what your own delivery history looks like through it.