There is enough empirical evidence to say that poor requirements contribute to the majority of project failures. Look at these study conclusions published over a 13 year period beginning in 1995:

Requirements problems have been proven to contribute to 20-25% of all project failures. The average project overran its budget 189% and its schedule by 222%—Chaos Report / The Standish Group 1995

Requirements Errors account for 70% to 85% of rework—Liffingwell, 1997

Poor requirements account for 71% of project failures—Grady, 1999

Between 40 and 60 per cent of all software defects can be attributed to bad requirements—Abbott, 2001

Only 34% of projects expected to finish on time; 52% had proposed functionality; 82% had time overruns; 43% had budget overruns—The Chaos Chronicles / The Standish Group 2004

Flawed Requirements Trigger 70% of Project Failures—Infotech Research, 2005

Gaps in the Technical Requirements accounted for more than 70% of program problems—United States Government Accountability Office, 2008

In addition to these startling conclusions about how poor requirements contribute to project rework and failures, the 1995 Chaos Report added that 94 out of every 100 projects require restarts, sometimes multiple restarts, citing a California Department of Motor Vehicles case study to illustrate the claim. The Standish Group reports, “Only 9% of projects in large companies were successful.” Medium size companies demonstrated a 16.2% success rate and small companies showed 28% successes. The most successful case study highlighted in the report is the Hyatt hotel reservation system. The report stated, “Hyatt had all the right ingredients for success: user involvement, executive management support, a clear statement of requirements, proper planning, and small project milestones.” Hyatt finished their project early and under budget.

You would think the statistics would reveal an improving trend line considering the advances made in system development methodologies. Instead, we observe the opposite with the best statistics in 1995 and a worsening trend over time leveling off at a 70% failure/rework rate since 2005. And this is only with the projects that have been surveyed. How many more are out there we don’t know about? The cost of these project failures and cancellations run into the high billions. The Chaos Report estimated American companies and government would spend $81 billion dollars (USD) on failed or canceled projects in 1995. How much more would that be in today’s dollars in light of the worsening failure rate?<

A February 2009 article by Jeff Roster, a member of the Gartner Blog Network, revealed 2008 worldwide spending statistics broken out by industry segment. The article predicted the growth rates through 2012 in IT spend for these industries which range from a low of 2.8% for manufacturing to 5.2% for Utilities. In 2008, total IT investment was just under $1.9 trillion dollars in these market segments which do not take into account government spending. If we apply the conservative 1995 Chaos Report metric of 25% for project failures to the 2008 spending statistic, it means that we can estimate that in 2008 $475 billion dollars was spent on failed or canceled projects worldwide.

Getting back to the question, "Who's to blame?" If the right ingredients for success are user involvement, executive management support, a clear statement of requirements, proper planning, and small project milestones as the Chaos Report indicates, then it's a combination of both the business and IT with the scales tipped toward the IT side of the equation.