General Hyten gives a metric for measuring acquisition success

There’s actually a pretty easy metric if you want to evaluate whether you’ve been successful for not. All you have to do is go out to any program manager of a major acquisition program and take their calendar in the last three months, and add up the number of days they’ve been in Washington DC or the Pentagon, and if the number of days they’ve been at the contractor plant exceeds the number of days they’ve been in Washington DC you’ll have changed the risk equation. Because risk has to be pushed down if you’re going to go fast. That means [the manager] has to have the authority to move quickly.

That was General John Hyten, Vice Chairman of the JCS, speaking at CSIS. Of course that metric would be problematic in reality. What about program manager tenure? Micro-managing the contractor? Unintended consequences, like a rise in documentation in lieu of meetings, or teleconferencing?

But I think Hyten hits onto something real with the metric example. The PM should be empowered to help guide necessarily incomplete contracts, for if the contract specified the exact outcome correctly, then such empowerment isn’t necessary. The PM turns into an administrator and caretaker of standing orders baked into the bureaucratic plan.

Here are some great quotes from Hyten on the need to empower PMs:

(1) We have built processes over the years that by design are not built for speed. By design they’re built to remove risk. If you have a process that is designed to remove risk, it is very deliberate, very structured, very bureaucratic, step after step after step. You remove authorities from the field and move them into the Pentagon so you’re sure you don’t take risk. And that means we go slow.

 

(2) The [Joint Requirements Oversight Council] is an industrial age model. Not an information age model. We have to change it. That will translate into the acquisition business. The thing we have to do in the acquisition business is real simple. We have to take risk and delegate responsibilities to people who are executing programs. We don’t train people how to buy things anymore. We train people to get programs through the Pentagon and Congress.

 

(3) If you want to see a military person go fast. All you have to do is give them the authority and responsibility. And if they fail, then you have to fire them and find somebody else. But isn’t that the way America works? Why does that sound so strange?

 

(4) If the dictator of North Korea has learned how to accept failure, why can’t the United States accept failure? We need to understand what failure is and learn from the mistakes we’ve made, move quickly from those mistakes.

The joy in taking responsibility of a program’s success requires (1) an intimate understanding of the technology and military requirements, and (2) the promise to see it through for probably 5 years or longer.

I would note that the current system doesn’t really drive down “risk.” The only real way to drive down technological risk is the method of trial-and-error, where real outcomes are learned. What does not drive down risk is asking the input of every functional in the Department, adding reporting layers, gathering approvals, and so forth. Planning backwards and forwards can drive down risk in a “tame” environment. It can never resolve uncertainties that are at the heart of technological progress. That requires empirical evidence not found in the bureaucracy or management tools.

Here, Hyten verifies the fact that the DOD requirements process focuses on particular states of technology and specifications rather than broad capability needs and attributes:

When you look at force design and development, there has to be a joint warfighting capabilities we need, but that is not systems. That is capabilities and attributes. What we’ve tried to do in the past is take our systems, and build it into a joint concept. That will always fail… In many cases what you read the requirements coming out of the JROC is system design specific…

The current process for building software is horrible. So we’re going to change that. I’ve talked to Secretary Lord, she’s going to do the same thing on the acquisition side, but she needs help on the requirements side. I don’t know yet what to call it yet. My working term is ‘process requirements.’ Because here is how we write requirements today. We write requirements for a product. We say, ‘build that. I want it delivered in ten years. I want it perfectly cybersecure. I want it everything, delivered in ten years.’ That’s what our process is. So it you do that, you say here’s the threat at the beginning, deliver me that capability ten years from now, that capability is to defeat the threat that threat ten years ago. An in cyber, tomorrow you’re already out of date.

What he’s talking about is moving away from intricate structures of documentation and approval, all based on analyses of programs and outputs, and focusing those before-the-fact control on processes, or perhaps inputs like training and organizations.

That would be a shock to the rationalists of the 1950s and 1960s which designed the program budget and systems analyses processes upon which our modern acquisition system is founded (i.e., the Planning-Programming-Budgeting-Execution, or PPBE, process). But a move to more traditional methods of planning and control — based on inputs, and then evaluating outputs with some knowledge of their consequence and holding managers responsible — that is the American way of administering public projects.

Of course it all relates to what he said earlier, that PMs with deep experience and game-winning judgments should be given authority and responsibility to make decisions under uncertain, understanding failure is a precondition for success.