5 best practices for agile procurement

Federal CIOs once spent nearly all their time on infrastructure. Today, however, thanks to commoditization and cloud technology, savvy CIOs are now grappling with the idea that they are no longer primarily infrastructure-focused leaders but rather key players in advancing their agencies’ missions.

As I wrote previously, CIOs must adopt an application development and management mindset. The shift can be difficult because the rules for managing infrastructure differ from those for managing applications. Nowhere is that difference starker than with procurement.

Civilian agencies are beginning to introduce agile delivery contracts, with U.S. Citizenship and Immigration Services’ Flexible Agile Development Services (FADS) contract serving as a model. Here are five best practices that can help government CIOs make the shift to agile procurement.

Award full-and-open contracts for small teams

The use of small teams, which is central to agile, is often distorted into a mandate to contract with small companies. That confusion has cut off access to more than half the talent pool and most of the real-world experience. Additionally, it drives up costs when small businesses can’t fulfill demand and must subcontract for talent, thereby adding multiple layers.

Instead, contracting for small teams regardless of company size levels the playing field.

Design contracts to reward delivery

Agile development is sometimes confused with “one and done” (a short development effort with no follow-on contract), and short contracts of three to six months are expected to reap results.

Mission-centric applications cannot be built in six months. Team effectiveness and efficiency take months to create; team and government collaboration takes quarters to build; and learning the application domain and mission can take years. Those factors contribute more to success than the development methodology alone.

Therefore, CIOs should award three- to five-year contracts, demand software deliveries at six-month intervals and replace contractors when they don’t deliver.

Use firm-fixed-price contracts with monthly milestone payments

The idea that a customer will know exactly what to build or the contractor will know precise staffing needs at the beginning of a project is pure fiction. Yet many contracts ask for a specific set of labor categories, turning the bidding process into a rate shootout.

Contracts should follow the FADS model, and specify what to deliver (working, tested, documented, maintainable code) under what working conditions (i.e., the technical and mission environment). With less specificity, the staff makeup is allowed to adapt.

In short, the government should buy delivery capacity, supported by a firm-fixed-price contract.

Rely on technical demonstrations

Traditionally, software development requests for proposals ask for 100 or more pages of text in response. How can the ability to deliver software be measured by prose?

Instead, the written technical approach should be six to 10 pages, and teams that pass an initial review should be evaluated based on a live test of their software delivery skill. Good agile contracts, like the General Services Administration’s 18F agile contract, require hackathon-like settings to measure bidders’ professional skills. Most serious professions accredit this way.

Look for past performance specific to agile delivery

Agencies should only consider contractors that have experience delivering with agile methods, specifically in the federal sector. Further, they should seek contractors that have experience helping stakeholders move toward agile methodology. A sound vendor will help agencies adopt good practices, while an inexperienced vendor can cause problems that agency executives won’t soon forget.

Keep in mind that even though an organization adopts agile procurement, the CIO is still a long way from nirvana. He or she needs to transform the IT shop, and that’s a topic I’ll discuss in the next article.