Skip to Content
The JEFF method

One method from first qualification
to final closure.

JEFF is the operating system I built for selling and delivering industrial software. It keeps one register per project and generates the bid, the price, the specification, the test scripts and the status reports from it, so what was sold and what is delivered cannot drift apart. It works on MES, SCADA, DCS and PLC integration, historians and AI-assisted projects alike, and has run on more than ten bids and two delivery projects, so far in MES.

30+
Specialist skills, from bid qualification to closure
Versioned release, governed library
10+
Bids run through the method
Including a global consumer goods MES pursuit
P0–P9
Ten phases, a gate at the end of each
Same spine for a small change and a multi-site rollout
2
Review gates and a nine-pass evidence check before issue
A failed check stops the document
Any industrial software project

The method does not care what kind of system it is

The register, the gates, the generated documents and the release checks are the same whether the project is a plant-wide MES, a SCADA upgrade or a historian migration. Domain knowledge loads as a separate layer, so adding a new kind of system does not change the method.

MES and MOMSCADA and HMIDCS and PLC integrationHistorians and plant informationERP and OT integrationIndustrial software platformsAI-assisted sales and engineering
It starts before the contract

The sale is phase P0, not a preamble

What a proposal promises becomes the first requirement baseline, and what it excludes becomes the first scope boundary. Nothing gets re-argued in month four.

Qualify

MEDDPICC and a bid or no-bid test on every opportunity, before anyone writes a page.

Price

An estimation workbook behind every quote: cost against price, margins, phase hours, payment schedule. No number reaches a client without it.

Propose

Win themes backed by named evidence, and every commitment and exclusion loaded into the register the day the order arrives.

The problem it solves

Four documents that agree on day one and drift apart by month four

An industrial software programme produces a proposal, a design, a test record and an acceptance. On most programmes each is written by hand, by different people, at different times.

Change requests are argued, not read

Nobody can show quickly whether a request was in the signed baseline, so whoever argues better wins.

Tests check what was built, not what was asked

Test scripts are written from the design. A requirement the design dropped is never tested.

The plant stops trusting the documents

Once the FDS and the system disagree, operators and engineers go back to spreadsheets and memory.

How it works

Five steps, run the same way on every engagement

Ingest

Every client document is coded with its date and version before anyone uses it. Nothing is quoted from a file nobody logged.

Extract

Requirements are pulled out with the client's exact sentence and its location, then rationalised and put through a four-test quality gate.

Design

Functional design content (state models, screen behaviour, degraded modes, interface contracts) is generated from the register and reviewed by an engineer.

Test

FAT, SAT and UAT steps are generated against the requirements, so every requirement has a test and every test has a requirement.

Issue

Two review gates and a nine-pass check against the client's own sources run before release. Documents stay at v0.x until the client signs.

Close

Open items move to named owners, lessons go back into the method, and the closure report is generated from the same register.

The JEFF delivery spine: ten phases P0 Bid to P9 Close, with a gate between each
Traceability chain: client source, requirement, design item, document section, client response, test case, evidence, closure

Each link is a column in the register. That is what makes the answers below take seconds.

What you get

Hard questions answered in ten seconds

The questionWhat JEFF shows you
Where did this requirement come from?The client's own sentence, with the document code and the line it came from.
Is it built and tested?The design item, the test case, the FAT or SAT result and the evidence file.
Did we agree to it, and when?The client's response, the date, and the version of the document it was signed in.
Is this change our cost or theirs?Whether the requirement was in the signed baseline. It is a filter, not a negotiation.
Built for the people who sign

Your team sees a readable workbook and clear documents, never the machinery

The register is written by the tooling and nobody types into it. The client fills in a plain workbook. The documents are generated views. Keeping the three apart is what stops a client review drowning in rows.

Three surfaces: the register, the client workbook, the generated documents
Quality and AI governance

The method overrides the model

JEFF uses AI to do the heavy lifting on documents. The rules that govern it were written after real mistakes on real projects, and they bind every output.

Quality gates: generate, gate 1 faithful to the register, gate 2 readable by the person who signs, nine-pass evidence check, issue

Verify, never guess

A fact that can be checked is checked. What cannot be checked is marked as unconfirmed, in the document.

Engineer review on everything

No generated text reaches a client until an engineer has read it against the source.

Your data stays controlled

Client documents stay on controlled tooling under NDA and are not shared outside the engagement.

The plant has a veto

A design that will not survive a wet-clean changeover at 3am does not go out, however tidy it looks.

What sits inside

Thirty-plus skills covering the whole lifecycle

Each skill holds one discipline and the checks that go with it. The phase you are in decides which skills load, so a test script never picks up proposal language.

Win

Qualification and bid or no-bid, win strategy, proposals, estimation workbook, price presentation.

Specify

Evidence to requirements, the client review workbook, functional and detailed design.

Prove

FAT, SAT and UAT scripts traced to requirements, two review gates, evidence audit.

Run

Charter, RAID, weekly status, cutover and closure generated from one project register.

Domain

ISA-95 and ISA-88, OEE, HACCP and CCPs, CIP, thermal processing, hygienic design.

Platform

Deep AVEVA product and licensing knowledge today; design rules written to be vendor-neutral.

Release

Versioning, change notes, document integrity checks and the release ritual.

Learn

Lessons captured on every job, promoted into the method only after review.

Evidence

A two-month slip recovered on a global F&B MES design

A global snacks and beverage manufacturer needed an AVEVA MES functional design specification ahead of deployment. The work was budgeted at more than 900 hours and was running two months late.

What JEFF did
Turned the client's requirement specification and workshop transcripts into a traceable requirements baseline and a full FDS.
Team
Two people, working on it part-time.
Quality
Every requirement traced to the client's source documents; every document passed the QA gates before issue.
The two-month slip was recovered and the programme returned to plan.

See JEFF on a problem you have now.

Bring a URS, an RFP or a stalled specification to a 30-minute call. I will show you what the register would make of it.