It's pushing 20 years since I first saw an academic study showing that IT project failure probability increases dramatically - the latest was 2005:
The Challenges of Large-Scale IT Projects
You're darn right I won't be put in charge of such - not without a gun to my head. I'd want to de-scale anything down to a size where you could reasonably spec and test it. As the article says, "test, test, test". A formative experience in my programming was FORTH, a language that strongly rewards small incremental experiments, compiling as you go, building from small functions up to large ones. I'm not saying use FORTH, but the philosophy of getting the basics working and building up has really worked for me for a whole career.
By contrast, all the large-scale projects I've worked on have all taken a philosophy like building a skyscraper or 747 - no one person can comprehend it, design everything before the first screwdriver is picked up, so the design process goes on for months and years, etc. And then you have "crunch time" from then on as the fond beliefs of the design team smack into reality, and the specs are proven to not match needs. Incremental building and testing tends to reveal these problems.
The fear that drives these philosophies is that you'll have the thing mostly built...and discover it doesn't meet every need and can't without some huge rebuild, because you didn't think of everything up front. Rather like an old system that's been patched to death and has to be tossed because it just can't keep up with changes. I think the fear exaggerated, particularly if the design-build team is at least roughly aware of the whole project dimensions.
The advantage of more-incremental projects that are never large because you take one part at a time is you develop in priority order. The 80/20 rule suggests that 80% of the clients will want about 20% of the options available - so get 20% of the offering working, and working well, first.
Canada has this story of medical records: http://news.slashdot.org/story/09/10/10/0124227/open-source-could-have-saved-ontario-hundreds-of-millions
As /. covered it, "open source" would have saved 95% of project costs, but I think it was also about the open-source development was in small increments, no large projects.