Context
A global software client needed an integration platform to move data between systems that had grown up independently and had no contract between them. What made this unusual wasn't the technical problem — it was the starting position. There was no business requirements document, no agreed architecture, no provisioned infrastructure, and no single stakeholder who could describe the whole system. There was a date.
I owned requirements, architecture direction, and stakeholder alignment. Engineering owned the build.
The problem
Three groups each described a different system when asked what the platform was for. One wanted a data pipeline, one wanted a self-serve configuration tool, and one wanted an audit trail. All three were right about their own need and all three assumed the others agreed with them. Left alone, this resolves in one of two ways: a scope that satisfies nobody, or a discovery phase that eats the timeline.
Constraints
- No BRD and no time to write one properly. A traditional requirements cycle would have consumed a third of the schedule before a line of code existed.
- No infrastructure. Environments, access, and deployment pipeline all had to be stood up in parallel with definition.
- Distributed stakeholders across time zones, with limited overlapping hours for the conversations that actually resolve disagreement.
- A team new to this problem shape, which meant estimates were unreliable early and I had to plan for that rather than pretend otherwise.
What I did
Wrote the problem statement before anyone wrote a requirement. Two pages, circulated in week one: what the platform is for, what it explicitly is not for, and the three decisions we were deferring on purpose. Everything after that was an argument against a written baseline instead of an argument between memories of meetings.
Made the artefact settle the disagreement. Rather than run more alignment workshops, I pushed for a thin end-to-end slice — one integration, running, in a real environment — inside the first few weeks. Watching data move through the system collapsed weeks of theoretical debate about the configuration model into a single afternoon of concrete feedback.
Sequenced infrastructure as a product dependency, not an IT ticket. Environment provisioning went on the same board as feature work with the same visibility, because the fastest way to lose a 90-day timeline is to discover in week eight that nobody owns the deployment path.
Held a hard line on the deferred list. The three deferred decisions from the week-one document stayed deferred. Each one was revisited exactly once, with the evidence we'd gathered in the interim, rather than relitigated continuously.
Ran architecture direction with engineering rather than at them. I brought a position on the integration model and the tenancy boundary and expected it to be argued with — which it was, and it improved.
Outcome
The platform went to production inside the three-month window, in a setting that started with no written requirements and no environment to deploy into. More durable than the date: the client had a single shared description of what the platform was, which is the thing that determines whether phase two is an extension or a rewrite.
What I'd do differently
I under-invested in the operational handover. We optimised hard for shipping and left runbooks, alerting thresholds, and on-call ownership until near the end, which made the last two weeks tighter than they needed to be. On the next zero-to-one under time pressure I'd put the operational definition of done into the week-one document alongside everything else.