Why practice management implementations fail

A firm signs for a new practice management system, spends real money and eighteen months of goodwill on it, and ends up with the same bottlenecks it had before. The partners conclude they picked the wrong software. Usually they didn't.

We have been brought into enough stalled and failed implementations to say this with confidence: the platform is rarely the cause. Xero Practice Manager, FYI, Karbon and the rest are mature products that thousands of firms run successfully. When an implementation goes badly, the failure is almost always in one of three places - and all three are inside the firm's control.

1. Communication

This is first because it causes the other two. A decision gets made in a project meeting that half the relevant people did not attend. It is minuted, nobody reads the minutes, and six weeks later a senior manager discovers the workflow has been built around an assumption they would have corrected in thirty seconds.

The pattern is consistent. Attendance at project meetings drops as billable pressure rises. The people who show up are not the people who do the work. Decisions get made anyway, because a project cannot stop - and every one of those decisions is a small bet placed on behalf of someone who was not in the room.

What works: fewer, shorter meetings with mandatory attendance from the people whose work actually changes, and a standing rule that a decision is not made until the person who has to live with it has said so out loud. That is slower in week three and dramatically faster by month six.

2. Ownership

Ask a firm mid-implementation who owns the project and you will often get a shrug, a committee, or a name attached to someone who has neither the time nor the authority. Meanwhile the vendor owns their piece, the integrator owns theirs, and the gap between them belongs to nobody.

The symptom is easy to spot: decisions queue. A configuration question that should take a day takes five weeks because it needs a partner group that meets monthly and has fourteen other items ahead of it. Nothing is technically blocked. Everything is waiting.

What works: one named person, internal or external, with the standing to make the call and the mandate to make it quickly. Not a steering committee - a person. This is the single largest predictor of whether an implementation lands, and it is why our project management engagements exist as a distinct service rather than an add-on.

3. Process

The most expensive mistake in practice management implementation is lifting the firm's existing process into the new system unchanged. The firm pays for software, spends a year on the transition, and arrives at exactly the same problems in a nicer interface.

It happens for an understandable reason. Redesigning process is contentious, and configuring software to match the current process is not. So the project takes the path that generates fewer arguments, and the firm's genuine inefficiencies get carefully rebuilt in a new platform at considerable cost.

What works: settle the process questions before configuration starts, not during. Which steps exist because a client needs them, and which exist because a system used to require them? Where does a job actually stop moving? Those arguments are cheaper to have on a whiteboard than in a half-built system.

What a good implementation looks like from the inside

Less dramatic than a bad one. The process arguments happen early and get resolved. One person makes the configuration calls and the rest of the firm trusts them to. Meetings are short because the decisions in them have already been socialised. Go-live is uneventful, because by then the team has been working in the new way for weeks in parallel.

And it is scoped around the firm's calendar rather than the vendor's. Rushed jobs lead to disaster. If the timeline is too tight for the firm to make its decisions properly, the honest answer is to move the timeline, not to compress the thinking.