Deployment Changes the Problem
Some requirements only exist once real work is running, which makes a live operation the one place you can find them.
The assumption underneath most delivery
Most delivery models treat deployment as the end of a process of finding out. You gather the requirements, build the thing, test it against what you gathered and release it, and release is the moment the knowing stops and the operating begins.
That sequence quietly assumes two things: that every requirement could be discovered in advance, and that testing can stand in for use. Neither holds, and the gap between them isn't something more rigor will close.
None of this makes the assumption foolish, it comes from places where it holds. If you're building a bridge, the load conditions are known before the first drawing, and they don't adapt to the bridge. Operations differ in one specific way. The thing being served is made of people who change their behavior in response to the system, so the requirements are partly a product of the design and only partly an input to it. Any method that treats them as fixed inputs will be right about the stable half and blind to the rest.
What only appears under load
Volume changes behavior. A step that's reasonable once an hour becomes intolerable forty times an hour, and the change isn't linear, because people start batching, deferring and working around it.
Exceptions arrive at rates nobody predicts, too. In a design conversation the exception is a footnote, but in the operation it's often a third of the cases, each one slightly different, and handling them is where the real cost lives.
Meanwhile people route around anything inconvenient almost immediately, because habit is faster than policy, and they do it quietly, so the system looks like it's working while the actual path has already moved somewhere else.
Incentives have their say as well. A system that makes someone's number look worse will get used differently from how it was demonstrated, whatever anyone agreed to in a meeting.
There's also the question of what the data turns out to be. Every operation has fields that are nominally structured and actually free text, categories that stopped meaning what they say around the time of the last migration, and identifiers that are unique in one system and not in another. You can't discover any of this from a schema, because the schema describes the intent. What shows it to you is the first real run, usually as a handful of records that fail in some interesting way and turn out to represent a whole category nobody had named.
An example of a requirement that could not exist earlier
I worked on an operational system in a regulated environment where compliance had been built as a review layer sitting after the work. On paper that's the defensible design: it's auditable, the responsibility is clear, and it separates the checking from the doing.
What that design did in practice was put a stop between demand and delivery. Every unit of work was completed and then waited to be checked, and the organization couldn't turn incoming demand into finished work quickly enough to meet what the market was offering. You wouldn't have found that constraint anywhere in the requirements, because it belongs to the arrangement running at volume, and no single requirement carries it.
I want to be precise about why no earlier analysis would have caught it. Each individual requirement was satisfied by the review layer, and satisfied well. The review was thorough, correctly staffed and completed within its own service expectation, so nothing about it was failing. The constraint exists only in the relationship between the review's throughput and the rate of incoming demand, and that relationship belongs to neither the review nor the demand considered separately. You only get it when the two run against each other, which happens live and nowhere else.
The system that changed the outcome embedded the regulatory requirements inside the workflow, so the check happened as part of doing the work, and within three months that produced new client revenue. What I find more interesting than the result is that no amount of pre-deployment analysis would have surfaced the constraint, because before deployment there was nothing to be constrained.
The deployment ends up correcting the specification it was supposed to be testing.
Why this is not a testing failure
The natural response is that the testing was inadequate, and occasionally it was, though usually it wasn't.
A test checks that a system does what it was specified to do. Most of the problems that show up at deployment come from the specification itself turning out to have been about the wrong thing, and no test can catch that, because the test was written from the same understanding that produced the design.
Pilots and staging environments soften this without solving it, and it's worth knowing which part they do solve, which is the mechanics: the integrations, the data shapes, the performance under synthetic volume. What they can't reproduce are the incentives, since nobody's number depends on a pilot, or the exception mix, since the cases fed into a pilot are chosen by someone who wants it to work. A pilot that runs cleanly has told you the system functions, and very little about whether the operation will adopt it.
You can't test your way to a requirement you didn't know existed. All you can do is run the work and watch.
Designing for the second pass
If deployment produces information, the sensible response is to plan on using it.
Planning on it changes what you build first. The smallest sufficient version becomes the cheapest instrument for learning what the operation is actually like, and the budget gets spent differently too, because capacity held back for what production teaches is worth more than a more complete first version built from worse information.
What you instrument shifts as well. If the first release is an instrument, it needs to record the things that will tell you the design was wrong, alongside the things that confirm it's working: where work stopped and for how long, which cases got handled outside the system, what people typed into the field that was supposed to be a fixed list. Those are the measurements that pay for the second pass, and they're almost never in the original requirements, because nobody specifies a system to report on its own inadequacy.
And then there's what you promise. A commitment to a fixed scope at a fixed date is a commitment to ignore whatever deployment reveals. Organizations make that commitment all the time, and then read the change requests that follow as a planning failure, which is a strange way to describe a system doing exactly what it should.
The uncomfortable version
Taken seriously, this means the design stays provisional until real work has run through it, and no amount of care beforehand changes that.
Saying so to a sponsor who wants certainty, and is paying for it, is hard. The honest position is that the certainty is available, just later than anyone would like, and that a plan which admits this is more reliable than one that doesn't. The plan that pretends otherwise carries the same uncertainty anyway, undeclared, and it arrives later and costs more.
There's a version of this a sponsor can accept, and it doesn't ask for open-ended scope. Commit firmly to the outcome and the budget and hold the shape of the solution provisionally between them, which gives the sponsor the two things they actually need to defend the spend and gives the work the one thing it needs to be any good. Most disagreements about agility turn out to be disagreements about which of those three is being fixed, and they settle quickly once someone says it out loud.
If this describes an operation you’re responsible for, the diagnostic is where that conversation starts.
How engagements begin
