the lectern banner

By Steve Kelman

Blog archive

An IT moonshot: Can government IT development come to look like SpaceX?

steve kelman

In my last blog, I discussed the challenge posed by Elon Musk’s firm SpaceX to traditional ways of government contracting for satellite launches, represented by the Boeing-Lockheed United Space Alliance. Unlike traditional satellite (and IT project) development, SpaceX has taken up the challenge of introducing competition into launches and to develop satellites that are offered to the government at a fixed price. (In the case of SpaceX, that fixed price is about half of what the traditional contractor is charging).

If we changed the way we developed new IT systems to introduce competition in the ongoing development process (rather than our current mode of one upfront competition followed by the winning contractor being a sole-source supplier), and if development work occurred on a fixed-price basis, could we reproduce SpaceX’s achievements in government IT? Consciously imitating a metaphor taken from the space world, I will refer to such a possible transformation as a government IT moonshot.

Could this actually happen? And if it did, would it produce changes similar to the difference between the United Space Alliance and SpaceX?

Well, like most moonshots, realizing either and especially both outcomes would be a long shot. And clearly, an important part of SpaceX’s success has to do with the energy and brilliance of Elon Musk. Simply imitating institutional features such as competition and fixed-price development does not guarantee the same results as he has achieved.

However, my view is that, if there are to be dramatic improvements in IT development in government, the best chance is through some form of agile development approach. (Note that the analogy to SpaceX’s successes here is figurative not literal; you can’t use agile IT software development methods for a satellite. But SpaceX uses innovative approaches appropriate to the product being developed.)

I have blogged in the past about the potential of agile to increase IT project success rates by dividing up the work into a large number of brief sprints. This approach allows much earlier, more frequent course corrections compared to traditional waterfall projects, which have huge sunk costs that occur before the government really knows if it’s on a good path. That can be done, however, using only one contractor, and doesn’t require that any individual sprint be done on a fixed-price basis.

I want to put out there for discussion in the community what we might want to call agile 2.0 – which introduces multi-vendor competition for agile sprints and explores having individual sprints done on a fixed-price basis. Something close to this has been pioneered by Mark Schwartz, the CIO of U.S. Citizenship and Immigration Services, and by work 18F has done with the State of California on a new case management system for child welfare programs. In preparing this blog, to get and test ideas I spoke first with my Harvard colleagues Nick Sinai and David Eaves (Eaves is completing a Kennedy School case on the California system), and then with Schwartz and with Greg Gershman, who has worked both for traditional government contractors and for the government, and now runs Ad Hoc LLC, a small firm in the agile space.

I actually started to be interested in ongoing competition for IT systems development when I was in government in the 1990s, suggesting multiple awards for overall development contracts and competition for individual task orders under those contracts. My reasoning that this would provide both performance and price pressure not present in the traditional system.

However, at the time I was shot down on the grounds that this was not feasible, because code developed by one contractor could not easily be made to talk with that another contractor would develop. Nice idea, Steve, I was told at the time, but it won’t work.

Well, a key piece of news for the ability to improve government IT development is that for the last five years or so, this has no longer been the case. Jeff Bezos at Amazon was an early pioneer of using what became known as application programming interfaces, standardized protocols to allow communication among code developed in different parts of the company, conceptually similar to code developed by different contractors. Combined with continuous integration, where the work of multiple developers is integrated in real time, using multiple contractors on a project has now become very feasible -- though its actual use in government is still in its infancy. Furthermore, much of the existing use of multiple contractors in IT projects involves a sort of parallel play, where developers are working on very different elements of a system, and the code for these different elements is then integrated, rather than a truly competitive environment where different vendors are working on similar things.

In an agile world (which did not exist when I was thinking about this in the 1990s), there is an additional advantage to multiple contractors -- if the approach one is using has run into trouble, and agency can easily switch to another before too much damage is done. It adds to the risk reduction advantages of agile over waterfall development.

Performance and productivity pressures in a multiple award world come from the ability to jigger around the amount of work given each of the multiple award contractors based on their performance in earlier sprints. This is key to what has been done at USCIS, where the agency reassigns among contractors every six months the number of teams assigned to the contract based on earlier performance. (It should be noted that such reassignment is easier for large than small business, because the former have an easier time reassigning staff. The government may need to be more generous about guaranteeing a minimum amount of work in a small business environment.)

The last piece is moving toward a fixed-price environment. The dramatic shortening of the size of chunks of work -- sprints or a suite of sprints -- makes bidding a fixed price much more practical. Uncertainty in an agile environment about what the “requirement” is sets a limit to that: What one can hope for might be a fixed-price level of effort bid, where the government evaluates afterwards how much different contractors accomplished for the fixed price. As a project moves from initial stages and people get more experience with what is going on, actual firm fixed prices for a requirement, particularly for very short sprints, may become more feasible.

Could these approaches, taken together, revolutionize government IT development? To return to the space metaphor, I am hesitant to promise the moon. And many details must still be worked out in practice. But I would really like to see a dialogue about whether we ought to be moving much more in this direction. Comments to this blog, and other forums for engaging this question, are welcome.

Posted by Steve Kelman on Jan 09, 2017 at 6:15 AM


The Fed 100

Read the profiles of all this year's winners.

Featured

Reader comments

Fri, Jan 13, 2017 Mel Ostrow

This is moving a mountain. Comments are a good hint that people are hide-bound, suspicious, and would not like to change. Too much labor would be saved by both vendors and the government. This approach directly threatens the iron rice bowl of Federal sys dev. I will be necessary to establish an alternative source of adequate jobs before such people will budge. Remember, the feeelthy lucre of the Federal IT world is: future jobs. Retiring government people take them all the time.

Tue, Jan 10, 2017 GVRANGE

Steve's article brings up a clear description of pros & cons of IT Government contracts and I appreciate Jeff Myiers inside into Government IT Contracts & Procurement.
My concerns are always related to how IT supports and interfaces with one or several agency or multi agency IT Systems.
Elon Musk is deploying an entire functional system with a mission. If we want to unify the Government Systems that would entail a lot more than deploying IT Development for specific end use.
Classification alone makes it for a great management nightmare. A Health Care Moonshot program entails a complex system involving health care records, medical test results, multi-clinical procedures, devices, analysis that have potentially critical ownership rights and thusfar have been carefully and carelessly protected by agencies, medical teams, on going research, bio-pharma & pharmaceutical corporations conducting clinical studies. I hope the moonshot program lives up to regulatory expectation in place and new policy to be legislated.
The USA Army Medical Meterial Command and The USA Navy have huge systems in place accounting historically for their mission - The Soldier/Sailor's Health".
How corporate, banking, health, medical, government ID personal records are so casually treated even after regulatated systems are implemented, validated, and deployed but not properly managed calls for a Global IT Systems assessment and risk management plan forward.
It's my experience contract cost competition has been in place for the last decade and systems are in place to review contracts. It's a waste of $'s when they are given to the lowest cost or fix price bidder unless the right pre-contract clauses are in place. It's at the end the mutual burn factor.
I believe in QUALITY before anything else, attempts to compromise it. ELON MUSK has demonstrated that already several times in his technology wins & losses - before and during space-X in all his Enterprizes.

Tue, Jan 10, 2017 Owen Ambur Hilton Head, SC

For many IT projects, the key is to use open, machine-readable data standards. Projects are more costly and switching costs are too high because the focus is on the software rather than the data requirements. Software components are transitory and should be fungible. What should be persistent and easily (interoperably) shared across IT systems are the business records.

Mon, Jan 9, 2017 Jeff Myers Washington

Two comments, Steve. First, I think the big deal with SpaceX is that there is a clear end-objective (launch the satellite into orbit successfully), and Elon Musk doesn't put up with government prescribing any of the intermediate details. He can thus do it in innovative and completely different ways than Lockheed Martin/Boeing, and different ways that the government might try to require. Nothing about the process is customized to the agency's demand. With IT systems, the end state is vague, agencies tend define lots of custom requirements, and agencies often prescribe major facets of how the work must be done (in addition to how the resulting system will look, work and what function it will perform). These constraints substantially reduce the hope for savings in IT like SpaceX offers. Second, and unrelated: Contractors - especially small ones, need to keep their staff billable. If an agency wants several vendors to compete for each sprint of agile development, a vendor may fear that their staff will be busy one week, and idle the next. Thus the efficiency motivation from the competition may be offset by the fear and risk premium for vendors that expect their staff to be 50% billable instead of 95%+ billable. The exception would be free-lance individuals and people who are moonlighting - those types might be able to survive with or without compensation on any given week. However they aren't likely to be able to provide development services at any significant scale.

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above

More from 1105 Public Sector Media Group