Shows & Panels
- The 2014 Big Picture on Cyber Security
- AFCEA Answers
- Ask the CIO
- Connected Government: How to Build and Procure Network Services for the Future
- Continuing Diagnostics and Mitigation: Discussion of Progress and Next Steps
- Federal Executive Forum
- Federal Tech Talk
- The Intersection: Where Technology Meets Transformation
- Maximizing ROI Through Data Center Consolidation
- Moving to the Cloud. What's the best approach for me
- Navigating Tough Choices in Government Cloud Computing
- The New Generation of Database
- Satellite Communications: Acquiring SATCOM in Tight Times
- Transformative Technology: Desktop Virtualization in Government
- Value of Health IT
Shows & Panels
Are federal agencies truly managing IT projects incrementally?
Thursday - 12/9/2010, 4:39pm EST
Director, IT Architecture and Systems Issues
Government Accountability Office
As we declared in 1776, we hold certain truths to be self-evident. One long-held truth in the IT community is that it is worlds better to adopt a divide and conquer approach when managing big, complex IT projects that necessitate doing many things over many years rather than to treat the project as a single, monolithic undertaking. In so doing, the many and significant risks associated with successfully managing the project can be spread across a series of smaller, more bite-size project chunks.
My experience over the last 30 years in looking at large-scale IT projects across more federal departments and agencies than I can name has shown that this self-evident truth has been long and widely recognized and adopted when it comes to how IT projects are developed or acquired.
In fact, I am hard pressed to name a major IT project that has not pursued an incremental acquisition or development approach (albeit one could argue whether the increments were always decomposed to a level that the time between deliverables could be measured in terms of months rather than years).
But does acquiring or developing a system incrementally equate to managing it incrementally? In a word, the answer is "no." And, while there may be exceptions, I would submit that federal departments and agencies have defaulted all too often to not managing their IT projects incrementally because they have not invested in them incrementally.
The Clinger-Cohen Act of 1996 and federal guidance have provided a basic framework for investing in IT projects that comports with recognized leading practices.
Together, they set requirements for (1) economically justifying projects on the basis of reliable analyses of expected life-cycle costs, benefits, and risks; (2) using these analyses as key junctures in a project's life cycle as the basis for investment decision-making; and (3) doing so for large projects (to the maximum extent practical) by dividing the projects into a series of smaller, incremental sub-projects or releases.
By doing so, the enormous risks associated with investing literally hundreds of millions and, in some cases, billions of dollars over many years in the hope of delivering mission capabilities and benefits far into the future can be spread across project components that are smaller and thus more manageable and of shorter duration.
In the end, this approach can permit the value proposition of each project increment to be justified up-front and for the accrual of actual mission value to be validated sooner as incremental capability is delivered and put into operation.
But what I have observed in the federal government, and what GAO has reported, is that even though departments and agencies typically acquire or develop systems incrementally, they do not invest incrementally (i.e., forecast return on investment or otherwise economically justify the value or cost effectiveness for each project increment, and then verify the extent to which expected returns and value is actually accruing).
Rather, they have largely treated what I view as perhaps the most fundamental question associated with sound project management — Are we developing or acquiring the right system solution? — as an all-or-nothing proposition.
Restated, they have based the answer to this fundamental question on the inherently imprecise and unreliable forecasts of the collective costs and benefits (or cost effectiveness) of all increments as a single monolithic project — to include those later increments that are so far in the future that it is not even reasonable to expect that any meaningful understanding could exist as to what they will cost to deliver and what they will produce when they are delivered.
A case in point is a billion dollar plus, mission-critical system that at the time of GAO's review was to involve about 20 increments of capability delivered over about 10 years. In this case, the agency had approved investing in the entire project (all increments) on the basis of an economic analysis that projected benefits that exceeded costs by about $2 billion. However, these projections were not reliable for a host of reasons, not the least of which was that the functionality beyond the first two increments had not been defined. Moreover, even though the agency had deployed and was operating the first increment, it was not measuring whether this increment was in fact producing mission value. As GAO has made clear in its reports, such a "grand-design" approach does not constitute wise project management.
At a time when IT project management reform is once again on the table, I believe that this reform should recognize and address this longstanding and fundamental weakness in how the federal government manages IT projects. It is not enough to merely develop or acquire IT projects incrementally. To do so without also making informed decisions about whether the increment is actually worth investing in, and without knowing sooner rather than later whether the increment is living up to its value proposition, introduces the unacceptable risk of developing and acquiring the wrong solution.
Randolph C. Hite is the director of IT Architecture and Systems Issues at the Government Accountability Office.