Why large government IT projects fail

Although the HealthCare.gov fiasco is the most recent example, the problem of underperforming government projects is so pervasive that it was described in the 2006 "Defense Acquisition Performance Assessment Report" as a conspiracy of hope.

The conspiracy of hope begins when the government puts out requests for proposals for projects that are too large, long-term and complex for contractors to make credible proposals. Companies are forced to create proposals that are at best educated guesses and end up underestimating cost and time in hopes of winning the award.

The winning proposal becomes the baseline for cost, time and capabilities. Five years later, everyone acts surprised when the project hasn't delivered as promised or fails completely.

Multiple studies show that project size is the most significant predictor of project failure. Typical multiyear projects that cost hundreds of millions of dollars to create have statistically almost no chance of being fielded in accordance with the initial proposal. Because big government has the need for big projects, should they be evaluated like baseball batters, where a one-in-three success rate is considered successful? Absolutely not!

The long line of failed government IT projects hasn't occurred because we're stuck with big projects that are destined to fail. A 2010 report titled "Achieving Effective Acquisition of Information Technology in the Department of Defense" offered a clear remedy and actionable strategy. In short, large projects would be developed and delivered in small increments and created through an iterative process known as agile development.

The vast majority of government projects are now delivered through waterfall methodology. A large project is broken into sequential phases, starting with requirements gathering and then moving through design, development, integration, testing and finally delivery. In a waterfall project, the first time you're likely to know you have a problem is when integration and user testing begin. In a three-year project, that's about two-and-a-half years from the beginning and about 80 percent into the budget.

If any significant problems come along at the end, it's possible that the project team will have to go back and reconsider its initial assumptions and perhaps throw out most or all of what's already been created. That's why many large projects end up being abandoned entirely. Fixing the problems ends up being too costly.

Agile accomplishes all of the work done in the waterfall phases, but instead of doing pieces sequentially, they are done in small slices simultaneously. Each week, an agile project does a little bit of requirements, design, development, integration and testing and, most important, delivers working code.

Agile projects are developed by implementing the most important features first. So instead of waiting five years before a big project is delivered, agile development can often field an initial version in the first year because the most important capabilities are the first to be developed. A good example is the U.S. Transportation Command's Distribute.mil portal.

In August 2009, Gen. Duncan McNabb, who was USTRANSCOM's commander at the time, directed his IT division to develop and field a new supply chain portal that would serve as the unified platform for the command's planners and logistics stakeholders. The project was slated to be developed through an agile methodology.

Using conventional processes, the project would have taken an estimated 36 months to deliver an initial operating capability. By using an agile development methodology, the initial Distribute.mil product was delivered in less than a year.

It's time to end the conspiracy of hope and begin creating RFPs that support agile development.