Remember that whole, “A million monkeys on a million typewriters would eventually produce Shakespeare?”
Sounds crazy, doesn’t it?
It also sounds a heck of a lot more efficient than the in-house system I reviewed a while ago.
Legacy Meets Deadline
The premise was simple enough. Like so many databases and in-house systems that were “computerized” back in the 1970s and 1980s, little had been done to maintain them — and even less to improve them.
So eventually, they break.
At the eleventh hour, this organization put all of their planning efforts into the “next generation” system.
As happens so often, the existing databases were so massive (40+ years’ worth!) that the focus was on building a new system that could still talk to the existing one (rather than migrate everything).
Tough task. What made it even tougher was that other organizations also relied on the system, and it had to be available 24/7.
And were they up to the task?
Um… Kinda.
A Win by Public Sector Standards
Government in-house software is almost invariably awful, but that’s a topic that can be tackled on its own. (And we will!)
But factoring in that low-level bar, the new software did its job: the database was up and running somewhat on time, it provided the basic functionality that they said it would, and they were able to keep it up and running without using popsicle sticks, candle wax, or a fire extinguisher.
By most public sector software development measures, it was a clear win for Team Public Sector.
So if this was such a rare success, why are we talking about it here? Why not write an article on massivegovernmentwins.com? (That’s not a real thing, by the way.)
You might want to ask the out-of-town cousins.
What About the Rest of the World?
The complicating factor that was never considered was: what happens when someone tries to use it outside of headquarters?
And what about in a less-than-ideal environment? Even in a remote, out-of-the-way office?
What about all of those things – and it’s overseas to boot?
In other words: how do we call it a success if about a third of its users have such little functionality that they literally have to hire local programmers to build plugin workarounds?
And then they get reprimanded for doing so?
“Working” Systems That No One Can Use
This, of course, is not a hypothetical situation.
I met with an entire office operation of about a hundred people far, far from headquarters.
And they showed me what they had to deal with on a daily basis.
The speed of the data entry program was such that you couldn’t really enter any data. The software was designed to constantly sync with the home database, which meant information was firing back and forth on a second-by-second basis.
The problem?
Both the (lack of) bandwidth and the distance meant that anything somebody typed into it felt like a subway operator would randomly slam on the brakes.
Nothing… nothing… THREE WORDS ALL AT ONCE… Nothing… Nothing… TWO MORE WORDS ALL AT ONCE.
Delivery Over Usability
It would have absolutely driven me crazy. This office somehow just accepted it as a fact of life, which – to public servants’ eternal credit – is something that happens every day.
But it was a prime example of just how little in-house development incorporates user testing, or – when it actually does – just how limited it is.
The user testing had all been performed at headquarters, a stone’s throw from the servers.
And I don’t think I need to tell you that they didn’t exactly spend a year testing it in a sandbox, or opening it up to beta testing.
Like so many government software projects, the goal was delivery, not usability.
And offices all over the world have frozen clocks to prove it.
👇 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.