Deals You Don't Control
Three situations where the shape of the thing was decided without you. None of them is a failure, and all three have a correct move that is neither rolling over nor fighting the room.
Most of this manual assumes you are in early enough to shape things — you run the discovery, you influence the criteria, you design the answer. A large fraction of real work is not like that. You get handed a deal a vendor has already sold in. A decision arrives from a level above the process you were running. Or you scoped it perfectly and it quietly drifted after you handed it over. Each feels like a loss of control, and each is common enough to deserve a practised response.
1. The vendor got there first
A business unit and a product vendor have been talking for weeks. By the time you are involved the product is chosen, a demo has happened, and there is enthusiasm in the room. You are expected either to bless it or to be the obstacle.
Fighting it fails, and not because you are wrong. The choice has social momentum and somebody's name is on it. Arriving as the person who says "this is the wrong product" spends every unit of credibility you have on day one, before you have the standing to spend any. The move that works is to separate two lists and hand over both, in writing:
| List | What goes in it | Who owns it |
|---|---|---|
| What the business can decide for itself | The functional capabilities they were excited about — the things this product genuinely does that they genuinely want | Them. Leave it alone; it was never yours |
| What must be resolved before it can safely proceed | The integration points, the identity model, data residency and licensing constraints, the assumptions the vendor's design makes that the organisation does not permit. Each one marked with what it risks and what would close it | You. This is the entire value you add to a decision already made |
This lets the decision stand and makes its conditions visible. Nobody has to lose, and you have established what you are for — which is precisely the standing you need to be brought in earlier next time. Arriving late once is circumstance. Arriving late repeatedly means you never demonstrated what earlier would have bought them.
2. The decision came from above the process
You have spent weeks with a stakeholder, mapped it properly, built the case — and someone senior enough to override all of it decides otherwise, for reasons that were never inside your scope. This is routine in government and in any large enterprise, and it is not a sign the work was wasted.
The mistake is to keep arguing after the decision has become real. The correct move is to convert the objection into a recorded risk: state plainly what you believe will happen, what it would cost, what would mitigate it — put it somewhere durable — and then help the thing succeed.
That is neither capitulation nor covering yourself. A raised and accepted risk is a legitimate organisational outcome: the business has chosen to carry something knowingly, which is an entirely different state from carrying it blindly. It is also, practically, how you get consulted earlier next time. People remember who told them once, calmly, in writing, and did not say it again afterwards.
Check one thing before concluding you were overruled, though: was the person you spent those weeks with actually the decision‑maker? Weeks invested in someone who cannot decide is the most common way this situation gets created in the first place, and it is a qualification failure rather than a political one — see Economic Buyer in Module 06.
3. It drifted after you handed over
What got delivered is not what you scoped. Usually nobody did anything wrong: the customer asked delivery for something reasonable mid‑flight, a vendor configured something directly, a constraint turned out differently than assumed. Every individual change was small and defensible. The aggregate is a solution that no longer matches the narrative you sold, or the assumptions the commercials rested on.
This matters to pre‑sales more than to anyone else for a structural reason: you are the only person holding both halves. Delivery holds the design. Sales holds the promise. Nobody else is watching the gap between them.
- Write the approach, not just the scope (MSP 04). Guardrails give the delivery team something to point at when they are asked mid‑project to chase a feature the vendor has not properly shipped yet.
- Name the change path. Anything outside scope goes back through the person who wrote the scope — not for control's sake, but so the technical and commercial consequences get considered in the same conversation rather than separately.
- Stay reachable on strategic accounts. In an MSP the pre/post boundary blurs constantly anyway. Being the person delivery is willing to ring is worth more than any document you could write.
- One checkpoint at the point of no return. Not a status meeting — one deliberate look at "is this still the thing we sold?" before it goes live and becomes the customer's experience.