I think the diversion to financial crisis ismostly irrelevant to the question of risks in IT projects, although some of the common factors are interesting. Jeff has it absolutely right, I believe, when he says that a main cause of the crash was overconfidence, and that is also a significant factor in software projects: the big projects that fail completely at enormous cost, the projects that overrun their timescales by a factor of two and their budgets by a factor of 4 while delivering less than half the panned functionality just couldn't happen if people weren't wrongly confident that they could be done at reasonable cost in a reasonable time. The techies being told to tweak teh modles to predict what the bosses wanted to believe is also something people in software development tend to be very familiar with: when someones model of teh software development , validation, and deployment process delivers costs or timescales the boss doesn't like the boss will insist on either tweaking the model to deliver "more acceptable" results or in throwing the model away and going purely on the boss's uninformed and unprofessional opinion.

However, the main problems are perhaps elsewhere. The biggest is that people forget the KISS principle, which is a very old rule that hardly anyone follows; although they are somewhat shorter than "keep it simple stupid" I prefer either of Tony Hoare's versions of this. One was in his Turing award acceptance speech: "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies", and a lot of risk comes from using the second approach described there instead of the first. The other was "Inside every large program is a small program struggling to get out" in database terms I might render that as "for every complex bunch of nested loops with cursors peppered with GOTOs and BREAKs there's a simple sql statement to do the same job"; it isn't quite true, of course (neither the orib=ginal nor my database version) but the general message (eschew unneeded complexity) is an essential one and ignoring it is another big cause of risk in IT projects.

ANother Hoare statement (which he said was told to him by someone at Elliot's, and just applying the principle enabled him to recover a catastrophically failed project) was that a project would fail if the manager didn't understand how to do it or allowed his people to do things that he didn't understand (I can't recall the exact wording, or track it down; it's in a piece he wrote about how he found that out the hard way). I've seen so many people trying to manage people doing things that they (the managers) don't understand that I recognise it is clearly asking for trouble, so I'm sure Tony was right on that one. Of course it's not saying that IT projects can only be done in companies where the CEO and the President are IT experts, that would be crazy; but it is saying that if a manager doesn't understand what the people working on a project do and he is a competent manager he doesn't manage the projecthimself - he will do things like dealing with people and budgets, not dealing with the subject matter of the project; and part of his dealing with people is appointing someone who does understand the subject matter of the project to oversee it, and managers for the groups participating in the project who understand what they and their people are doing. That is very like Buffet's "Risk comes from not knowing what you're doing", but takes it a stage further, in two ways - know what your people are doing, as well as what you are doing yourself; and don't just know, understand.

But I think falure to observe the KiSS principle is the big problem; doing something you don't understand, or letting you people do something that you don't unerstand, is certainly failing to keep it simple. And keeping it simple goes back a very long way: duns Scotus, Ockham, Da Vinci were fairly modern practitioners of it compare with our earliest records of it in classical Greece; and engineers have loved the principle since long befoe the KISS acronym was coined. There are plenty of versions of it from computer scientists, Hoare wasn't the only one of those to advocate it (being a classicist before getting involved with computers, he may have gotten it from Aristotle), there's also Perlis with "Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it", Dijkstra with "Simplicity is a prerequisite of reliability", and Joe Armstrong with "Lack of simplicity is a symptom of using the wrong abstractions" (I thought that came from here, which should be obligatory reading for all developers, but it doesn't).

And of course that page reminds me of yet another reason for high risk: people insist on writing software in ridiculously bad languages (C++, Java, Basic - including VB - and so on); and hardly anyone realises that the language they use is part of the problem, not part of the solution; and the world is full of idiot invententing yet worse languages and yet more dsastrous new language paradigms. But of course that is just another aspect of not keeping things simple - those languages are ridiculously complex.