Local governments aren’t businesses – so why are they force-fed business software? - Oracle’s repeated public sector failures prove a different approach is needed::Oracle’s repeated public sector failures prove a different approach is needed
Local governments aren’t businesses – so why are they force-fed business software? - Oracle’s repeated public sector failures prove a different approach is needed::Oracle’s repeated public sector failures prove a different approach is needed
I mean… the headline is basically wrong. There are plenty of purpose-built tools for public administration, often configured and supported by the same big players (e.g. IBM). I’ve worked with several of them.
But I think the article hints at the real problem:
Governments have requirements, often legislative in origin, that making no f*cking sense and that are incredibly tricky to model in software, because they’re written by legislators who have a poor understanding of automation and how to write clear prose. And those requirements change with the stroke of a pen. Keeping up with them means the constant attention of a large team of software developers.
By contrast, most commercial enterprises can pivot to line their processes up with whatever the industry common practice is. Governments rarely have that freedom.
This statement seems incredibly naive to me:
The entire reason that governments go to companies like Oracle and SAP for help is that building, maintaining, and changing bespoke applications, and the full stacks to support bespoke applications, in a way that is compliant with government-grade change management is incredibly expensive. The entire selling point of tailoring a commercial ERP system is that it should nominally do a pretty good job of handling “the things they all have in common” at least as well as anything you build yourself. The projects still fail because accomodating the stuff that IS different ends up being a bespoke software project all of its own, and because things that appeared to be “in common” turn out to require bespoke configuration, because the government bean-counters didn’t tell you about a bunch of the nitpicky requirements up front.
The prosaically simple explanation for these failures is that companies like Oracle over-promise, but they do that because almost ANY contractor has to over-promise and under-price to get a government contract.
Source: I work for a company like Oracle, and I work on projects for regional governments.
They don’t have to be. Legislators can, you know, funding the fucking departments that need it. But that’s an entirely different subject…
Not always. Sometimes it’s pivoting to whatever is making them the most money. Or eating their own dog food to prove their product, even if that product sucks.
Yes, it is incredibly expensive, and sometimes these huge corporations think they can just do it the same way they did it with State X and hope that State Y can just map terms. And then they crash and burn hard because they don’t understand that state laws are different, and sometimes you have to put in effort and time and money to actually get a working product. Corpos want to put in the least amount of work and money to get as much profit as possible from governments, and some of them have been burned so badly by that mentality that they look for better solutions. Often, there’s not any great solutions and their infrastructure suffers.
Have you even seen a government RFP? They tell you. Every. Single. Requirement. In detail, in triplicate, in sometimes unreasonable or unrealistic terms, under 800+ pages that a team of experts need to pour over and that’s before there’s even any sort of contract negotiation that requires the team of lawyers.
Source: I work for a company that comes in after companies like Oracle have fucked up so royally that governments are begging for a quality product
Sure. The ability to pivot has a lot to do with whether the process is fundamental to the way they make money. The more fundamental it is (part of their “core competency”, as Weird Al would say), the more likely they will have a “secret sauce” that they can’t change (or even openly discuss until you are contracted, onboarded, and NDAed).
With respect, that’s the same error that I’m accusing the article of making. You can’t just tack on complex bespoke development on an open system and expect to get the results you want for cheap.
Ehh… I respectfully disagree.
I work in the US, and I’d say that what you just said is true for a subset of well-specified federal contracts.
But at the state and local government level? It’s not true at all. I’ve done requirements gathering at the state and local government level and it’s like herding cats. The contract itself will have high-faluting language about “the contractor shall implement an information processing system to X, Y, and Z”, but as for HOW you’re going to X, Y, and Z, figuring that out all comes after the ink is dry on the contract. And there’s no guarantee that X, Y, and Z actually make any sense in light of the data and capabilities that the state or local government actually has. That language came from legislation, or the mind of a high ranking bureaucrat, not any of the people who do the literal day-to-day work.