TL;DR: Applications serve processes – not the other way around.
I think by now we should finally be at the point where we all know that software doesn’t actually “fix” anything, aren’t we?
Haven’t we all finally accepted the quasi-old expression of, “Garbage in, garbage out,” meaning that software is still at the mercy of whatever people choose to put in it?
It’s a nice thought.
The idea of it being true sometimes makes me smile.
But we’re still a long, long way away from it being a reality.
Why Software Doesn’t Fix Broken Government Processes
Unenlightened Senior Managers (we’ll call them USMs) still seem to hold this fascination with what magical technology can accomplish.
As if a giant system, with scores of interconnected databases, can just be summoned to “make it do” something that people want.
Quickly.
Software applications are often treated like office furniture, that if you want it to look different, you just pick it up and move it to the other side of the room.
Even worse, there seems to be no consideration that what people tend to do outside of the system – in other words, on “earth” – might have any relationship with the little blinking light on the screen.
Nowhere was this more evident than in a huge project that pitted two processes against one system.
Three warriors, one end result, and no victors.
When Government Processes Clash With Enterprise Systems
The highest offices had decided to migrate an entire set of operations from one organization to another. The two organizations had very little to nothing to do with each other, other than they were both federal government organizations, and they processed things.
After that, the similarities kind of broke down.
It was almost like a corporate merger, except in government. While the budget for the project was wishy washy at best – some elements were costed, but everything was in-house so nobody really kept track – thousands of employees changed roles.
And why were these two dissimilar organizations merged together?
Senior management stated – actually, boasted, I think is more appropriate – that the end host organization had a great system, and the moving organization needed a new one.
“One organization has a system, and the other doesn’t – so let’s squish ‘em together and watch the magic happen!”
Why Merging Systems Can’t Fix Organizational Problems
There might be weaker reasons for making massive, impactful structural change.
But I can’t think of one.
To make matters even worse, the moving organization (with the old, lousy system) was a service-based organization that was meeting its service standards 97% of the time.
In government services speak, that’s what we call “all-time historic magnificence.”
So if we’re uprooting the entire process and shifting everything over to a new system, what’s the predictable result when you’re already at the top?
Only way to go is down.
The Fallout of Prioritizing Systems Over Process
And that’s exactly what happened.
Mere weeks after the “merger,” processing times were down by 30%, or so the dashboards said. Scopes of activities were reduced and more people were thrown at the problem.
And the root cause was as simple (and as predictable!) as could be – a familiar pattern in major government transformations. The IT folks were asked to add a couple of extra screens to the existing system, and the new organization was asked to rename some of the fields they had used.
And somehow that would have meant a perfect marriage of system and process?
Not only did the new organization have to learn a new software, but they had to translate it to their existing processes.
All on the fly.
The Core Rule: Systems Must Serve the Process
Sure, when the application development starts to get ironed out, there is always a tweak or two that gets reflected back to the process. That’s just part of collaboration and idea-generation.
But the application is meant to be built to empower the process, and to make the process easier.
Any time we try to reverse that relationship, we set ourselves up for disaster.
Lesson: Applications serve processes – not the other way around.
👇 Want to avoid being this story?
If you’re leading a complex public sector initiative — and want a fast, honest scan of how your project’s tracking — try the free Project Health Check. It takes five minutes, and it might catch the exact blind spots that tripped up this $100M failure.
You can also learn more about my services here, or explore more real-world insights in the Insights section.