by clicking on the page. A slider will appear, allowing you to adjust your zoom level. Return to the original size by clicking on the page again.
the page around when zoomed in by dragging it.
the zoom using the slider on the top right.
by clicking on the zoomed-in page.
by entering text in the search field and click on "In This Issue" or "All Issues" to search the current issue or the archive of back issues respectively.
by clicking on thumbnails to select pages, and then press the print button.
this publication and page.
displays a table of sections with thumbnails and descriptions.
displays thumbnails of every page in the issue. Click on a page to jump.
allows you to browse through every available issue.
FCW : September 15, 2014
Commentary | DAVID ELFANBAUM DAVID ELFANBAUM is co-founder of Asynchrony Solutions. Although HealthCare.gov 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 capa- bilities. 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 hun- dreds 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 govern- ment IT projects hasn’t occurred because we’re stuck with big proj- ects that are destined to fail. A 2010 report titled “Achieving Effective Acquisition of Information Technol- ogy in the Department of Defense” offered a clear remedy and action- able strategy. In short, large projects would be developed and delivered in small increments and created through an iterative process known as agile development. Most government projects use 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 sequen- tially, 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 wait- ing five years before a big project is delivered, agile development can often field an initial version in the first year because the most impor- tant 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 logis- tics 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. ■ Why large government IT projects fail We need to end the ‘conspiracy of hope’ and embrace agile development as the best way to avoid fiascos on the scale of HealthCare.gov Companies are forced to create proposals that underestimate cost and time in hopes of winning the award. 12 September 15, 2014 FCW.COM
September 30, 2014
August 30, 2014