It's the requirements, stupid...
I took part in a recent panel discussion at an employee professional development program on the past, present, and future of government contracting. The most interesting panelist was someone I had never met before named Derrick Moreira, who works for a small firm called Censeo.
Censeo provides high-end organizational and operational consulting services to government clients and other mission driven organizations -- helping them with strategic sourcing and other areas where federal agencies would do well to emulate the procurement practices of successful large private firms. Moreira worked at the global management consulting firm A.T. Kearney before joining Censeo.
During the panel (which was part of a larger program sponsored by FedBid, a firm I have long worked with as a paid advisor), both of us shared frustration with the glacial pace of adoption of strategic sourcing, which is really a low-hanging fruit for cost savings for government. People had already started doing this 20 years ago when I was in government, and the pace of change has been almost criminally slow.
But for me the headline in Moreira's presentation was his response to a question about what the one single change that, if made in federal contracting, would have the greatest impact on improving how the system works.
Moreira's answer? Improve requirements.
Compared to the quality of requirements he normally saw in the private sector, Moreira said, what he typically sees in government is low. Requirements seldom describe what the government wants in terms of results, but rather just specify processes, procedures and deliverables. Requirements from one area are often applied to another area, even when important details of what the government is buying are different.
Moreira suggested (and I agree) that poor requirements -- i.e., the government's statement in a request for proposals about what it wants the eventual contractor to provide -- often result from an effort to get through a procurement as quickly as possible, without thinking through whether the contract, once awarded, will succeed. At best, this creates extra costs and wasted time down the road, as the government realizes what it asked for isn't what it wants, and that the requirements need to be renegotiated -- now in a non-competitive environment that is less favorable to the government. (Contract changes are inevitable on any complex, lengthy contract because the world changes and upfront knowledge is imperfect, but that raises separate questions.)
A particular nightmare can occur in the increasingly common lowest price technically acceptable (LPTA) environment, where contractors have an incentive to provide the least possible to keep their costs down, which in the case of a poor requirement can easily result in totally non-functional deliverables.
Sometimes a government program office does not have the technical skills to write a good requirement. In these cases, the program people should be looking for third-party help. GSA has made available assisted acquisition services (though its Office of Assisted Acquisition Services), which in the IT and professional services areas includes providing people with IT technical skills who could help with writing requirements. (Though very complex requirements are likely to be beyond GSA's skills as well).
However, lots of customers have been unwilling to pay for this help -- apparently preferring failed acquisitions -- and GSA has not been emphasizing this service as much as it had previously. Additionally, for complex requirements, some agencies have used third-party companies, including Federally Funded Research and Development Centers, to write requirements.
All of the above -- including government, God forbid, slowing down the procurement process a bit to create requirements that make success more likely -- are possible ways to go, but the current situation virtually defines penny wise and pound foolish.
Note: This article was updated on Nov. 7 to clarify Censeo's client base and Moreira's professional history.
Posted by Steve Kelman on Nov 07, 2014 at 10:35 AM