Perhaps it's an extreme generalisation, but the reporting around most failures seems to suggest either the solution has taken far longer (and cost many more dollars) than expected OR upon delivery (or in testing) it was determined that it was not fit for purpose – either "wrong" or too limited.
Initial business requirements exhibit a relatively smooth view of the environment. Perhaps in defining the new system they will either say, "wrap up all these disparate systems we're currently using and make a cohesive whole that works faster and more efficiently", or they might say, "build me a system that looks a lot like my current software, but make it better and more flexible – allow for growth in both usage and features".
Both of these options lead to the same "wall of death": complexity. Worse, evolving complexity!
So, having spent some months designing this new system, the go-ahead is finally given by the appropriate competent authority (based on the value of the project) – that may be the project sponsor, or it may well require a full board-level approval. Either way, it is expected that go-ahead will only be given when the project budget and scope of works are costed with just a 10% margin of error.
Construction begins. Software is written, hardware is ordered and specific milestones are defined and (hopefully) achieved. Communications infrastructure is designed and tenders let for it's completion.
And then it all goes to the dogs.
The software designers/implementers complain that the design specifications are incomplete. Hardware that had been specified for the new system is found to be seriously under-performing. Perhaps only the communications infrastructure is remotely close to what was actually needed (perhaps not!). Initial testing by trial users exposes far more flaws than successes...
And now we see the issue. The pace of change has grown so much that specifications are obsolete before they can be implemented. Hard-earned software language abilities rapidly become "yesterday's skill" long before anyone is able to gain more than competence – mastery is a pipe-dream. COBOL, anyone?
We have reached a stage where the evolution of requirements, of competing products and of the ability to implement has become seriously compromised. The world of IT is evolving faster than the practitioners are able to keep up.
Which leaves us with the Faustian choice between the "uber-programmer" who can solve all our problems, and the recognition that we cannot continue to grow complexity and expect to maintain our sanity.
Uber is probably a myth.