20 January 20267 min read
There is a particular kind of failed engagement that is nobody's fault. The provider is competent, the buyer is serious, the rate is fair, and three months in both sides are frustrated and the thing that exists is not the thing anyone wanted. Trace it back and the cause is almost always the same: the project was not defined well enough to be handed to anyone, and both parties agreed to start anyway.
The confusion at the root of this is between complex and vague. They feel similar from inside and behave completely differently once work starts.
Complex outsources fine. Vague does not
A complex project is hard: many moving parts, difficult constraints, real engineering judgement required. But you can say what it must do and how you would know it worked. A payments integration with retry semantics and reconciliation is complex. It is also perfectly outsourceable, because correctness is checkable against something outside anyone's opinion.
A vague project is one where the requirements do not exist yet in any form, and the person who will decide them has not seen anything concrete to react to. A portal for our partners. Something to help the ops team. A dashboard for the leadership. These may be simple to build. They are not describable, and the difference between describable and simple is the whole issue.
Complexity costs you effort. Vagueness costs you the effort twice, once building the wrong thing and once building it again after someone finally sees it.
Three questions that expose it
Ask these about your own project before you ask a provider anything.
- Who decides this is finished, and have they said out loud what finished looks like? If the answer is that we will know it when we see it, the project is vague and the cost of that is now going to be discovered rather than planned.
- Could a competent stranger start on Monday? Not finish: start, without inventing requirements. If day one requires a decision only you can make, the brief is not a brief.
- Where does the description come from? A written document that several people have read and disagreed with in the margins is a specification. A description that has only ever been spoken is a wish, and everyone hearing it is hearing a slightly different version.
The third question is the most diagnostic and the least comfortable. Requirements that have never been written down have also never been tested for internal contradiction. Writing them is not administrative work, it is the moment you find out that two stakeholders wanted opposite things.
What happens if you outsource it anyway
The team starts. They have to make decisions to move at all, so they make them, sensibly, based on what they know, which is not much. Every one of those decisions is a small bet on what you meant. Some are right.
You see the result at the first demo, and it is subtly wrong in ways you could not have articulated beforehand but recognise instantly. This is not a failure of communication, it is how requirements actually get discovered: by reacting to something concrete. The problem is that you have discovered them on an expensive clock, and if the arrangement is fixed price, every correction is now a change request and the conversation acquires an edge.
There is a worse version. If the ambiguity is never resolved, the outside team fills the gap with defaults and the product quietly becomes whatever they were used to building. Nobody decided that. It is just what happens when questions go unanswered long enough that people stop asking.
Discovery, and how it goes wrong
The standard answer is to buy a discovery phase, and it is a reasonable answer. It goes wrong in three specific ways worth watching for.
- It produces a document nobody uses. If discovery ends in a slide deck rather than a backlog with acceptance criteria, you bought a summary of things you already knew.
- It is done by people who then leave. Discovery has value only if the understanding transfers to whoever builds. Ask whether the same people continue.
- It is open-ended. Discovery with no fixed duration expands to fill the budget. Fix the length, fix the deliverable, and accept that the answer may be that the project is not ready.
Done properly, a short discovery is one of the better purchases in this market: a fixed price on a small, bounded piece whose output is a scope good enough to price the rest, written by people who have now touched your systems rather than only heard about them.
How to make a vague project specific in about a week
You can usually do this internally, and it is cheaper than paying anyone to do it for you.
- Write the three things a user will do with it, in order, in one sentence each. If you cannot name a user, that is the finding.
- Draw the screens on paper, badly. Fidelity is irrelevant; the point is that a drawing forces decisions a sentence lets you avoid.
- Write the acceptance criteria for the first two weeks of work only. Not the whole project. Two weeks.
- Show all of it to the person who will sign it off and watch them react. Their objections are the requirements you were missing.
- Write down every question you could not answer. That list is the actual scope of your uncertainty, and it is what you should be discussing with a provider.
This takes an afternoon or two of real attention. It is unpleasant, which is why it gets skipped, and it removes the largest single source of waste in outsourced work.
When vagueness is fine, if you buy it deliberately
None of this means you must have certainty before starting. Genuinely exploratory work exists and has to be done by somebody. It just has to be bought as exploration rather than as delivery.
That means time and materials with a capped budget, a checkpoint every two weeks with a real working artefact, and an explicit agreement that direction will change. It means staff augmentation, where you steer daily, rather than managed delivery against a scope everyone privately knows is a guess. And it means a provider whose working day overlaps yours enough for a question to be answered the same day, because in exploratory work the rate of questions is the rate of progress.
What causes the damage is not uncertainty. It is uncertainty dressed as a specification, priced as if it were one, and signed by two parties who both suspected it was not.