Automation projects rarely fail because the software is impossible. They fail because scope drifts, ownership is unclear, or the wrong people are at the table. A few scoping decisions made up front prevent most of that waste.
Most automation projects that disappoint do not fail because the software is impossible. The vendor may be competent. The client may be willing. And yet, somewhere between kickoff and a system actually running in production, the work loses momentum and quietly stops.
This is not surprising once you have seen it a few times. The reasons are predictable, and most of them sit in the contracting and scoping stage rather than in the work itself. Knowing the patterns is the first defense.
The scope drifts
The most common failure mode is open scope. The engagement starts as “we will build a lead qualification system” and, four weeks in, has expanded to include a CRM migration, a new analytics dashboard, and a reporting flow nobody asked for at kickoff. The client thought all of this was included. The vendor thought it was extra. By the time the misunderstanding surfaces, both sides have lost the appetite to continue.
Fixed scope is the fix. Not “fixed-ish” or “with some flexibility”. Fixed in writing, signed before any work starts, with a clean process for adding scope as separately quoted work. This feels rigid in the sales conversation. The rigidity is what saves the project.
The wrong stakeholders are at the table
Many AI projects are scoped with the operator who feels the pain, then handed off to a department head who does not. The operator wanted email triage. The department head wanted a strategic transformation roadmap. The vendor delivered email triage, which is what was scoped. The department head, six weeks in, feels the project is missing the point.
The fix is to do the scoping conversation with both people in the room. If the operator and the budget-holder have different mental models of what the project is for, the project is at risk before it starts. A good vendor surfaces this before signing, even when it costs them the engagement.
The handover is not designed in
A working system is delivered. A walkthrough happens. The vendor disappears. Three weeks later, an API key expires, the system breaks, and nobody on the client team knows where to look. Within a month, the system has been replaced by the manual process it was built to replace, and the project is treated as a failure even though the original work was sound.
This is a contracting failure, not a technical one. The handover should be designed in from the beginning: documentation written for the team that will run the system, training that goes deeper than a single demo, clear ownership of credentials and access, and a defined window for follow-up support. None of this is exotic, and it is routinely skipped.
The project drowns in committee
Some clients require approval from committees that did not exist when the project was scoped. The build is finished, the system is ready, and it cannot go live because three departments need to sign off on a security review, a procurement review, and a regulatory review that nobody mentioned at kickoff. By the time the reviews are done, the project has been shelved on a senior agenda, and nothing happens.
This is rare in SMEs, which is part of why we work with SMEs. In a 10 to 50 person business, the people who scope the work are usually the ones who can ship it. In a larger organisation, the gap between scoping and shipping is where projects go to die.
The vendor over-promised
Some AI vendors will say yes to anything in the sales conversation. Yes to scopes they cannot deliver, yes to timelines they cannot hit, yes to outcomes they cannot guarantee. The first month of the build catches up to reality, and the project is already behind expectations.
The pattern that prevents this is the audit step. Before quoting a build, spend a week with the workflow, look at the actual data, and write down what is realistic. The audit costs you both a small amount of money and a delay before kickoff. It saves you both an enormous amount of money and a much larger delay if the answer is “this is harder than it looked”.
What contracting decisions actually prevent these
Almost all of the failure modes above are prevented by four contracting decisions, made before the build:
- Scope is fixed and written down, with a clear process for adding work later.
- The operator who feels the pain and the budget-holder who pays the bill are both in the scoping conversation.
- Handover is designed in from day one and explicitly included in the deliverables.
- The work is preceded by an audit that produces a written read on whether the build is the right move at all.
This is roughly the operating model behind Bangkok Automation. None of it is novel. It is just contracting that takes the failure modes seriously rather than pretending they will not happen.
That is most of why projects ship. The technology was never the hard part.