In a previous post, I described how Luigi Zingales’ framework of regulatory capture also applies to the defense industry. I will here try to describe how that same process of capture may lead to increased efficiency.
During the capture process, we find defense contractors hiring government personnel, providing critical information, and pressuring policy decisions. From each of these channels, we find an interaction between military requirements and technical solutions. We also find a process that synchronizes long-range plans that might otherwise be confounded by a rigid acquisition process.
I will identify three areas where capture can reduce friction and solve problems: (1) Requirements process; (2) Pre-contract decisions; and (3) Change orders.
(1) Requirements process.
The requirements process starts with the a JCIDS analysis of capability gaps. It is run through the Joint Chiefs of Staff, and it is usually military people who connect force structure plans with various strategic documents. Civilians then evaluate and approve the requirements.
The process identifies capability gaps and proceeds to analyze the various solutions available. Key Performance Parameters are then created in advance of contracts going out to industry for design studies, or, if you’re lucky, prototyping.
Notice that contractor feedback is not formally part of the weapon system process until after a great deal of documentation and review. We’ve already had the Capabilities Based Assessment, the Materiel Development Decision, the Analysis of Alternatives, the draft Capabilities Development Document, and the weighty Milestone A review, all before a contract goes out. And don’t forget, you need to justify the funding for the design contract funds two years prior to contract solicitation.
Now, time and time again you hear that the process is to define capabilities and broad sets of requirements. It is not supposed to pre-specify technical specifications. But in many ways, this is a simplistic view of innovation.
Members from the requirements and concepts panel of the Army Materiel Acquisition Review Committee (AMARC) had interesting points requirements. In 1974, the panel reported that requirements did not just increase development cycle time, they could become dangerous without proper feedback from technology-push approaches.
Our team believes that in one sense there is no such thing as a ‘requirement.’ The concept that a description of the end product can be made at the front end of a development program may be responsible for more useless and expensive equipment being acquired than all other causes combined…
If the word ‘requirement’ causes managers to lose sight of the objective of providing operationally useful equipment to the Army, then it should be dropped from the Army’s lexicon.
The panel reiterated the same point made by various others at the time, including Robert Perry, Arthur Alexander, and Thomas Glennan, that a linear requirements-push process without continual feedback from empirical evidence (technology) would stifle innovation.
Here is Maj. J.M. Lutton’s assessment of the requirements process from 1975:
The project officer, usually without detailed technical knowledge himself, had to develop required item characteristics without a factual basis and put them into a document. Where did he get the characteristics? You guessed it—from a fertile and sometimes overactive imagination!
The result was a project that could not be substantiated, that was generally doomed to failure, and that took everyone concerned with its progress an inordinate amount of time to determine that it wouldn’t work.
This is where capture comes in. When the formal process has it such that requirements are generated without the repeated interaction of engineering expertise — expertise the Government stripped itself of long ago — the requirements are likely to converge on poor program choices. The capture process actually introduces some of the non-linear feedback required to generate good concepts.
When a military person goes to industry, they are able to provide forward guidance to engineers. They also have personal relations with Government officials and can stop by to chat about capability gaps. In the process, they can market new types of technologies, acquire feedback, and improve designs. At the same time, Government officials receive new information that may affect their concepts and performance needs. The feedback reduces risk ahead of R&D contracts.
Rick Whittle made a similar point to me with respect to the V-22 Osprey.
In the requirements phase, information from industry plays an important part in shaping requirements towards more realistic parameters. Often, several companies are approaching officials with competing ideas. This flow of information generates helpful options for the Government in advance of the market research phase, which is supposed to start after requirements were set.
This process could be said to bias project requirements toward legacy solutions. It may stifle disruptive innovation. However, a fair case could be made that it generates better informed decisions than would otherwise prevail if military personnel wrote requirements in a technological vacuum along the linear model.
(2) Pre-contract decisions.
After the requirements have been set and layers of approval met, there is another long period of refinement before a contract gets awarded.
Generally, the requirements are handed over to a dedicated program office, and it is the contract officer initiates market research. This often entails a Request for Information (RFI) going out on FedBizOpps. Interested suppliers send back information about how they might meet the requirement.
The resulting information is used to update the language that will go out in the Request for Proposals (RFP). When the Source Selection Board makes a decision on who gets a contract award, they must select the best proposal without modification. It is therefore important that the requirements be correct at the outset, and the language of the RFP be the most informed it can so that contractors optimize correctly. There is a great deal of room for ambiguity or miscommunication in proposal solicitations.
We often hear that getting the requirements right is the most important aspect of a successful contract process. Of course, it the requirements were right, there was probably already numerous back-and-forths between industry and Government in the requirements process. Otherwise, it’s hard to imagine the RFI and its responses would be a sufficient market research process. The capture process is also a process of information and environment, which is dominated by the firms “plugged into” the requirements from the start.
The capture process here can be harmful in biasing the contract decisions. For example, only Government contractors troll FedBizOpps. Information was intended to be sought from all sorts of magazines, journals, and other sources to find innovative firms outside of defense. But that usually doesn’t happen.
Recently, the Section 809 Panel reported that China was trying to buy a US firm with defense relevant technology. The scandal was that the DOD had no clue that the firm existed. Instead, the DOD is trying to plug gaps in the supply chain by giving capital away to favored firms. Hopefully, OTAs/CSOs can mitigate some of these problems.
But the capture process can also be helpful. Provided that defense contractors were the only ones capable of delivering anyway, it eases the flow of information during the market research phase. The Government can play one contractor against another, update expectations as more data comes in, and even benefit from details of internal research & development efforts continuously happening at the contractors.
Having experienced personnel from the Government join industry can help contractors provide high quality proposals that meet expectations. With contract protests on the rise, it is important that award decisions don’t get overturned — resulting in more cost and perhaps the selection of second-best suppliers.
This risk can be avoided when you have Government experts come to industry and help them remain fully compliant with all the regulations. Not only will proposals be solid from a legal standpoint, they can better answer questions of engineering, pricing, management, schedule, etc. When proposals have the kinds of information that the Government is looking for, then the Source Selection Board can better evaluate the offers.
Another point in capture is that in the RFI period, the contracting officer can basically speak with any supplier one-on-one to gather information. Those who take advantage of this can help influence the RFP. If there was no “capture,” such as in conversations, then the only response would be some formal document that might be hard to interpret. Once the RFP goes out, however, the contracting officer basically has to signal information equally to all participants involved.
(3) Change orders.
A signed contract usually has tightly specified requirements in order to ensure that the contractor will meet expectations. The interaction between requirements and technology ahead of contract definition was intended to create detail in accordance with the complexity of the task. Yet, as we have repeatedly discovered, no amount of analysis can erase uncertainty from contract execution — particularly for major defense systems.
Inevitably, there will be changes to expectations along the way. When dealing with new technologies or processes, project success is highly dependent upon the ability of an organization to learn. When updated plans entail breaching a poorly conceived requirement, the contract must be amended.
Change orders can be quite controversial. The contractor claims, most often correctly, that the Government changed requirements during contract execution, forcing a change to engineering designs. Those costs are out of scope with the contract, and should be priced out for reimbursement.
Because of information opacity or mistrust, the Government often views change orders as the contractor making unfounded claims against the Government. Cost growth was not a result of Government interference, but because the contractor was demonstrably inefficient.
More likely than not, both sides are correct to some degree.
The DOD often wants an entirely new type of system to go from a paper design to a fully operable system in just one development contract. That puts a huge premium on predicting the path of technology over many years. The Government even recognizes the likelihood of changes by allowing R&D contracts to be incrementally funded. But the contract requirements are not so flexible.
Now, it would be preferable to avoid locking-in decisions too early in a development contract. But given how the system operates, the capture process can be useful in reducing friction in getting change orders approved.
The flow of information from the contractor in support of the change order is naturally biased and a source of capture. It most likely would support their claims that the work was out-of-scope, or they wouldn’t have submitted it. That means there is usually some factual basis to the claim, even if interpretations may vary.
The environmental pressures are such that Government officials would prefer approve change orders. The contractor, with its earnings on the line, will certainly call foul if reasonable change orders were not approved. They will raise a stink throughout the Department. And the rest of the bureaucracy wants to keep the program on schedule. They do not raise the suspicion of the higher-ups. For example, Navy bureaucrat Gordon Rule denied so many change orders that the bureaucracy moved against him.
The reaction was not totally without cause. Mr. Rule created a change order backlog of $1 billion in 1971, and strained many relationships. It could be argued that his obstruction was more out of ignorance of production and suspicion of contractors than it was good business practice.
Finally, we find that career concerns affect the official reviewing change orders. This didn’t affect the independently wealthy Gordon Rule. But approving the marginal change order — not the fraudulent one — increases the likelihood that the official will earn beaucoup bucks in industry. This also reduces friction to moving forward with work. It can be very costly for work to grind down while awaiting change orders.
It might be confusing that the capture process may increase efficiency of change orders, when really it could be funneling money to the poorest performing contractors. But if the current acquisition process worked without capture, and change orders were difficult if not impossible, then we would have a major set of problems.
The benefit isn’t that fraudulent change orders get approved, but that the marginal change order does. And this allows for more rapid learning within project execution, allowing project outcomes to reflect the full set of information gained along the way (rather than only the information available at the RFP stage).
Conclusion.
This post was intended to show that, due to the rigidity of formal acquisition in today’s defense, the capture process can actually create more effective outcomes than without it. At a high level, this is because capture provides a channel where information and expectations can flow back-and-forth in a nonlinear manner between industry and Government. The end result is an alignment of plans and the ability to update those plans in execution.
This is not to say, however, that there are not better institutional arrangements than we now have. Indeed, the fact an argument could be made for capture as a net positive for defense is likely a reflection of how poorly the process works.
Leave a Reply