Why is stopping so hard in a professional services firm?
Partnerships are bad at ending things. A project that was announced at a partners' meeting, defended in a management report and given to a respected colleague acquires a constituency. Stopping it looks like a judgement on the people attached to it, so nobody proposes it. Instead the project gets quietly reduced: fewer meetings, a smaller scope, a vaguer timetable, until it is neither running nor finished.
That state is more expensive than either outcome. The licences still renew. The internal champion still spends an afternoon a week on it. The firm still tells itself it has an AI initiative, which is enough to stop anyone starting a better one. And the work it was meant to fix, the write-ups, the bid production, the monthly reports, carries on being done by hand at full cost.
There is also a quieter cost. While the official project limps along, people solve their own problems with whatever they can reach, which is how shadow AI takes hold. A stalled programme does not leave a vacuum; it fills one badly.
What are the signals that a project is already over?
Three absences matter more than anything else, and all three can be checked in an afternoon.
- There is nothing live. Not a pilot, not a sandbox, not a demonstration to the management team. Nothing that someone does their actual job in. If every artefact of the project so far is a document, a slide deck or a workshop output, the project has produced analysis, not capability.
- There is no named owner. A committee is not an owner. If you ask who decides what the system does next and get three names or a function, the answer is nobody. We set out what a real owner looks like in picking the person who owns AI.
- There is no go-live date anyone will say out loud. Dates that move are normal. Dates that have stopped existing are terminal. When the honest answer to "when will this be how the job is done?" is "once we have finished looking at it", the project has no end state.
Beyond those, watch for the scope widening every time progress is questioned. A project that cannot show a result on one process and responds by proposing to cover four is buying time. Watch too for the people who do the work being absent from every meeting about it, which almost always means the system being specified does not match the job as it is actually done.
How do you tell slow from dead?
Slow projects have a direction. You can describe what changed this month in terms a fee earner would recognise: the draft report now pulls the right figures, the bid library now has the approved version of each section, the note comes out in the firm's format. Dead projects can only describe activity: meetings held, requirements gathered, a supplier shortlisted.
The test we use is simple. Ask one person who does the job whether their week is different. Not whether they are optimistic. Whether their Tuesday afternoon has changed. If the answer is no, and the project has been running long enough that it should have, you are not behind schedule. You are on the wrong road.
Length matters here because it sets expectations. An implementation measured in a month has to show something inside a month. One measured in a year will always be able to say it is early, which is exactly why how long implementation takes is worth agreeing before anyone starts. Long timetables are not more thorough. They are harder to fail.
What should you ignore when deciding?
Ignore what has already been spent. It is gone in both scenarios, and including it in the decision only guarantees you spend more. The only live question is whether the next three months will produce a working process, judged on what the last three produced.
Ignore the demonstration. Every tool looks competent on a prepared example. The thing to look at is output on live work, with the firm's own templates, on an awkward matter rather than a tidy one. We go into why that gap exists in a tool is not a process.
Ignore the argument that the firm needs to be seen to be doing something. That instinct is what produced the stall. A quiet, well-explained stop carries far less risk than a project everyone internally knows is going nowhere.
How do you end it cleanly?
Give yourself a week, and treat it as a piece of work rather than an embarrassment.
- Write down what was learned, in one page. What the process actually involves, where the hours go, which exceptions broke the design, what the team would not accept. This is the asset. Most failed projects produce genuine knowledge about how the firm works and then throw it away with the software.
- Keep the process map and the template decisions. If someone mapped the bid or the report properly, that holds its value whatever happens next. If nobody did, note that as the main finding. Documenting a process covers the standard to aim for.
- Close the accounts and the data. Cancel licences before the renewal date, retrieve or delete anything uploaded, and confirm in writing what the supplier holds and for how long. Do this while someone still has the logins.
- Tell the firm, briefly and without blame. One paragraph at the partners' meeting: what was tried, what it showed, what happens to the underlying problem. Silence invites the worse interpretation, which is that nobody noticed.
- Name the next step or explicitly park it. "We are stopping and doing nothing for six months" is a legitimate decision. "We are stopping" on its own becomes drift.
What does a sensible restart look like?
Most firms that stop a project were not wrong about the opportunity. They were wrong about the shape of the commitment. The common pattern is a broad programme aimed at the firm in general, with success defined by adoption rather than by a job getting faster, which is the failure mode described in why AI rollouts fail.
A restart should be narrower than feels satisfying. One process, picked because it costs real hours and has a recognisable output: the monthly client report, the bid production cycle, the file note. A fixed date by which it is how the job is done. A named person who approves anything that reaches a client. And a measure agreed in advance, which measuring return on AI sets out how to define.
Set the stopping conditions at the same time as the start date. If nothing is live by the agreed date, the project ends. Firms find that uncomfortable until they notice the alternative is the position they are already in: paying for something indefinitely that nobody will defend and nobody will cancel.
Before restarting, re-establish where the hours actually go rather than trusting the assumptions behind the first attempt. The unbillable hours calculator gives you the arithmetic, and the audit will tell you which process to put first.