Every growing business has a list of projects it knows it should do. Automate the returns process. Connect the 3PL to the web store. Stop rebuilding the Monday report by hand. Get the team using the AI licences somebody bought last year.
Nobody on the list is in doubt. The owner knows what is broken and usually knows what would fix it. Six months later the work is still being done the old way, and the list is a little longer.
The gap is not knowledge. It is the distance between knowing what to do and having someone with the time and the skills to do it while the business keeps trading.
Why the two usual fixes stall
The first attempt is to hand the project to whoever is closest to the problem, usually the operations manager. They understand the work, which is why they are the right person, and they are already flat out running the week, which is why nothing happens. The project becomes the thing they will get to after month end. Month end comes every month.
The second attempt is to hire for it. A head of systems or technology who understands logistics, finance and software. That person is rare, expensive and slow to find, and a business doing twenty million a year rarely has a full year of that work to give them once the first project is done.
What stalled projects have in common
Having watched a lot of these from the inside, the pattern is fairly consistent.
- The project has no owner whose week is cleared for it. It belongs to someone as a side task, and side tasks lose to the day job every time.
- It was scoped as one big thing. A whole ERP migration, a full integration, a company-wide AI rollout. Big things need a long run of uninterrupted attention, which is the one thing a growing business does not have.
- Nobody wrote down what done looks like. Without a finish line the project can neither be completed nor cancelled, so it hangs around.
- The people who do the work were not involved. The build lands on them, misses the exceptions they handle every day, and they go back to the old way within a fortnight.
What gets them moving
The projects that finish tend to be set up differently from the start.
They are small. One department, one workflow, a few weeks. Small enough to finish before the next crisis, and small enough that the business can see the result and decide whether to do the next one.
They have a named owner with time actually taken out of their week, and a written definition of done that the owner can check without arguing about it. "The customer service team keys no emailed orders by hand" is a finish line. "Improve order processing" is not.
They are measured. Hours before, hours after. The measurement is what turns one finished project into permission for the next.
And the people who do the work are in the room from the beginning. They know where the process actually breaks, and a fix they helped design is a fix they will use.
Where outside help fits
The honest case for bringing someone in is not that they know things you do not. It is that they have the time your team does not, and they have done this particular kind of project before, so the first version is closer to right.
The useful version of that help does the work rather than describing it. It sits with each department, works out which project on the list is worth doing first and what it is worth, sets it up, trains the people who will run it, and stays until it holds. That is what the AI Ops Audit and the rollout are for. A fifty-page strategy document is not on the list of things a busy business is short of.
Where to start
Take the list. Pick the item that is costing the most hours this week, not the most interesting one. Give it an owner, a finish line and a month. If it needs help from outside to get done in that month, get it. The list gets shorter, and the next item is easier because the business has now seen one finish.