Transformation always sounds bigger than mere “change.” It suggests a fundamental re-think and re-do of what was there before – not just “something new.”
In many ways, the confusion between transformation vs delivery in government starts right here – in the assumption that bigger automatically means better.
Of course, it also implies that the “something new” will actually, you know, work.
Trying to bridge the revolutionary with the functional is a tricky task, and one that the public sector wrestles with on a regular basis. This is the heart of the challenge when it comes to transformation vs delivery in government: sweeping ambitions often collide with the unglamorous realities of day-to-day implementation.
Let’s look at three examples where transformation vs delivery in government was misaligned — and what went wrong as a result.
Case Study 1: Idaho (Luma)
The Luma system was designed and implemented to bring Idaho’s accounting and payroll services (an enterprise resource planning, or “ERP” system) into the cloud by July 1, 2021.
The first governance or directional issue appears to have come from a change in scope during this delay. Originally, the core system was meant to stay on government servers, a decision already seen as obsolete by most agencies at least a decade earlier.
Next, rather than pilot implementations with smaller departments, Idaho’s State Comptroller’s Office decided to implement it everywhere, all at once – often referred to as the “big bang” approach.
Compounding this decision was the reduction of end-user testing. So not only was the implementation exposed to getting it wrong everywhere at the same time, the project team decided not to double-check how it was really going to work in the real world.
And so much of the “automated” work – according to the state auditor’s department (Idaho Legislative Services Office) – has been diverted to spreadsheets, massaging the data before entering it, and reconfiguring financial reports because they can’t be customized in the system.
Oversight approved speed without demanding safeguards. Testing couldn’t catch flaws that hadn’t been surfaced – and the half-finished system went live two years late.
Case Study 2: Maine (Workday)
In 2016, the state of Maine embarked on another ERP system, this time with the Workday platform. With the same goal of modernizing their 40-year-old human resources and financial systems, Maine opted for a platform that was already used by multiple cities across the U.S., as well as a number of departments in the United Kingdom’s government.
The oversight failure became visible afterwards when Maine sued Workday, shifting blame for the project failure onto the vendor’s project support. But project accountability rested with the state, not its contractors.
While it is entirely possible that the vendor did not provide the level of support that the state felt they needed, the oversight body should have demanded that the project team take control of the situation.
Effective oversight means managing risks internally, not outsourcing them to vendors.
And, as above, despite the concerns about the information that was being provided to the oversight body, testing was scaled back and several stages were ended before completion.
Senior consultants from the vendor were (allegedly) not provided to the team, which impeded the testing further.
In the end, the project with an initial budget of $17 million budget ended with a spend of almost $55 million – and the platform was abandoned before ever being implemented.
Oversight isn’t about monitoring vendor behavior – it’s about owning project risk.
Case Study 3: Michigan (MiDAS)
In 2011, reacting to a report that suggested the current unemployment benefits system had allowed for $143 million in overpayments, the Michigan legislature pushed through an overhaul. A brand new system was to be designed from the ground up, at a cost that eventually became about $44 million.
Like with so many transformations before it, the decision-makers wanted to reap the savings before the transformation had even taken place. Because the goal had been to fully automate unemployment claims processing, the state laid off many of the “humans” that had previously made those decisions.
That decision proved catastrophic when testing was reduced and failed to simulate real-world conditions – and the errors started popping up.
Simply put, the MiDAS system started flagging fraud everywhere, with data that could not be traced to any actual dates or amounts.
MiDAS flagged 40,000 citizens for fraud – with a 90% error rate – forcing many to repay tens of thousands of dollars plus 400% penalties before compensation lawsuits reversed the findings.
Real-world testing isn’t a luxury – it’s the only shield against cascading failure.
Pattern, Not Accident
The unfortunate thing about these types of projects is that they almost encourage public sector leaders to lower their ambitions.
“Look at how easy it is for things to go wrong,” they might say, and it’s a challenge to argue that things could have been easily turned around.
These projects didn’t fail because the transformation was too ambitious. They failed because transformation vs delivery in government wasn’t managed as a unified effort — they over-promised change and under-delivered outcomes.
Public service project leaders can deliver massive, transformational change.
They just need to clarify their vision, develop a concrete plan to implement, and never forget that the citizens don’t care about what was promised.
They only care about what is delivered.
This post is based on an article I originally wrote for Route Fifty.
Want to know how your own project stacks up? My Project Health Check highlights the warning signs when transformation vs delivery in government starts to drift.
