Let’s say the Government has awarded R&D work to a contractor. During the course of the contract, the engineering team spontaneously generates new insight. The team innovates a component design that dramatically improves system performance in one critical aspect. Yet it negatively impacts another. The new design would far exceed one contract objective only to breach another requirement’s threshold, incurring contract penalties.
What should contractor management do? I see three options:
(1) Stick with the original plan to deliver on the prescribed requirement, then market the innovation as a new program.
(2) Seek to convince the Government customer of the design’s promise, amend the contract, and deliver on a new program requirement.
(3) Deviate from the requirements, deliver the re-designed product, and suffer the consequences.
Now, option 3 jumps out as the least desirable. Before we address that, let’s consider the downsides of the other two.
Let’s say the company delivers the original requirements and withholds the innovation. Managers send the idea to the internal research & development department for maturation. It then will enter a long process of “marketing,” where the idea is socialized with the services. When a new program comes out several years later, hopefully the company will be ahead of the other companies (who have had time to start catching up) when the development contract is competed.
Under this scenario, the company will have to wait for several years and burn money on IR&D and bid & proposal cost, only to potentially see themselves lose the program to another company who bought-in on production, or simply didn’t understand the challenges involved. The process isn’t as low risk as it might have originally been perceived.
Moreover, either you send your crack engineering team off the project to do the IR&D (where their passions are) and accept significant risk in the contracted project, or, you keep the innovators on the original project requirements, and they lose their enthusiasm as others are taking over and potentially fumbling their idea. The disgruntled innovators leave and become the competition that beats you when the RFP hits the streets.
How about convincing the Government customer of the new design’s promise? Well it is not only the program office that needs to be convinced, it is all the layers of military staffs, service headquarters, OSD, and even the President and Congress. If it requires a change in the pattern on funding — R&D projects are often incrementally funded across several fiscal years — then that requires a great deal more coordination with other programs due to the resource constrained nature of the budget.
Even if we assume away funding changes, the new program will have to be reviewed by the Milestone Decision Authority, and coordinated with the requirements community among others. Usually there is a lot of institutional bias in the existing technologies and doctrines, and the requirement wasn’t arrived at arbitrarily. It has real significance. Even if the new technology’s merits are plainly obvious, by the time all the approvals are granted, it is too late.
The project needed a fast, real-time decision. Are they taking the new path or the old? Any time spent convincing technological outsiders adds to the cost of taking the new path. It will also drain the enthusiasm and spirit of the engineering team who might otherwise volunteer their overtime to solve critical problems. And again, the Government decision might decide to stand up a competing program in a competition which you may lose out on.
The option not discussed, deliver the original requirements and suppress the innovation, is by now starting to look pretty good. You already won the program development. Production and sustainment goodies are within your monopolist grasp. Why ruin a good thing? Why accept increased risk for potentially little or negative returns?
Well that’s depressing. Think about it. The engineering team innovated a new solution. That was done during the course of execution for free. It gives everyone involved a free option. And from the perspective from the ones with the most knowledge about the innovation and its prospects — the engineering team — it is an option that can pay off handsomely. Instead of continuing course, you could pay a small fee of time and cost to see what a new concept could deliver that may leap-frog the existing concept. If it does make the existing one obsolete, then a quick change saves a tremendous sum of money and time that would otherwise get sunk while the bureaucracy slowly pivots the front-end of its requirements stage to the new innovation.
Consider it in another way. If change approvals on the Government side were fast and wise, then why wouldn’t the Government forego the contract all-together and internalize the engineering team? After all, if it were fast and wise, that means the Government is a good on-the-ground manager. And when there is more uncertainty, Ronald Coase found it is more efficient to internalize production knowledge rather than incur the transaction costs of contract requirements and changes. But it is highly unlikely that the Government knows more about technical feasibility than the contractor, particularly since it has lost most of its in-house talent, so change approvals will be slow and ill-judged.
And so we are left with the third option, just execute the innovate without approvals. It comes from the cliche it’s easier to ask for forgiveness than it is to get permission. And forgiveness is what is sought. If the engineering team was right, then the unbiased user would be happy with the result, and should express gratitude toward the engineering team for taking the risk and delivering a superior product. Of course the engineering team could be correct, the user happy, and the DOD bureaucracy or Congress is still infuriated. Or, even worse, the engineering team was wrong and you have a big lawsuit on your hands.
Perhaps most surprisingly, if instead of innovating something new, the contractor simply experienced poor performance and saw 2x cost/schedule growth, then nothing big would have come of it. That is not an unusual outcome, and it would likely get the funding without too much difficulty. But consider the problems with getting that same result — 2x cost/schedule growth — but you also pursued a new idea that looked promising and failed before delivering on the original requirements. That would bring a great deal of wrath that 2x cost/schedule growth itself never would have. And yet you also learned something. You learned what did not work. But, you might have also learned something revolutionary that did work.
Certainly this simplified thought experiment has overlooked critical aspects of the problem, but the point is that there really are no good options for unscheduled innovation in the Department of Defense. As former ASD Comptroller Robert Anthony said when criticizing his predecessor,
Strategic planning is essentially irregular. Problems, opportunities, and ‘bright ideas’ do not arise according to some set timetable
But that is exactly what is expected in the defense system of innovation. Far from bright ideas occurring to the acquisition timetables, it could very well be that the process of innovating one thing is precisely the best time and place to change direction and innovate another.
Leave a Reply