A global aerospace manufacturer and an international logistics partner needed a governed SaaS platform to run the movement of aerospace components — items ranging from small parts to assemblies that require specialist international transport.

The operation being replaced ran largely on manual process, accumulated convention and the knowledge of the people who had always done it. Multiple organisations were involved, each with its own systems, vocabulary and idea of where the process began and ended.

I contributed as a Business Analyst within a cross-organisation delivery team. The work was to turn an undocumented, contested process into a specification an engineering team could build from — and then to stay with it through development, testing and handover so the built system still matched what had been agreed.

I did not lead the programme. The value I added was in the connective work: facilitating the sessions where the real process surfaced, making it tangible as prototypes, writing it down precisely, and holding that record steady as the build progressed.

Discovery started with the assumption that everyone was telling the truth and no two accounts would match. Facilitated sessions were run to get the competing versions into the same room, where the contradictions became visible and could be resolved by the people who owned them rather than by the analyst guessing.

The prototype was the analytical instrument, not the deliverable. Written requirements get nodded at; a clickable screen gets argued with. Putting an interactive Axure prototype in front of stakeholders reliably surfaced constraints that had gone unmentioned for weeks — because it is much easier to say "that field is wrong" than to describe a field from memory.

The field dictionary came out of the same instinct. Once each data element had one definition, one type, one source and one owner, a whole class of downstream disagreement simply stopped occurring.

A governed SaaS platform replacing manual coordination for international component movement, specified through an interactive prototype, a PRD and a field dictionary that together formed the single source of truth for the build.

The specification was deliberately treated as a maintained artefact rather than a document produced once. As the build raised questions, answers went back into the specification, so what shipped and what was agreed stayed the same thing.

Functional testing was written from the process rather than the interface. Testing what the screens do finds interface bugs; testing what the business does finds the cases where the built logic and the agreed logic have quietly diverged.

Defects were documented with the business context needed to reproduce them, which shortened the loop considerably — an engineer given the scenario and the reason usually needs no follow-up conversation.

The deliverable everyone asks for is the specification; the deliverable that actually moves a project is the prototype, because it converts vague agreement into specific disagreement early enough to be cheap.

In cross-organisation work, most apparent requirement conflicts are vocabulary conflicts. A large share of the analysis was establishing that two teams using different words meant the same thing — and, less often but more importantly, that two teams using the same word did not.

Staying with a specification through testing and handover changes what you write. Knowing you will be the one testing it, and the one writing the manual, produces noticeably more precise requirements than writing a document you will never meet again.