In June 2012, the White House issued guidance intended to make the U.S. government a better customer of information technology. This came in part from a document, Contracting Guidance to Support Modular Development. It showed the government’s attempt to encourage and embrace a variety of commercial industry trends that were yielding better results for IT investments.
Among the practices encouraged by the White House was agile, the collaborative and iterative development methodology that’s been adopted in private sector for some time. The guide also encouraged modularization. In part, that means acquiring and/or engineering software with reuse in mind and as a driving consideration. That can mean being ever conscious of the “build vs. buy” decision, with greater emphasis on the search for what is available before building. It also means, if “build” is the choice, to build and deliver IT investments based on modular frameworks that can be developed, delivered and tested in smaller chunks than has previously been the norm in government projects.
Taking agile to a higher level
The federal government guide references commonly available project-level information focused on execution of projects. It also applies that guidance to a higher program level, where it discusses how to structure acquisitions so that they benefit from agile and modular methodologies. The guide suggests improvements in the contract award structure, such as breaking large contract awards into a series of smaller ones, allowing acceptance criteria to be applied earlier in the process, with payment more solidly tied to success criteria.
One size does not fit all
Over the years, the Department of Defense, as an example, seems to have swung between extremes of strictly prescriptive versus only informative guidance regarding contract acquisition. The government’s attempts to be prescriptive were intended to promote best practices and avoid repeat failures of the worst kind, such as lack of using version control systems in software development.
A challenge with being prescriptive is that it assumes that “one size fits all” with respect to what is being prescribed. Best practices aren’t static. They evolve quickly over the years, far more so than federal government guidance information. The prescriptive and specific nature of earlier government contract guides might help bad vendors avoid the most obvious pitfalls — but it doesn’t make them good. Meanwhile, being prescriptive can stifle innovation of better vendors that have evolved their own practices to a state more mature than the government would prescribe (enter waivers).
The 2012 guidance information reflects a more intelligent and balanced approach. The guide discusses various factors, methodologies, contract styles and acquisition approaches that might previously have been prescribed by a contract. But it now does so in a way that is more amenable to interpretation. That approach strikes a balance between promoting and institutionalizing good practices while not falling prey to the illusion that good guidance can fix a bad vendor, the kind that contributes to boondoggles. The wording promotes awareness and taking advantage of new and emerging technologies and trends as part of acquiring IT.
In addition to guidelines related to modularization and agility, the guide discusses considerations to avoid contract situations that shift undue risk to the government customer or that give unfair advantage to particular vendors in competitive situations. For example, the guide suggests that a vendor helping develop requirements for IT acquisitions tries to avoid writing requirements in a way that unfairly drives business to that vendor.
Reading between the lines, one might read into the guidance information a set of war stories of a once-bitten, twice-shy customer. The hope is that better awareness will make the government customer wiser.
Continuing the theme of avoiding a once-size-fits-all mentality, the 2012 guide also discusses improving how the government leverages competition among vendors to benefit the taxpayer. It recognizes both the value of competition and the costs of arranging for competition. Delivering actual taxpayer benefits from competitive bidding remains a challenge for the government.
What’s missing? Security!
Other than referencing the Information Security Office in the User Acceptance Testing section of a sample Performance Work Session in the appendix, the guide does not promote security considerations. In an age of growing cyber warfare and potentially cyber terrorism, it seems that guidance discussing the acquisition of IT investments should at least reference security in a meaningful way. Security represents a risk to those investments that needs to be better understood.
Clearly, the security needs of various government agencies differ, and specific guidance on IT security comes from other government sources as well. But perhaps the next update of contract guides will include a discussion on the degree of security necessary in various contexts and stress its growing visibility and general importance.
So, is it working?
Three years later, it appears that at least some of the guidance is indeed having a beneficial impact. Although the information available to this author is related to only some government contract situations, some government agencies are clearly being smarter about purchasing IT services and working with IT vendors to manage projects according to modern, modular, and Agile tenets.
Changing the large-scale IT purchasing behaviors of so many government agencies takes time. In my work with both government agencies and vendors since mid-2012, there are clear signs that both government customers and vendors are focused on making better IT investments for at least some government agencies.
C. Thomas Tyler is a senior consultant at Perforce Software.