Why practice management implementations fail

A firm signs for a new practice management system, spends real money and months of goodwill on it, and ends up with the same bottlenecks it had before. Plus months of disruption. What went wrong?

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.

And even better news - it's almost always recoverable.

1. Communication

This is first because it causes the other two points of failure. A decision gets made in a project meeting that half the relevant people did not attend. It is noted, nobody reads the notes, and six weeks later a leader in the firm discovers the new 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, or the people most impacted. Decisions get made anyway, because a project cannot stop and it's being held to a date. Every one of those small decisions made in a project meeting can have far reaching consequences. The right people need to be in the room consistently, and actively engaged.

What works: fewer, shorter meetings with mandatory attendance from the people nominated to represent their positions in the firm. It is slower to progress a project for three months, but dramatically faster by month and year six of live.

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 or 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 more important. Nothing is technically blocked. Everything is waiting for a committee or unanimous agreement.

What works: one named person, internal or external, with the standing to make the call and the mandate to make it quickly. Not a whole 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.

A project owner can be accountable to a committee, board, group; but someone has to own it.

3. Process

The most expensive long term mistake in implementation projects is lifting the firm's existing process into the new system unchanged. The firm pays for software, spends months 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. Implementation projects often also have to run to a timeline. There's a reason for a deadline, and it needs to keep moving.

So the project takes the path that generates fewer arguments, and the firm's genuine inefficiencies get rebuilt in a new platform at considerable long-term cost.

What works: settle the big ticket process questions before configuration is signed off, not during a Go Live. Which steps exist because a client needs them, and which exist because a system used to require them?

Agree in advance, with a plan, when the remainder of processes will be optimised to suit the new system. In reality, if you re-write / re-build every process in the practice before a Go Live, an implementation would take a year. Most firms don't have that luxury - so be realistic about what falls in and out of the implementation scope.

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 meeting have already been socialised. Go-live is uneventful, because the project team have had the latitude to test, and consider the variables beforehand.

Finally, the project is scoped around the firm's calendar. Rushed jobs lead to disaster.  Plan and simple.
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 project.

The shorter the timeline, the more the disruption.