The dangers of low-price contracting
Report warns the approach raises the risk of failure
- By Mark Hoover
- Nov 28, 2012
Because they appear to be cheaper, low price, technically acceptable procurements are on the rise, but TASC Inc. is making an argument that these kinds of contracts pose a danger to the government over the long haul.
In a recent report, the company spells out when these deals should be used and when they should not.
Low price technically acceptable deals are usually made for commodities—facility maintenance services, laundry services and custodial services, to name a few—for three reasons:
- There is little difference between competitors; no one competitor is going to be significantly more qualified than another.
- The stakes are low so if there is a failure the resulting damage is not extensive.
- Commodity services are simple enough that their requirements can be clearly defined.
Critical professional services are the exact opposite, according to the report:
- There are significant differences in how qualified companies are for the mission.
- The stakes are very high; a failed mission could result in a national security risk.
- Professional services for critical missions are often very specialized, and so it is difficult to clearly define their requirements.
What makes the lowest price technically acceptable approach favorable is that it seems to be a cheaper option to conduct business in today’s government market where budgets are so tight.
But using the lowest-price technically acceptable approach for non-commodity services can result in program and systemic risks, TASC said in its report.
Program risks can include a “significantly underbid work effort and an increased risk of failure,” TASC said. Plus, any shortcomings on a project require money to fix, making the effort more expensive overall than would be a classic approach.
Systemic risks are more detrimental on a fundamental level. Independent research and development is likely one of the first areas to be cut in this scenario, putting “the government at risk of losing access to future technology innovation and consequently the cost savings associated with technical advance,” the company said.
Another area that might suffer from cost cutting is learning and development; however, this is the area that helps, among other things, “transfer knowledge from more experienced (and more expensive) engineers to less experienced (and less expensive engineers,” TASC said.
But if lowest price technically acceptable deals continue to rise, TASC did suggest ways to make them less risky.
First, the qualifications for “acceptable” must be made much more rigorous, to the point where “some offerors are found unacceptable or only one offeror is technically acceptable,” TASC said.
Qualifications for this could include scenario-based evaluations that have teams illustrate their breadth of expertise, even going so far as to “provide solutions to specific problems that may arise during the period of performance,” TASC said.
This would give a team an opportunity to “demonstrate that it understands the work sufficiently to solve problems and exhibits the flexibility and adaptability to address changing priorities and circumstances, which is not always brought out in [lowest price, technically acceptable] awards,” the company added.
Another fact to weigh is past performance. It would speak greatly of a team’s abilities if they already have projects similar in “size, scope, and, especially, complexity,” TASC said.
At the end of the report, TASC made two recommendations:
Either issue “solicitations for complex and/or mission critical services [that] adopt a classic cost-technical tradeoff approach for achieving best value,” or make technical and past performance requirements “rigorously and precisely defined to ensure the government receives something that is truly and rigorously technically acceptable.”
In other words: Quality or bust.
Mark Hoover is a senior staff writer with Washington Technology. You can contact him at email@example.com, or connect with him on Twitter at @mhooverWT.