Why automation projects take longer than anyone planned

Where the time actually goes

Ask anyone who has run one why it slipped and they will tell you the same thing. The build weeks are predictable. The gaps between them are not, and the gaps are where a two month project turns into a five month one.

None of this is a complaint about clients, and it is not a defence of suppliers either. It is a description of a shared problem with a shared fix, and the fix is almost entirely about preparation rather than effort. A business that has four specific things ready on day one moves at roughly twice the speed of an identical business that does not, without anybody working harder.

The four causes below account for most of the delay in most projects. Read them as a list of things to sort out before you start rather than as a list of things that go wrong.

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 currently 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. Two days of that per tool, across six tools, is a fortnight.

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 six times. Where read only is enough, the list says so, which makes the conversation much shorter.

Occasionally a tool simply will not allow what is needed, and it is much better to discover that in week one than in month three. Some software genuinely 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 of these two people does an unusual enquiry go to. Is this reply allowed to go out without a person reading it first. Each one takes ninety seconds to answer and can sit for a fortnight if the person who can answer it was not in the room.

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

So the useful step is naming, before the start, who can decide what without escalating. One person with the authority to answer 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, because it is a small amount of time landing at unpredictable moments.

Waiting on content and data that was promised

The system needs to know 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, and most businesses have it spread across a website, a folder, three people's memories and a spreadsheet somebody built in a hurry.

Gathering it is genuinely a job, and it is a job that tends to be given to whoever is already busiest. It also surfaces disagreements, because two people in the same company frequently answer the same customer question differently and neither of them knew.

Data has the same shape. Exporting the customer list is easy. Deciding which of the four versions of a contact is the real one is not, and cleaning it is real work that has to happen 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. Even a rough folder with the price list, the terms, the top twenty questions 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. Somewhere around week two, the question is asked: what happens after a customer confirms. And it emerges that three people do it three different ways, all of them defensible, none of them 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 actually wants that step to work, which 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 the outcome is that a step gets deleted rather than automated, because once it is written down it turns out nobody could explain why it existed. That is the cheapest result available and it happens more often than you would expect.

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.

The automation did not create the problem. It found it, in week two, which is the cheapest week to find it.

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

None of the four 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.

• A named internal owner for the project, with an hour a 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, 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 twenty 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 one 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.

The week before day one, and who is waiting on whom

The access wait shortens when ownership is settled before the project rather than during it. Accounts registered in your own name from the first day, admin rights held by somebody inside the business who is not the person on leave, and a written list of every account, key and connection the system will need, produced during the audit instead of requested in week three. You own the system throughout, which is also why nobody spends a fortnight waiting for a supplier to grant something back.

The decision wait has a version that never ends, and 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 hands it to a person. Settling those once, in the audit, removes a whole category of the every-couple-of-days decisions described above, because most of them turn out to be the same question about who is allowed to say yes.

The fourth cause, the process nobody wrote down, is the one your own team has to solve and the one no supplier can solve for you. It is also the most valuable thing the project uncovers. Writing it down in-house before anybody is engaged converts the most expensive wait in this article into an afternoon, and it is worth doing even if the build never happens.

The published shape to judge a slipping project against: the audit takes the first week, one named system is live inside a fortnight, the second and third land across month two. Behind that sit 94 units delivered in the first two months at Quillon and more than 500 calls a day at Big Texas Land Buyers. Moiz Khan owns automation architecture at Wobble, which works from Karachi, bills month to month and carries 25 engagements across six countries.

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?

One named process, with access ready and the decisions available, is usually a matter of weeks rather than months. A build covering several departments is a phased programme where the first piece goes live early and the rest arrives over months. Any supplier giving a single number before looking at your tools is guessing.

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

Name one internal owner with an hour a 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 three people do a step three 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.