What Transformation Actually Means for a Services Organization

Sep 5

5 min read

Most transformation advice tells you to add more. This one is about the client who won by taking scope away, and what it took to stay in the room long enough to get there.

Transformation gets sold as addition. More automation, more visibility, more capability, more insight into what your business is actually doing. Every vendor pitch leans this direction, and it makes sense; addition is an easy story to tell.

Some of the most meaningful transformations I have been part of started with the opposite move. Not addition. Subtraction.

Here is a real story, details changed to protect the client, about a services organization that came within a conversation of walking away from their new system entirely, and what it actually took to turn things around.

Where it started

The organization was moving off a legacy platform that had outgrown what they needed from it. Poor visibility, clunky workflows, a system nobody trusted anymore. The goals for the new implementation were ambitious and, on paper, entirely reasonable: detailed resource planning, granular task-level tracking, tight integration with their financial system. The kind of scope most organizations reach for because it sounds thorough. More capability tends to feel like the safer bet than less.

Weeks into implementation, the cracks started to show. The team wanted the system to calculate project schedules one way; the tool, configured as built, calculated them another. Task durations kept shifting unexpectedly. Resource bookings and project timelines lived in two different places and had to be maintained separately. None of this was a software failure. It was a mismatch between how the team wanted to work and how the system had been set up to work, and that gap kept surfacing as friction, meeting after meeting.

The moment it nearly fell apart

At a certain point, one senior leader on the client side had simply seen enough. In their view, the tool could not do what the business needed it to do, and continuing down the current path looked like continuing to spend time and money on something that was not working. That sentiment, once said out loud in a room full of stakeholders, is hard to walk back. Momentum on a project like this is fragile. Once a senior voice says the word "walk away," everyone in the room starts quietly agreeing with themselves that maybe it is time.

I want to be honest about what that moment feels like from the consultant's chair. It's not comfortable. There is no elegant deck that talks a frustrated executive back off that ledge. What actually works is slower and less dramatic: staying calm instead of meeting frustration with frustration, listening closely enough to understand what was really driving the concern, and responding with reasonable explanations and a clear path forward rather than a defense of the tool. The posture that matters most in that room is partner, not adversary; meeting the client where they are, then working from there toward what the original plan had gotten wrong.

What the diagnosis actually required

This is where experience does the work that no amount of software training can replace. Anyone can learn where the buttons are. Recognizing that a struggling implementation is usually an expectations problem wearing a technology costume takes having lived through enough of these to know the pattern on sight. In this case, that was almost exactly it: the gap was not about what stayed in scope or fell out of it. The gap was between what leadership assumed the system would simply handle and what the team had actually built.

Recognizing that a struggling implementation is usually an expectations problem wearing a technology costume takes having lived through enough of these to know the pattern on sight.

I have written before about the "copy and paste trap," where teams try to rebuild their old spreadsheet-driven process, or even their process from a previous system, inside a new system rather than rethinking the process itself. This was that trap, but louder, and with a deadline pressing in from one side and a frustrated executive pressing in from the other. My job was not to defend the software. It was to separate what the team actually needed on day one from what they had assumed they needed because it sounded complete. That distinction, drawn clearly and defended with the client's leadership, is what kept the project alive long enough to get to a better outcome. It is the kind of call that only comes from having seen enough implementations go sideways to recognize which fights are worth having and which ones are costing more than they are worth.

The restart

Once the diagnosis was clear, the path forward looked almost nothing like the original plan, and that was the point.

Resource planning came out entirely. Advanced scheduling features were disabled. The integration with their financial system was pushed to a later phase instead of being forced into the initial go-live. The team went from a broad, ambitious build to a narrow, functional one: time entry, billing, reporting, done well, with everything else deferred.

The restart itself was uneventful; it picked up again almost as if nothing had happened. A new kickoff, a redefined and much smaller definition of success, and a compressed runway to go-live built around what was actually achievable.

No fanfare. Just a clear-eyed decision to stop trying to do everything and start doing the essentials well.

What happened after go-live

This is the part that makes the story worth telling, because the ending is not "they went live and everyone was relieved." The ending is what happened over the months after.

The organization kept working the system. Utilization reporting that had been unreliable got rebuilt from the ground up. Invoicing and revenue recognition moved from a manual, spreadsheet-driven process to automated rules. Roles and permissions that had piled up during the transition got cleaned up and simplified. Governance around timesheets and billing tightened considerably. None of this happened because a vendor pushed an upgrade. It happened because the organization, having stabilized on a smaller foundation, kept building on top of it.

If you know the Services Operations Maturity Model I have written about here, this is a textbook Level 2 to Level 4 journey compressed into a single ongoing engagement: the shaky first months after go-live, the optimization window where the change-request list comes alive, and the slow climb toward operational maturity where reporting actually gets trusted again.

The lesson

Transformation is not a straight line from old system to optimized new system; it rarely is. More often it looks like what this organization lived through: overreach, a genuine crisis point, a retreat to what is essential, and then a rebuild forward from steadier ground.

None of this had to happen reactively, though. The same subtraction that saved this project, cutting scope down to what actually mattered, works just as well as a deliberate step taken before go-live instead of damage control after one nearly fails. This client got there because the situation forced the question. Most organizations have the chance to ask it on their own terms, simply by scoping harder and assuming less before the first configuration decision gets made.

Organizations that treat that retreat as failure often quit right there. They read the moment as proof the project was doomed from the start. The organizations that come out stronger are the ones that treat the retreat as information: a clear signal about what actually mattered, stripped of everything that did not. This client did the harder thing. They stayed in the room, took the smaller scope seriously, and let a narrower version of success become the foundation for a much stronger system than the one they originally set out to build.