There is no single buyer
On the deals we have worked, the group with a veto typically runs to six to eleven people: the executive whose budget it is, the technical evaluator who will inherit the integration, an information security reviewer, data protection or legal, procurement, and at least one manager of the team who will use the thing daily. Each can stop it. None can start it alone.
They are not evaluating the same product. The executive is evaluating whether this makes their number. The technical evaluator is evaluating how much of their weekend it will consume. Security is evaluating whether it becomes their incident. Procurement is evaluating whether the contract is defensible. A single deck aimed at all of them lands with none of them.
The practical consequence for a delivery team is that a pilot which delights users can still die, and usually dies quietly in one of the other five conversations. When a promising engagement stalls, the cause is almost never the demo.
The security review is a schedule risk, not a formality
For a regulated buyer, expect a full questionnaire — commonly a SIG Lite or the buyer's own variant, 200 to 400 questions — plus an independent penetration test report no older than twelve months, a data processing agreement, a sub-processor list, evidence of access controls and an incident response commitment with hours attached. Median elapsed time in our experience is five to seven weeks, and the long pole is almost always a single unanswered question waiting on one person.
Prepare the pack before it is requested: a data flow diagram naming every system that touches customer data, an answer bank maintained by someone accountable, and honest gaps marked as gaps with a remediation date. Buyers' security teams are far more tolerant of a dated commitment than of a confident answer that unravels on the follow-up call.
Where a model is involved, add the questions that have become standard since 2025: which provider, in which region, whether prompts or outputs are retained or used for training, how the vendor is prevented from seeing customer data, what the human oversight arrangement is, and how a decision is explained after the fact. Not having answers ready has cost projects a full quarter.
Pilots fail politically, not technically
The pattern is familiar: an eight-week pilot goes well, everyone is pleased, and nothing happens. The cause is nearly always scoping. Nobody agreed in writing what result would trigger a production decision, no production owner was named, and the money for year one was never in a budget line — so at the end there is a good outcome and no mechanism to act on it.
We scope pilots with three things fixed before the first line of code: a measurable baseline for the current process, a written exit criterion with a number in it, and the name of the person who owns the production rollout if that number is met. A pilot at Halden Group ran on the criterion that quotation turnaround must fall from a 4.2-day median to under 1.5 days on 200 real enquiries. It reached 1.1, and the production decision took nine days because the argument had already been settled.
Pick a workflow with a real baseline and a real owner, not the most interesting one. Interesting pilots produce admiration; boring pilots with measurable throughput produce budget.
Procurement is buying predictability
Procurement's job is to reduce the chance of an expensive surprise, and its instruments are contractual rather than technical. Fixed price against a tightly defined scope reads as low risk and is genuinely lower risk for the buyer when the scope really is knowable; time and materials with a capped rate card and a monthly review reads as risky unless the exit rights are clear. We generally recommend a fixed-price discovery of four to six weeks that produces the scope the larger fixed price is written against.
Whatever the shape, price the second year and put it in front of them. Hosting, support, model inference, licence uplifts and the cost of the next major version are the items that generate a difficult conversation in month fourteen. Naming them at signature is a small commercial cost and a large trust return.
Include the exit provisions without being asked: data export in a documented format within a stated number of days, source code escrow or a repository handover where it applies, and a defined transition period. Buyers who compare us with TCS, Infosys or Accenture are quietly measuring whether a firm of our size can be left safely, and a written exit answers that better than any reassurance.
Write the memo your champion has to defend
The decision is usually made in a room you are not in, by people reading a one-page summary written by your champion. The most useful thing you can produce is that page: the problem in the business's own words and numbers, the proposed scope, the cost across two years, the measurable outcome, and an honest risk section naming the two or three things most likely to go wrong and what happens if they do.
Champions who present only upside get challenged and lose. Champions who present the risks first are treated as credible and get the budget. We have seen the same proposal fail in January and pass in April on nothing but the addition of a candid risk section.
And be clear about the real competitor. It is rarely another firm; it is doing nothing for another year, which has a cost the business almost never quantifies. At Halden that cost was 340 engineering hours a month spent reconciling two systems by hand. Putting that figure on the page did more than any comparison table.