Everyone likes to think that their project is unique – but most mistakes in public sector transformation aren’t new. Back-office transformation failures are common, they’re pervasive – and they’re avoidable.
As long as we’re always on the lookout for them.
So let us pray that we forever avoid the following “sins” – forever.
#7: Aiming Too Big
The first sin is perhaps the most misunderstood pitfall of any public service project.
Because notice that I said aiming “too big” and not “too high.” I’m a massive believer that governments can be as ambitious with their transformation goals as any corporation in the world.
But how that ambition’s scope is managed is where things often go wrong.
The Big Bang approach – unveiling massive transformation everywhere, all at once – is rarely in the project plan at the start. Even the most ambitious projects plan for small roll-outs, fixing what isn’t working, and then adjusting as the implementation progresses.
But these projects rarely go according to their plans, do they?
Big Bang roll-outs are often a product of stressed schedules: things are falling behind, and teams find a way to rationalize squishing the milestones together.
Even the best-run transformations will have something go wrong.
The question will be: is that a small problem, or one that throws the entire project into chaos?
#6: Aiming Too Small
The flip side of that coin is aiming too small – in both scope and ambition.
While scaling too fast and crashing often comes with a “told you so,” a small-scale transformation of an area in need of change can crush a team’s hopes.
This is the transformation equivalent of slapping a new coat of paint on a broken-down house.
Again, the broad-stroke plans in the early days will talk about aiming high, and they’ll scour the different departments for ideas: “In a perfect world, what would this look like?”
But just like with the expansion of implementation, these project scopes are dramatically impacted by crunching timelines – except in the opposite direction.
Features are reduced, modules are eliminated, and access to tools or functionality is limited.
The “transformation” becomes an upgrade from Windows 10 to Windows 11. Maybe that makes somebody else’s life easier, but most people’s jobs remain unchanged.
The end result will be a project that didn’t earn its cost, and a set of employees that will refuse to buy into the next so-called “transformation.”
#5: Over-Engineering The Project
One thing that public service leadership loves to do is establish infrastructure around a project.
Lots of it:
- Incorporating even the most tangential stakeholder into the process – not just for consultation, but for decision-making.
- Establishing sub-committees that report to the committees.
- Insisting on broad sign-offs for process steps, not just milestones.
- Remember when we talked about rushing implementation or reducing scope because of crunched timelines?
Over-engineering of the project governance and planning is often the cause. We build in so many different layers of decision-making that it’s almost impossible to move forward on a project because we’re always waiting on one committee or another.
In addition, these committees are often comprised of so many different stakeholders that we either schedule them according to availability – versus project needs – or the stakeholders keep sending substitute attendees who rarely know what’s going on, and thus contribute nothing.
The big decisions will likely require the big wigs in order to get the funding. Accommodate the big decision points, but try to keep everything else nimble.
#4: Accepting “Good Enough” Back-Office Systems
A close cousin to the “Aiming Too Small” sin is Accepting Good Enough.
What does this mean in real life?
A protein shake rather than a three-course meal.
In other words, something that serves a purpose, but only barely.
Internally designed software is almost always like a desk drawer: it contains all the stuff you need, but finding it takes more time than it’s worth.
The IM/IT team will diligently take notes to develop an inventory of all the functions that need to happen, and they’re often left to their own devices to put it all together.
And what’s left?
A product that in no way matches the user experience. Screens that are designed as forms, not as a part of a process. Text boxes that can technically capture notes, but are so small that users end up writing in Word and copy-pasting it into the system. Buttons buried behind so many menus that the organization inevitably calls for more “training.”
You know what I’ve never needed training in? Tax preparation software. It’s about the most complicated activity in the world to do on paper, and yet the first time I ever used the filing software, I could have done it half-asleep.
Whether it’s off-the-shelf or internally built, back-office software needs to be designed with the user in mind – not just how easily it can be deployed.
#3: Over-Customizing Your Back-Office Software
I know, everyone has their favorite colors: the theme should always be in cool blues. Or what about warm earth tones?
Everyone has their preferences for little ringing bells chiming when the process is complete – or maybe no sound at all?
The beauty of racing down the customization rabbit hole is that it’s maybe the most efficient way I can think of to completely derail a project – quickly, totally, and unforgivably.
And the examples above are just surface-level customizations, though they’re the ones that invariably derail focus groups and steering committee meetings.
The really dangerous ones?
Those are what happens when an organization decides that their processes are so unique that there’s no possible way to use the new software unless it’s ripped open and rearranged to suit internal demands.
The most common result of this?
Everything breaks, and they’re so far from the starting point that there’s no way to course correct.
The worst part about over-customized software is that it’s most often used on processes that were never designed in the first place. They’re almost always processes that have evolved, not through deliberate improvements, but through routine.
And too often, the official processes aren’t even the ones followed in practice.
Just buy the software, change the job titles, put in your logo, and be done with it.
#2: Accountability That Isn’t Accountable
One of the great ironies I’ve observed time and time again in all public service projects – but especially in back-office transformation projects – is the complete absence of a person in charge.
Don’t get me wrong: there is always a project charter, and there are always steering committees and oversight committees.
There are loads of accountability vehicles.
But which person – specifically – owns the project?
If anything goes wrong in a certain area, which person – specifically – is accountable for the result?
Governance structures and committees are excellent for building consensus, but when relied upon too much, the result is watered down accountability.
If a poor decision is made, who made the error? Was it the project manager that proposed it, or the twelve people around the committee table that endorsed it?
If a deliverable was misinterpreted, was the mistake the fault of the specialist who acted on it, or the manager who communicated it poorly, or the project manager who described it in the plan, or the committee who signed off on the plan?
There’s an old-school saying that if something goes wrong, there has to be “one throat to choke.” In other words, one person has to be accountable for any one mistake – or any one project.
And if no one really knows who “owns” the project or the project decisions, then nobody owns it.
#1: Forgetting The Purpose Of The Transformation
It becomes so easy to focus on the sticker statement of the transformation: we’re installing a new software, or we’re re-organizing our service delivery.
That’s what the ultimate transformation will look like, so that’s all we talk about.
But why would we install that new software? To what end are we re-designing our business units?
Ideally we’re bringing in a new software system because the old (if it existed) was too slow, was too expensive, or resulted in too many errors – probably because it relied too much on manual human intervention.
And so rather than the project team bragging about the new software that they’re implementing, they should be bragging instead about making everyone’s jobs easier.
Why is that so important?
Because of all of the “sins” we’ve listed above. Once we get too far down into the weeds of the day-to-day, we lose the bigger picture of why we even started in the first place.
Is the customization actually slowing things down? That’s not the purpose of the transformation.
Does the software function but things are taking just as long? That’s not the purpose of the transformation.
If we don’t remain laser-focused on the purpose of the back-office transformation – rather than the shiny product in front of us – then we’re committing ourselves to the same traps that have befallen so many back-office transformations before ours.
We risk creating the next case study in back-office transformation failure — not because we lacked effort, but because we lost direction.
Want to make sure your transformation avoids these traps? Take the free public service Project Health Check — five minutes to find your blind spots before they sink the project.
