Delivering IT projects in quick increments: 23rd time's the charm?

Since the early 1990s, when the General Services Administration issued its first report urging the government to move away from "grand design" projects that aimed to deliver an entire new IT system at one time -- with the time being years after the project began -- the idea that it makes more sense to deliver new IT systems in quicker, incremental chunks (now often called "agile development") has been discussed around government. During the late 1990s, this was one of the primary messages of Raines' rules, developed by Franklin Raines, who was then the director of the Office of Management and Budget, as a series of guideposts for improving the delivery of IT projects.

The arguments in favor of delivering new capabilities in chunks – with increments delivered in a six- to 18-month time frame -- remain what they were 20 years ago. The main technical argument is that it is very difficult for users to know what they want before they have actually worked with a new system. Quick releases provide quick user feedback, which allows modifications and course corrections. An incremental approach also helps reduce requirements creep, since requirements can be frozen, or nearly so, while an increment is being developed, with changes waiting till the next increment. Incremental releases allow quicker identification of troubled projects, allowing redirection or cancellation before too much money has been spent. More recently, the use of system architectures has made it easier to have contractors compete increment by increment, unlike the case of grand design systems which typically require a single contractor. Whoever wins a given increment simply bolts it onto the common architecture. And increments more easily accommodate approaches based on the integration of commercial-off-the-shelf integration technology.
 
There are political and psychological advantages as well. Early wins on increments build momentum and enthusiasm that a program is working. And it shouldn't be sneezed at that an incremental approach is more closely tied to the time frame of agency political appointees, who are more likely to show interest and involvement in an IT system if they believe it may actually deliver capability on their watch.
 
The recently released report of the Government Technology Opportunity for the 21st Century panel, which was sponsored by the TechAmerica Foundation (an IT industry group), which I co-chaired, makes a move toward more "agile development" one of its four main recommendations.
 
It is fair to ask why this recommendation should have any impact now, when so many similar recommendations in the past to do this haven't changed things much.
 
Of course, I can't predict with certainty that the 23rd time will be a charm. However, there are some differences. First, these recommendations emphasize what needs to happen for an agile approach to work – the development of templates (probably by the CIO and Chief Acquisition Officer Councils) and training for managing and contracting for agile development; changes to the OMB 300 process away from 10-year plans and projections and a commitment by industry to align its own capabilities toward doing agile development (IT firms with a significant commercial presence are already doing this for their non-government customers).

Second, this is a personal priority for federal CIO Vivek Kundra and for many agency CIOs. And third, there is a generational transition going on in the federal IT workforce, as government hires young people whose only training and experience involves agile development -- and who may refuse to work in a traditional government development environment.
 
No guarantees, but maybe this time?