Opportunities and challenges for the program manager

For bringing innovative solutions to the Department of Defense, the contract mechanism is an important tool. But contracts are more than a tool for stating requirements and price. They set the context for a relationship between the buyer and seller.

Over the last few years, the DoD has innovated the contract process itself, raising important questions about the role of program managers. Should they lead the program and solve major problems, or are they merely its caretaker?

Contract Innovation

When the DOD wants to buy innovation, there are two important contracting methods. First are the Other Transactions Authorities (OTAs), which bypass thousands of pages of regulations. OTAs are primarily intended for research and prototyping by innovative firms that otherwise wouldn’t work with the government. OTAs were $200 million in 2013, growing to $2 billion in 2017. While that is only about 2% of RDT&E funds, its growth seems to be continuing.

The second is the Commercial Solutions Opening (CSO), which is a process that can use either OTAs or contracts abiding by the usual regulations. While the government usually provides contractors a “take-it-or-leave-it” proposition in the traditional contract process, CSOs create a “nonlinear” contract process. What makes it non-linear is the intended back-and-forth of a CSO.

A single CSO can pursue many ill-defined requirements and technologies, and make awards to several contractors over a long period of time. A contractor may submit a 1-2 page white paper, and even if the solution is “out of left field,” those that are promising will be invited for a pitch. The pitch may lead to contracted work. Each contractor is always at risk of being replaced by another, better performing, contractor on the same CSO vehicle.

The CSO evaluation method is based on merit rather than lowest-price or best-value. Merit gives DOD officials greater decision-rights to award a contract, even if there is a lack of overwhelming quantitative support. CSOs recognize that it is, in fact, dangerous to proceed using precise specifications and costs in the earlier stages of R&D. It invites rework when assumptions prove wrong, in addition to the neglect of new opportunities that may arise.

Platform Design

In general, OTAs and CSOs are found inappropriate for full-scale development of major system platforms such as ships or air vehicles. But they are useful for smaller-scale projects within a disaggregated system of systems framework, or for rapidly upgrading platform components like the fire-control system, radar, power plant, and so forth.

CSOs in particular help break the systems solution into smaller pieces. By partitioning the task into smaller bits, the government can hedge against two risks. First, that there may be several feasible technical solutions available. And second, that the direction of development and integration may change due to information learned along the way. In essence, CSOs give the government the most valuable asset it has in R&D, management of real-options.

With OTAs reducing transaction costs further, CSOs provide enough flexibility for the DOD to become a more welcoming customer to non-traditional defense firms. The concept of a platform with partitioned components also better reflects what’s happening in the new economy. Tech firms like Facebook (for social media) and Amazon (for cloud computing) have created powerful platforms, opening up their architecture so that other firms can come in and create modular applications that provide real benefits to their customers.

CSOs also seek to gain from modularity of design. While the platform is a major investment, all the component parts can be swapped rapidly. Amazon, for example, doesn’t solicit proposals for new apps on its AWS cloud computing platform. It is open. Other firms are more-or-less free to build applications on top of AWS, which results in increased value for all participants.

While the DOD has been excited about modularity for some time, it has not yet led to much success. For example, the Littoral Combat Ship was supposed to be able to swap out modules such as Marine Counter-Mine (MCM), Anti-Submarine Warfare (ASW), and Surface War (SUW). That program is largely considered a failure. But perhaps that was because it sought modularity within a linear framework of traditional processes.

The Program Manager

CSOs and OTAs are used primarily for innovation, providing an open competition based on the subjective idea of merit. In addition to business acumen, the decisions require a higher level of competence in matters of technology and military requirements. The contract is no longer starting from a fixed set of requirements which all bidders optimize against. Both requirements and technology are flexible.

But after so many years of centralized decision-making, it isn’t clear that DOD program managers have the necessary qualifications to make these R&D decisions, particularly since the demise of the in-house technical services. Most of the important program decisions have tended to be made by various offices in the military staffs, service headquarters, and the Office of the Secretary of Defense, extending even into Presidential and Congressional offices.

Program requirements, as well as their cost and schedule, are determined bureaucratically. With so much definition built up-front, there is little discretion in the execution phase without reach-back. Managers were largely executing “standing orders.”

Under such an environment, the DOD program manager often spends far more time interfacing with his or her own bureaucracy than with the contractors themselves. Further compounding problems, program manager tenure often lasts only a couple years, far less than the average cycle time of a program development. This has led to perfunctory training and short tours of duty.

Culture Change

As the DOD starts to recognize that R&D decisions cannot be perfectly forecasted through a systems analysis, it puts a premium on talent at the program office level to choose wisely. As contract tasks are partitioned, more of the burden will be on the program manager to make sure the pieces fit together. This means that program management requires many years of training in specific technologies and requirements. Think Gen. Bernard Schriever, Adm. Hyman Rickover, and Gen. George Monahan. The PM position cannot be a short stepping-stone from one place to another.

CSOs and OTAs have empowered the program office not just in contracting, but in the technical-cost-schedule trade-space. Congress has also passed additional authorities delegating down more decisions on requirements, milestone approvals, and funding.

However, even if DOD program managers were given authority consistent with the challenges, problems, and responsibilities they are expected to handle, they would require a high level of technical knowledge. That means a culture change.

Of course this has been tried many times before. The original “full-blown” program office concept from the 1950s had a single manager with a “substantial degree of control over resources [and] a substantial technical staff attached to them.” But that turned out to be only reflected in exceptional programs (e.g., Atlas, Polaris). The ideal was attempted several times and failed in each one of them. Even the 3 year tours for program managers that was first required in 1965 has never been met.

There are no easy answers to complex institutional questions. You can never design organizations without overlaps, competing perspectives, and interdependence. An acquisition process that focuses more on professionalism and less on program lifecycles would do well to say ahead of the technological curve.

Be the first to comment

Leave a Reply