Re: Hmm
Another way to read that is Crapita saved the tax payer $140m. If this was kept in house the tax payer would have to stump this and probably more.
That would depend on whether they delivered the project in the same way. The tragic thing is that all of this is very simple in concept, with the complexity mainly in the data and interfaces. The way most of these projects go wrong is that they make the concept complex, and assume simplicity in the data and interfaces.
There's only two levels for the concept, the processes, and the IT (which is largely transaction processing tied to a very simple database or three). You design a robust and common process around what the users of the system want. It is important to pay lip service to the requirements spec issued by procurement, but the actual requirement must be based on what the end users want to achieve (procurement won't have asked them). All of the business units have to accept the new process - or pay from their own budget for a custom process - this usually shuts up the whiners. Then you either build new, or preferably re-use any existing halfway adequate systems according to the new process, and roll in the "client" workload sequentially, knowing that the first 40% of easy records will go across with few problems, and then you'll unearth all the skeletons when you move from 40-60% of the data. So you don't rush it.
There's no rocket science. And typically, when you take a bunch of different organisations and systems, somewhere there's a process that's working at least adequately, and somebody has an IT system that isn't a disaster. Best option is build out from those things that work, so ideally not everybody, every process and every system are changed.
When you look at the fuck ups that Crapita are associated with, the hugely costly messes they create for non functioning systems (like Army recruitment), it's quite clear that the vendor are simply incompetent, unfortunately so is their client.