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.

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).

think they can just do it the same way they did it with State X and hope that State Y can just map terms

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.

Have you even seen a government RFP? They tell you. Every. Single. Requirement.

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.