- 1-403-975-5816
- info@governit.ca
- 1-403-975-5816
- info@governit.ca
Get in Touch with Us!
GovernIT Consulting Inc.
We turn stalled projects into delivered value through governance discipline, independent oversight, and hands-on execution.
We turn stalled projects into delivered value through governance discipline, independent oversight, and hands-on execution.
A multi-office UK law firm was implementing a new practice management suite to improve case management, proformas, billing and related operational processes. The investment exceeded £1 million and affected more than 200 users across 2 offices.
The business case was significant. Inconsistent billing practices were contributing to fee disputes and limiting the firm’s ability to bill clients effectively. The new platform was intended to provide a more consistent operating foundation while modernizing the way the firm managed matters, billing and resources.
More than half a year into the implementation, however, the project was in trouble.
By the time a new vendor-side project manager was brought in, confidence between the law firm and the solution provider had deteriorated badly. Some partners had disengaged. The client’s project lead was no longer communicating effectively with the incumbent vendor project manager. The issue had escalated to the vendor’s account leadership, and the client was considering legal action.
The problem was not simply poor project management. The original plan had been approved using the information available at the time. As implementation progressed, the extent of several underlying issues became clearer.
Data migration was a major source of difficulty. Information had to be consolidated from multiple systems, processes and, in some cases, spreadsheets. Data structures and practices that had worked independently now had to be formatted, mapped and standardized for a common platform.
Requirements were also less settled than the original plan assumed. Different parts of the firm had developed their own practices and preferences, and some stakeholders wanted inconsistent data points or operating variations preserved in the new system. What appeared on the surface to be a technology implementation increasingly required decisions about how the firm itself would work.
By then, both client and vendor stakeholders had invested considerable effort in the approved plan. Changing it meant acknowledging that assumptions made earlier in the project no longer held.
Continuing against that baseline would have increased the risk of a failed implementation. Starting again with another provider could have left the firm’s original billing and operational problems unresolved for as much as another year, while introducing additional cost and potential reputational damage. The firm had already been communicating impending changes to its own clients.
The incoming vendor project manager began by listening rather than defending the existing
plan.
He met with client stakeholders to understand their concerns, investigated the delivery issues behind them, and separated the problems with the current state of the project from the personalities and history surrounding it.
The objective was not to determine who had been at fault. It was to establish what was now known, what constraints the project actually faced, and what would be required to complete it successfully.
Working closely with the client’s project lead, he rebuilt the implementation plan around those realities.
Dependencies were refactored so that prerequisite work would be completed before downstream activities depended on it. Expectations around data migration were reset to reflect the actual effort required to map and standardize information from disparate sources. Requirements were solidified so that the client and vendor had a common definition of what the system needed to do.
Some stakeholders could reasonably have viewed this as a reduction in scope. In practice, the objective was not to remove agreed functionality but to eliminate ambiguity and establish more consistent ways of working.
The revised plan extended the expected go-live by approximately three months. The commercial impact was shared. The vendor absorbed some of the additional effort as a good-faith measure, while the client recognized that its needs and the project’s underlying conditions had changed.
A new plan alone would not have restored confidence.
The project manager and client lead first built enough consensus around the revised approach to take it to client and vendor leadership. Rather than presenting milestones as technical delivery dates, they connected each milestone to the business reason it mattered and the consequences of getting it wrong.
The first visible sign of recovery was renewed engagement from the firm’s partners. The right decision-makers returned to the boardroom and participated in the path forward.
The recovery plan then deliberately emphasized achievable commitments. Hitting credible milestones became a way to rebuild trust through evidence rather than reassurance.
Execution was broken into daily and weekly milestones, with close attention to the critical path. Regular stand-ups surfaced issues quickly. Data problems that might previously have waited for a scheduled weekly meeting could now be identified and acted on as they emerged.
This more granular operating rhythm was intentionally simple. The purpose was not to add process. It was to give both sides a clear view of what had to happen next, whether it had happened, and what could put the next milestone at risk.
The recovery also changed the role of change management.
Earlier resistance often reflected a reasonable concern: existing practices worked for the people using them. Moving to standardized data and processes could therefore feel like the system was imposing change for its own sake.
The project team made the trade-offs explicit. Where established practices could not be carried into the new environment without perpetuating inconsistent data or inefficient processes, stakeholders were shown the alternatives, the constraints and the longer-term benefit of standardization.
The vendor project manager recommended standards, built working consensus and then sought client leadership approval where decisions required it.
Change management shifted from explaining changes that would happen to users toward involving users in how the new operating model would work. Workshops, user representatives, testing and a train-the-trainer approach gave affected employees a role in the implementation before go-live.
That involvement was important because the new system touched more than technology. It changed how information was structured and how work flowed through case management, proformas, billing and related processes.
Confidence returned gradually.
The re-baseline stabilized the commercial relationship, although trust remained fragile for much of the remaining implementation. As the project began meeting the revised milestones and stakeholders saw issues being addressed earlier, confidence continued to improve.
The project ultimately went live against the re-baselined plan. The data migration, training and adoption objectives were achieved, and the cutover itself was notably uneventful.
After implementation, the firm observed more effective billing, fewer fee disputes and better allocation of resources to cases. These benefits were operationally visible, although the vendor project manager did not have access to the firm’s full financial results and therefore did not quantify the revenue impact.
The clearest measure of the relationship recovery came afterward. A client that had reached the point of considering legal action against its solution provider formally agreed to act as a reference client for that provider.
The project did not recover because the original plan was executed more aggressively. It recovered because the teams accepted that the facts had changed. They rebuilt the plan around the real dependencies, addressed the data and operating practices underlying the implementation, involved users in the change, and restored confidence one achievable commitment at a time.
Experience basis: This case describes work led by a GovernIT principal in the early 2010s while employed by the solution provider, before GovernIT. The client and solution provider have been intentionally anonymized.
We want to hear from you
Who We Are | What We Do | Case Studies | Insights | Contact
© 2026 GovernIT Consulting Inc. All rights reserved. See Accessibility for more information.
