Why automation projects take so long

Where the time actually goes

The build weeks are predictable. The gaps between them are not, and those gaps are where a project planned for weeks stretches into months. The fix is almost entirely preparation rather than effort, which is good news, because preparation is something you can do before anyone is engaged.

Read the causes below as things to sort out before you start, not as things that go wrong. Some slowness is ours. The audit and the integration report are the supplier's responsibility, and when either arrives late, the date slips and that delay is ours to own, not yours to carry.

Waiting on access to the systems

Nothing gets connected until somebody can connect to it. That means logins, admin rights, an API key, a plan that includes the feature, or an account owner who is on holiday and is the only person who can approve the request.

This one is rarely refused. It is just slow, because the request usually lands with somebody who was not in the audit, does not know why it is needed, and is sensibly cautious about handing over access to anything. Days lost on each tool add up quickly across a whole stack.

The fix is boring and it works. We list every account and permission we need by name, in writing, with the reason next to each one, before the build starts. You take that list to whoever holds the keys once rather than many times. Where read only is enough, the list says so, which makes the conversation much shorter.

Ownership belongs on the same list. Accounts are registered in your own name from the first day, and admin rights are held by somebody inside the business who is not the person on leave, so nobody waits for a supplier to grant something back.

Occasionally a tool simply will not allow what is needed, and it is far better to find that out at the start than months in. Some software will not let an outside system create or update a record, whatever the sales page implies, and the integration report exists to say that out loud before anyone spends money.

Waiting on a decision nobody is authorised to make

A build produces a decision every couple of days. What does the system say when a customer asks for a discount. Which person does an unusual enquiry go to. Is this reply allowed to go out without somebody reading it first. Each one has a short answer and can sit for a fortnight if the person who can give it was not in the room.

The people in the project usually know the right answer. What they lack is the authority to commit to it, so the question becomes an email, then an agenda item, then something raised at the wrong moment in a busy week.

The useful step is naming, before the start, who can decide what without escalating. One person with authority over operational questions, available for short conversations rather than long meetings, is worth more to a timeline than any amount of project management. If that person is you, block the time. It is a small amount of time that lands at unpredictable moments.

The decision wait also has a version that never ends, so it is worth designing rather than enduring. Every workflow gets a stop before it goes live: money, pricing, anything published in your name and any serious complaint wait for human approval, and a case outside the rules is handed to a person.

Settling those stops once, in the audit, removes a whole category of the every-couple-of-days decisions, because most of them turn out to be the same question about who is allowed to say yes.

Waiting on content and data that was promised

The system needs your prices, your policies, your service list, your terms and the answers your best person gives to the questions customers actually ask. Most businesses have all of that, spread across a website, a folder, several people's memories and a spreadsheet somebody built in a hurry.

Gathering it is a job, and it tends to be handed to whoever is already busiest. It also surfaces disagreements, because two people in the same company often answer the same customer question differently and neither knew.

Data has the same shape. Exporting the customer list is easy. Deciding which of several versions of a contact is the real one is not, and cleaning it is real work that happens either before the build or during it. There is no version where it does not happen at all.

The practical move is to start collecting while the audit is running rather than after it. A rough folder with the price list, the terms, the questions customers ask most and one clean export is enough to keep the build moving while the tidier version is assembled.

The process turns out not to be written down

This is the one that surprises people, and it is the most valuable thing a project uncovers. Early on, somebody asks what happens after a customer confirms. It emerges that several people do it several different ways, all defensible, none recorded anywhere.

Automation cannot proceed past that point, because a system needs one answer rather than three. So the project pauses while the business decides how it wants that step to work. That feels like a delay and is really the business doing work it had been postponing for years.

The honest framing is that the automation did not create the problem. It found it. Sometimes a step gets deleted rather than automated, because once it is written down nobody can explain why it existed. That is the cheapest result available and it happens more often than you would expect.

This is the wait your own team has to solve, and no supplier can solve it for you. Writing the process down in-house before anybody is engaged turns the most expensive wait in this article into an afternoon, and it is worth doing even if the build never happens.

If a process underneath is genuinely broken, automating it makes the wrong thing happen faster and more often. Fixing or removing the step first is not scope creep. It is the only order that produces something worth having. Our page on common AI automation mistakes covers what happens when that order is skipped.

Scope that grows quietly

Waiting is the main cause, but a second one hides behind it. A project is agreed, the build starts, and somebody has a good idea in the middle. It is added informally because it seems small. Then another follows. Nothing is refused and nothing is priced, and the finish line moves without anyone deciding to move it.

Our rule is that a new idea becomes the next phase, quoted first and never added quietly. It protects the date you were given and it protects your budget, and it means the idea gets proper attention rather than squeezing into a build that is already full. It also keeps the first system live sooner, which is usually what you wanted in the first place.

What finished projects delivered

These results show what live systems did, not how long they took.

Business and country	Measured result	What the figure measures
RTO business, Australia	94% gross margin, from under 35%; 94 units delivered in the first 2 months	The same delivery line before and after, rebuilt as a single audited automation of 34 AI nodes. AI cost is about $4 per full unit pack.
Real estate business, USA (Texas)	$114k saved per year	A saving set against the human cold calling team the voice agents replaced. It is not new revenue.
Real estate business, USA (Texas)	More than 500 calls a day	Inbound and outbound AI voice agents running continuously.
Another real estate business, USA (Texas)	$19.79 cost per lead	Investor leads, after AI calling was added.
Building materials business, Germany	Three disconnected tools became one system	A change in structure rather than a single number.

The shape to judge a slipping project against is simple. The audit comes first, one named system goes live early, and the rest follow in phases. Wobble works from Karachi and has run more than 25 engagements across 6 countries. AI is how we run the audit, the build and the monitoring, and it does not replace the decisions described above.

What to have ready before day one, and when a fast start is not available

None of the causes needs solving perfectly before starting. They need somebody to have thought about them once. This is the checklist worth working through in the week before a build begins, and it is useful whoever you end up hiring. Our page on what we expect from clients sets out the same preparation from our side of the table.

• A named internal owner for the project, with regular time each week and the authority to answer operational questions without escalating.
• A list of every tool the system will need to touch, and the name of the person who controls access to each one.
• Admin rights confirmed on the accounts, held inside the business, and a check that your plan on each tool includes the features being asked for.
• One folder holding the price list, the terms, the service list and the questions customers ask most, in whatever state they are currently in.
• One clean export of your customer or enquiry data, with somebody available to say which duplicate is the real record.
• A written note of the process you most want fixed, including where you already know people do it differently.
• An honest answer to whether the process underneath is working, because if it is not, that is the first piece of work rather than the automation.

On cost and commitment, how we bill depends on the build. Some projects are a one-time build, some are a monthly service and some are both. Monthly services stop any month, with no lock-in, and you own what we build either way.

Common questions

Why do automation projects take so long?

Usually because of waiting rather than building. Access to the tools takes days per system, a decision sits with somebody who was not in the room, content and data that was promised takes longer to gather than anyone expected, and the process being automated turns out not to be written down. The engineering itself is generally the predictable part.

How long should a first automation take?

A first build starts with the audit, then one named system goes live early, and further systems follow in phases. How quickly that happens depends on whether access and decisions are ready when each step needs them, so any supplier giving a single number before looking at your tools is guessing. Our page on how long AI implementation takes goes through the stages.

Does automation save time?

Once it is live, yes, but it costs time first. The preparation and the build come before any saving, and the saving arrives after the setup work, not instead of it. Our Work page records what live systems did, not how quickly each one paid back, so we make no promise about payback speed here. It shows more than 120 automations shipped across 25+ engagements.

Will automation jobs be replaced by AI?

Repetitive tasks, in part. The work that remains is deciding what the system should say, owning the exceptions and writing down how the business actually runs. That is why every workflow we build has a stop where a person approves money, pricing and anything published in your name. We cannot forecast the wider labour market, and we do not claim to.

Why do IT projects fail so often?

Most of the causes above apply to IT projects generally: unclear ownership, decisions with no owner, missing content and an unwritten process. Failure usually shows up as a project that stalls, then loses support, rather than one that breaks. Our page on why AI projects fail covers the failure side of the same subject.

What is the single biggest thing I can do to speed it up?

Name one internal owner with regular time each week and the authority to make operational decisions without escalating. Nearly every delay traces back to a question waiting on somebody. A person who can answer within a day, rather than a committee that answers within a fortnight, is worth more than any amount of extra engineering.

Is a slow project a sign the supplier is bad?

Not on its own, but silence about it is. A supplier should be able to tell you exactly what the project is waiting on, who holds it and what would unblock it, in one sentence, at any point. If they cannot answer that, the problem is visibility rather than speed, and visibility is the thing to fix first.

Should we fix our process before automating it?

Usually yes, and it is often quicker than it sounds. If several people do a step several different ways, a system has to be told which one is correct, so the decision happens either way. Making it deliberately takes an afternoon. Making it accidentally, halfway through a build, costs weeks and produces something nobody quite agrees with.

Do regulated industries take longer?

Yes, and the extra time is paperwork rather than technology. Agreements, non-disclosure terms, approvals and compliance reviews sit before and during the build in sectors like banking, pharmaceuticals and anything with a regulator watching. It works perfectly well, the timeline is simply longer, and expecting that from the start prevents most of the frustration.