The new Middle Tier of Acquisition instruction (DoDi 5000.80) is a pretty big deal. In this post I’ll explain why, but first, a tiny bit of background.

The document (effective 30 Dec 2019) formally establishes a new acquisition pathway that was first created in section 804 of the FY16 NDAA. So if you’ve heard of “Section 804 programs,” that’s what this is. Also, let’s stop calling these “Section 804 programs” and start calling them MTA’s or Middle Tier, please and thank you.

For context, the Middle Tier pathway is one of six paths in the Adaptive Acquisition Framework. Specifically, it’s the green one. This pathway establishes procedures for rapid prototyping and rapid fielding, with a huge emphasis on RAPID.

Now, I’ll be the first to admit the MTA instruction is not perfect. There are a few things I’d love to see incorporated in a future update. Yes, I literally have a list, but that’s a topic for a future post. Today I’m just going to focus on what I really LIKE about the new MTA instruction, because it’s got some great stuff. After briefly pausing to appreciate how short the document is (15 pages, counting a cover page, glossary, and references), let’s get down to the substance of the thing.

ENTRANCE CRITERIA
From OSDs perspective, the entrance criteria for a non-Major system is literally just the Acquisition Decision Memorandum (ADM). That’s all. It does not mandate a formally approved requirement. No formally approved acquisition strategy. No detailed cost estimate . Just an ADM and you can get things started. As program initation documentation goes, it doesn’t get much more streamlined than that.

Welllll… I should clarify that a bit. See, cost estimates, requirements documents, and acquisition strategies are still good and useful. Program managers should do them, even if you’re leading an MTA rapid prototyping or rapid fielding effort. And yes, the services can each require programs to develop these documents. So no, this new policy is NOT an anything goes, ignorance-based, full-speed-ahead-with-our-eyes-shut sort of thing, nor would we want it to be.

Rather, the MTA instruction lets programs get started without having to pretend they know more than they do about costs, schedules, future performance, or even operational needs (as Dr Roper explains at the 11:12 point in this video). It allows the services to review and make decisions about such things at their level, rather than concentrating the review and approval authority at a higher headquarters. That’s good because sometimes stuff like cost and schedule and performance goals become clear only after the program has begun and we have some actual data to evaluate. MTA’s minimalist approach to initiation documents lets local authorities get programs underway and then develop and update various documents based on actual experience, real numbers, and local conditions.

If we’re interested in cutting red tape AND making decisions based on data (and yes we are), this is a darn good start.

CONSTRAINED TIMELINES
Para 1.2.c says “ MTA programs may not be planned to exceed 5 years.”

Outlawing endless schedules is a crucial step towards improving acquisition outcomes, and fortunately this limitation is not mere policy – it’s actually dictated by statute. I’ve been pushing for acquisition programs to constrain their schedules for a long time now, and I’m not alone. As far back as 1986 the Packard Commission wrote “An unreasonably long acquisition cycle is a central problem… from which most other acquisition problems stem.” Limiting program timelines to less than five years should help prevent some of the problems caused by going too slow .

Such short timelines are possible because MTA programs are either developing prototypes or fielding mature technology, not developing brand new programs from scratch. Neither of those activities should take more than five years.

STREAMLINED PROCESSES
Para 2.56.b says PM’s “will seek appropriate alternatives to any regulatory requirements that increase burden without adding value…”

Frankly, good PM’s have always sought alternatives to policies and regulations that “increase burden without adding value.” Finding and implementing such alternatives is pretty much the job, right? So the new thing is simply that this behavior is now formally part of the policy. That means – and I cannot emphasize this enough – accepting an onerous status quo where the bureaucratic burden exceeds the value IS NOT ALLOWED under this instruction.

Let me say that again – accepting unproductive red tape is a failure to comply with instructions. If a PM is not seeking to improve the value-to-burden ratio of regulations, they are doing it wrong. So that’s pretty awesome, and I hope people will take it to heart.

The other good news here is that PM’s do not have to do this on their own. Para 1.2.c says the OSD (A&S) office will work with decision authorities on MTA’s “to ensure streamlined processes…”

Yes, I realize the cynics will waggle their eyebrows at the idea of senior Pentagon staffers coming in to “help,” but I for one am game to give them a chance and I’ll happily put this paragraph in the Win column. One particularly helpful thing here is the “tailor-in” approach, which means programs do not have to seek special permissions and waivers to take things out of their process. Instead, they only add things into their process that are genuinely valuable.

RAPID DECISIONS
Para 1.2.f says “approval authorities for each capability requirement will be delegated to a level that promotes rapid action.”

As we already saw in the section about entrance criteria, the MTA instruction generally pushes decision-making to a lower level than usual. Here’s where things get a little shaky and cynics get even more snarky, because one might reasonably ask whether the recommended delegations will actually occur on a regular basis and a meaningful scale.

The answer is… I don’t know.

Bear in mind, It’s still early days. This DoDI is less than a month old, after all. At this moment I cannot point to any specific examples of this type of delegation happening just yet, other than the entrance criteria bit (please, educate me in the comments section if you have examples!). However, I can say with confidence that if approval authorities for MTA programs are not delegated in such a way as to promote rapid actions, it will be because someone is disregarding the instruction. That’s not a bad start, so paragraph 1.2.f belongs on my list of things I like about 5000.80 as well.

ADAPTABILITY
Eleven different times the policy says “DoD Components will develop a process…” That’s right, eleven times!! Clearly, this instruction is not a one-size-fits-all, compliance-oriented policy. Instead, it puts the onus on each service component to come up with customized processes depending on their unique situations. All I can say to that is “Yes please, may I have another?”

FINAL THOUGHTS
I’ve been around long enough to know there is always a difference between policy and practice, and yes, this post was primarily about the policy document itself. I completely understand that people may be suspicious of (any!) new policy. And I’m sure there’s plenty of folklore out there among people who haven’t read the DoDI yet. And I am 100% certain that the frozen middle (aka the stalwart defenders of the status quo) will do their chilly best to make sure the implementation of MTA is as glacial as previous acquisition methods.

But it seems to me that any slow-downs or inefficiencies in implementation will be in spite of the MTA instruction, not because of it. If I was a PM reading this, I’d feel like I have a ton of freedom to reduce oversight, burden, doc’s, and red tape. The question is, will programs exercise this freedom and use it well, to rapidly develop prototypes and rapidly field capabilities? Because as I read this policy, that’s precisely what programs are supposed to do.

In Part 2, we’ll look at the MTA pathway in more detail and explore some of the practices it enables.

Disclaimer:  The opinions expressed here are those of the authors only and do not represent the positions of the MITRE Corporation or its sponsors.