If you're commissioning an AI project right now, whether that's a custom build or a vendor implementation, you've probably heard that AI has made writing software at least ten times faster. It's reasonable to conclude that perhaps the whole project should be dramatically faster and cheaper than it would have been five years ago.
Our estimate, from doing this work: expect the overall timeline to come down by something like a quarter. The actual building part is definitely faster, but that part alone is not sufficient for helping your company gain the value you're seeking.
That difference matters before anyone signs, because it changes which proposal in front of you is the good one.
The coding did get much faster
The good news here is real. For the act of writing code, the gains are enormous, and the population of people who can produce working software at all has widened a lot.
So why doesn't a tenfold improvement in writing code produce a project that takes a tenth of the time?
Simplifying heavily, an implementation project has three phases:
- Discovery. Working out how the job actually gets done today, and what the new tool has to do. Sometimes, what the workflow should become instead.
- Development. Building or configuring the thing.
- Change management. Getting your people to actually use it.
Development was time-consuming, but it was tractable. The two phases that were time-consuming and hard are discovery and change management - the ones with people in them - and those are the two AI has a hard time compressing.
Discovery: People don't know what they know
Some workflows you could learn just by watching somebody's screen. That's roughly what RPA (robotic process automation) did years ago. But most workflows worth automating aren't like that, because they have a lot of human judgment baked into them, and judgment is hard to document. Most companies don't keep hyper-detailed written procedures, and honestly, we don't blame them.
Here's one we worked on: a home services company dispatching field technicians. Every day, all the techs need a list and ordering of which customer jobs to tackle.
That sounds like a routing problem, and you may have heard that people earn doctorates on route optimization. But the nuance really is in everything aside from the route math:
- Hard constraints. Fixing certain machines needs a certification only some technicians hold.
- Semi-hard. If the first visit only diagnosed the problem, the follow-up should ideally be done by the same technician.
- Medium. This technician covers zones X, Y and Z, unless there's enough work in zone A to justify the trip, or unless they're already at the edge of Z, which puts them near C, or...
- Soft. Higher-commission jobs tend to go to senior technicians, because that's what they expect, but nobody will contort a route for it.
And so on. None of it is written down anywhere. It lives in the brain of the dispatcher, who has never had reason to spell it out in full.
This isn't people being evasive or guarding their jobs. In our experience the people we interview are open and helpful, with fair questions about what this means for them, and more curious than defensive. The challenge is that nobody keeps a mental catalog of every edge case and judgment call baked into how they work. It only comes out under questioning, over several passes.
Could AI do the interviewing? You can picture it, like with doing AI-moderated voice interviews. In practice it feels unnatural, and so it doesn't get the same depth of knowledge transfer. There's still nothing quite as disarming as a curious (human) person asking an expert a follow-up question.
Change management: It's easy to ignore an announcement
Change management is the other phase that hasn't compressed, and it's mostly made up of things that are unglamorous and get skipped even in normal times:
- Documentation people can actually use
- Enough in-person training
- Sitting next to users while they work, answering questions and noticing the small changes that would smooth out the workflow
- Cultivating a liaison on the team who teaches the new way and channels feedback back to you
Why does this fall by the wayside? It takes a lot of human hand-holding, it gets viewed as lower-value work, and people tend to overestimate the impact of an executive mandate (hint: it doesn't do nearly as much as you think). And it's not that your employees are obstinate about technology. They're just busy, and few things irritate faster than a new tool that is, at least this month, worse than what it replaced.
AI doesn't look like a tractable way to compress this yet. If anything, it's a lot easier to ignore an AI than a person sitting beside you!
So buy more, rather than cheaper
If the project comes in about a quarter faster, should the price drop by more than that? Somewhat. The shift we'd push harder on is what the same budget ought to buy now: more of it, with partners picked on that basis.
More means more iterations. Because the building can happen in short bursts now, the rhythm should be: build a little, put it in front of the expert, watch them react, build again. That spreads discovery across the whole project instead of front-loading all of it, which matters because people react to a working prototype far better than they answer questions in a conference room.
It also builds the adoption you're going to need later. Your expert sees their feedback show up in the tool within days and starts to feel some ownership over the new workflow. By the time you get to rollout, you've got internal champions rather than an announcement.
And the iteration shouldn't stop at launch. Some requests during rollout are real scope decisions. Many are small polish items, and shipping those quickly buys you a lot of goodwill.
Questions to ask potential outside help
Everyone now has access to the same fast development tools, so build speed is table stakes rather than a differentiator. Here are some questions to make sure you ask of anybody who's going to help you with an AI project:
- How do you run discovery? Who does the interviewing, how many people do they talk to, and how many passes do they make?
- Who specifically owns change management on this project? A plan with no name attached isn't a plan. This is the same gap that shows up on the org chart, and it's worth asking whether they expect to supply that person or expect you to.
- How often will our experts see new versions of working software? "Every week" is a good answer. "At the end of the build phase" is a red flag.
- What happens in the month after launch? If the answer is a handover document, the adoption problem is being left with you.
A partner who disappears for three months and comes back with a big reveal is running the model AI was supposed to have made obsolete. Instead, you should be looking for a partner who can work quickly and iteratively.
Where this leaves you
The honest version is that AI moved the constraint rather than removing it. The building is cheap now, and the two expensive things are still understanding how your company actually works and getting people to change how they do their jobs.
That's worth knowing before the roadmap gets written, because it changes what a realistic first project looks like: something narrow enough that discovery is a few conversations rather than a quarter, with a named person inside the company who owns whether it gets used. Figuring out which project fits that description is what an AI strategy should land on.
You know your company, so you probably have an idea of which projects are narrower versus much bigger lifts. If you'd like a second read on them, or want help figuring out what the next step is, send us a note, we're happy to chat.