It also meets with considerably more failure than people tend to realize. Studies on software project failure (as opposed to the program failure, which is due to software bugs) are controversial, since the measure is necessarily subjective, but one extensive survey found that failure was around 70%. They counted failure as wildly over budget, over deadline, or well below expectations. They also reported about 30% cancellation, which is part of the 70%, and is failure by anybodies measure. As for the rest of the failures, though, they could just as easily be a failure of expectation rather than a failure of the project. If a project goes wildly over budget, is that because things went wrong, or because the budget estimate was absurdly low? In any case, what they measured was that a strong majority of project leaders were sufficiently disappointed in the outcome of their projects that they were willing to slag them on a survey.

This is part of where agile comes from. What's the advantage of taking the time to figure out failure states and so on if you're going to be disappointed in the majority of projects and a third of them will never be completed? It would make more sense to spend the analysis time on projects that will be finished, and that's only two in three. So, how do you know which ones will work? You don't. This is where all the "fail fast" comes from. Get something together quickly such that you get an idea whether or not the project is worth investing further in.