In the movies you know what's coming when the team leader suggests the group separate and some red shirt gets sent off to investigate a dark cellar by herself - and oddly enough IT project failure reviews are often exactly like going to that kind of movie.
Basically what happens as you go through the files and talk to the people is that the standard markers of doom - things like methodologists in controlling roles; strong separation between designers, developers, and users; or simply too many people pushing too many agendas - give you the same sense of impending doom you get from watching the pretty girl march down those steps by herself.
You'd think experienced IT people would know better, and many do - but if you're a developer or project manager just yelling "don't go there" when these warning signs pop up is a lot like yelling it in the movie theatre: you get in trouble with everyone else around, but nothing changes.
In response I generally try to get non IT management to learn from the on-going disaster so that they'll understand what they're seeing the next time something suicidely stupid, like separating the players in the interests of saving time, shows up in someone's IT project management strategy.
Unfortunately role separation is as basic to data processing as the waterfall model - and telling people that their entire methodological focus for project delivery is at the root of their failure to deliver projects usually produces a lot of hostility and the rather huffy assertion that most of their projects succeed just fine, thank you very much.
Unfortunately, I don't think it's true: on the contrary I believe that essentially all significant projects developed using rigid phase, and therefore role, separation fail the business - but in saying that claim that there are two very different kinds of failures. There are the obvious hard failures in which the project is cancelled, abandoned, or declared hugely successfull but never heard from again - and then there the really expensive ones: soft failures in which the project becomes an albatross hanging on user necks to impede them.
In other words, I'm prepared to argue that the worst software project failures from a business perspective are often considered successes by IT.
In this view, the worst of the worst are the ones that succeed at brilliantly doing the wrong thing.
Alberta Health, for example, went through at least three separate attempts to redevelop their original claims and registration systems, finally producing an outstanding success in the mid ninties - and locking the entire organization into an eighties style management structure that's now costing the taxpayer well over a billion a year.
All of which leads me to propose a fundamental observation about software development: specifically, that there's an inherent parallelism between the rigidity of the development process and the effect the application will have in use: i.e. the tighter the controls imposed during development, the more of a strangulation effect a successful release will have on downstream organizational flexibility and productivity.