Process has a bad reputation, and mostly it’s earned. Stage gates, acceptance criteria, RACI charts — in plenty of organizations these are ceremony, a way of looking managed rather than being managed. Anyone who has sat through a status meeting built entirely of green squares knows the feeling.
So the argument I want to make is a narrow one. Not that process makes you faster — it usually doesn’t, and building it costs time you rarely feel you have. The argument is that in any program depending on organizations you don’t control, structure is what makes a change of direction survivable.
Consider the shape of the problem. You’re connecting a platform to a few dozen external vendor systems. Every vendor is a different company, with different architecture, different security posture, and a wildly different level of technical maturity. Some know exactly what to do and do it. Others need your team working alongside them for weeks to stand up a connection, test it, and get it live. None of them report to you, and none of them have your deadline as their priority.
The first thing a stage model buys you in that environment isn’t coordination. It’s legibility.
The prevailing assumption — held by people not doing the work — is that this is easy. Turn on single sign-on, flip a switch, next vendor. That assumption is corrosive. It makes your timeline look like padding and your team look slow, and it starves the work of the attention it needs. Defining explicit stages, each with criteria that must be met before a vendor advances, does something before it improves a single handoff: it lets you show the organization the actual shape of the work.
“You cannot get support for work people believe is trivial.”
The second thing shows up later, and it’s the one worth building for.
At some point the requirements change. In multi-vendor work they always do — a security decision gets revisited, an identity provider gets swapped, a platform deprecates the thing you built against. Suddenly you have to unwind and rebuild across every vendor in flight.
Without structure, that means going back to each organization individually, reconstructing where they were, and renegotiating from scratch. It’s the kind of change that eats a quarter and doesn’t announce itself as a disaster until month two.
With it, you know exactly which stage every vendor occupies, which means you know what the change costs before you commit to it — and you can tailor the message. A vendor that hasn’t started needs different information than one already in testing. Blasting the same notice to both wastes the first and alarms the second.
The other asset, and it takes a year to build: knowing who inside your own organization actually holds the relationship with each vendor. That map is invisible on any org chart and it’s the difference between a message that lands and one that sits in an inbox.
A caution
The coordination story is easy to oversell. In this kind of work the technical effort is not the smaller half. Getting two systems to trust each other is real engineering, it varies enormously by vendor, and no amount of process substitutes for it. What structure does is make sure that effort goes in the right order, on the right vendors, with everyone able to see where it stands.
Which is the whole distinction. Ceremony produces the same artifacts — the stages, the criteria, the dashboards — and none of the benefit. The test isn’t whether the documents exist. It’s whether, on the day the requirements change, you can answer what it costs by the end of the afternoon.