[nabla9]

This was not a fluke.

The failure rate of large scale IT projects is the huge. For large, complex projects the statistics is

     2% success
    42% challenged
    56% failed

https://www.standishgroup.com/sample_research_files/CHAOSRep...

The new system has probably similar 50% change for success. I think giving the new project to the same contractor may improve the changes. Hhey have hopefully learned something.

[p_l]

In this case the chances of success are even lower, given the track record of the company doing it.

Which involves as stellar things as delivering a not-working (but "valid under contract" so we couldn't sue them) system for logistics management (everything from ensuring parts are on the shelves to assigning jobs to technicians and pilots for a mission) that we later found was rebranded broken car logistics support software, something that was found 3 years post original delivery date by new employee of a team working on fixing it - which meant we had to rework a crucial module.

Said software had gems like JS copied from geocities in 1998 handling drop down menus (which were broken unless very specific browser versions were used) - in 2012. (original delivery date was 2009~2010).

The "redo" contract is going to the same guys who just did the failure, and I've seen no mention of removal of one of the bigger pain points, which was use of cloud.

[adrianN]

Hack: Start development of n systems in parallel, to get 1-(0.98)^n success probability.

[ipnon]

Isn't this sort of the FAAAM strategy regarding senior talent retention? Pay 10x engineers to work on pet projects rather than have them jump ship.

[mikorym]

If only the variables were independent, right...

[fulafel]

This has been proposed and it seems like a credible strategy. The actually implemented versions seem to always end the competition phase relatively early so they are not very good experiments for validating the idea.