Jeff Boleng [USD(A&S) Special Assistant for Software]: Should we separate our hardware procurement and our software procurement, and maybe even look to different vendors to do each? Because one of my arguments is that I want people really good at software doing my software, and people really good at building airplanes, ships, and tanks to do that. But a lot of time we pay the airplane, ship, and tank people that haven’t demonstrated their software prowess, the way other companies have. Do you think that is a feasible acquisition strategy?
Jennifer Pahlka [Code for America]: In the state of California they’re trying a new new model for a really big software system where they’ve chunked it out into a bunch of bits — its very modular — and different software people can do different bits of it, and they’re building the capability in-house not to develop the software, but to manage the program such that this vendor can be taking care of this bit for a while, they can bring the bits together, if one part isn’t working they can move one of the vendors onto a different module, and I think that gives them more control.
But its definitely not a “here’s one giant thing and one vendor is going to do the whole thing.” What that requires is much more software capability in your contracting and program management….
That was from a great YouTube conversation hosted by DAU called “Changing Software Acquisition in DOD — Roundtable with the Defense Innovation Board.” Pahlka brings up two important points which have been recurring themes on this blog.
First, she emphasizes the role of modular architecture and recombinative innovation. Major systems should not be bought as a giant package from a single contractor. Instead, contract tasks should be partitioned where feasible and provided to the firm best suited to perform.
Of course, that creates integration risk — that the various components will not integrate into the desired system and functionality. Yet that’s why Pahlka later emphasizes that it is often best not to pursue an entire system concurrently, but tackle the hardest problems first and then wait until more information is available to decide on future actions and eventual integration. The DOD often pursues low-risk aspects of a program simultaneous to high-risk, which creates a great deal of rework and added cost.
The modular method of system development was pretty common up until the 1960s when Robert McNamara took the helm. Even for the Air Force, which was the first to use the tightly coupled “systems” approach, was opportunistic and didn’t set detailed integration plans before work start. Of the last 6 fighters developed in the 1950s, 4 ended up with different engines than planned, 3 with different electronic systems, and 5(!) with different airframes. Such flexibility would be unthinkable in today’s acquisition, particularly because such changes to plan makes one look like an oaf to top leadership who observes from far away.
Partitioning contract tasks both by technical component and across time was advocated for by Nobel Laureate Oliver Williamson during is time at RAND. Here are Williamson’s conclusions on the “manifold” benefits of partitioning tasks:
- It reduces the amount of uncertainty and hence increases objectivity in contract negotiations, reduces the felt need for defensibility in administering contracts, and permits more reliable evaluations which in turn allow cost-performance reputation effects to be assigned with confidence. Each of these effects should help to prevent excessive contract costs.
- It creates a contract environment in which the full potential of parallel R-and-D approaches… can be exploited.
- It complements R-and-D strategies which emphasize the need for maintaining options by providing support for work on adaptable components and flexible capabilities…
- It permits greater competition by increasing the number of eligible contractors.
- It lends itself to sales and employment stabilization.
Of course, with the partitioning of contract tasks comes added responsibilities to the government program office. This is particularly troubling given the rapid decline of in-house government competence that accompanied McNamara’s managerial revolution. It favored a single prime contractor to handle all aspects of the government defined program.
The second important point Pahlka brought up is that the government needs additional in-house technical capability to held guide modular program and make incremental decisions. McNamara’s management strategy presumed that all important decisions could be made before-the-fact, and would be embedded in the specifications of the approved program budgeted in the PPBS. There wasn’t much left for the government program office to do but administer the approved policies.
However, with modular design, decisions are incremental. The program office is required to make genuine choices. There is not time to go through 2-5 years of requirements coordination, then another 2-3 years to get the budget approved. But in order for the program office to make wise choices, it needs to be staffed by experienced technical persons with relatively long tenures.
For example, the Polaris missile system was primarily managed by a large Navy special projects office (SPO). The SPO chunked out the program into various components and contracted for them separately. Most components had 2 or 3 contractors performing parallel efforts to minimize risk. Detailed integration plans were held off until many uncertainties had been resolved. Oskar Morgenstern, for example, had “great doubts” about the success of Polaris had the “systems” approach been applied from the start.
A major issue with modular architecture, however, is that it requires incremental decision-making. The DOD exercises management control by stating up-front the requirements, budget, and methods of evaluation. If modular architecture is taken seriously, and components are worked on independently of the final system, then the DOD would have to completely change its methods of approving programs and appropriating funding. It is clear that the proposed Section 801 authorities would not provide lower level decision-makers the flexibility required to make such incremental decisions toward continuous delivery.
Leave a Reply