Navy Acquisition Can Easily Be Fixed

Driven by peer naval competition from Russia and China, the U.S. Navy has embarked on a transformational Fleet Design vision to enhance U.S. naval warfare. Along with new weapon and sensor technologies, this vision is critically dependent upon out-pacing peer competitors with artificial intelligence and cyberspace control.

Like previous transformation visions, this vision has a high probability of failure under the weight of costly, long drawn-out acquisition timelines, driven by the acquisition “build culture” of Department of Defense (DoD) and Navy.  The rapid pace of commercial IT innovation now demands a “buy before build culture,” as Congress has mandated in law. Because commercial IT is globally available for peer competitors to adopt, the hard reality is that the U.S. can no longer remain ahead while fielding and sustaining 3, 4, or even 5 generation old information technology. Given these real-world challenges, it is imperative that Navy rapidly transform the acquisition system to support Fleet Design.  Four, easy to adopt, acquisition changes would help to deliver the Fleet Design vision in time to make a difference.

1. Speed to Capability – In the world of commercial IT procurement or development projects, acquisition timelines average 70%-80% less than similar DoD program timelines. Tax dollar stewardship is the given justification for these long timelines, but in reality long acquisition timelines needlessly increase taxpayer costs and delay needed warfighter capability.

Long acquisition programs also insure that nobody in the acquisition system is personally responsible for failure because a Program Manager’s (PM) 3-4-year leadership tour only covers a portion of the full requirement-to-IOC (Initial Operational Capability) timeline. To turn this around “speed to capability” should be the primary program metric, with cost, performance, and schedule as secondary metrics . Because time is easy to measure, every person in the acquisition system can be graded on speed to capability. Such a system would not diminish the importance and responsibility of a Title X PM’s acquisition authority, but it would enable the rest of the “acquisition team” (oversight, contracts, legal, budgeting) to be responsible for a measured element of a program’s success or failure.

In the fast moving world of IT intensive systems DoD’s “build culture” is exactly wrong for achieving speed to capability. Even in the *Federal Acquisition Regulation (FAR), the holy book for acquisition contracting, it states that all agencies are obligated to fit requirements into available Commercial Off the Shelf (COTS) products before contracting to build a capability. Congress has also called for greater use of COTS products prior to resorting to building, and backed up that law by making non-FAR Other Transaction Authority (OTA) available, for prototyping COTS and non-development capabilities, for all Military PM’s.

2. Passive Oversight – Currently acquisition oversight is effectuated through PM’s, and their staff’s, satisfying hundreds of staff oversight checkers, responsible for various elements of the acquisition process, including requirements, budgets, contracts, and of course legal. None of these checkers (most of whom have never worked in a program office) can say yes to a program decision, but all of them can say no by challenging, kibitzing, and forcing re-briefs. This translates into hundreds of view graph presentations, papers, and scheduled briefings, given to everyone in the chop-chain above the PM, for every decision.

The Milestone Decision Authority (MDA) approval for each major program milestone is the culmination of these hundreds of briefs, put together by program staff support contractors, and reviewed by chop-chain support contractors. It is a lucrative business for support staff contractors and, through no fault of the support contractors, doubles or triples the cost and time for every program. By taking advantage of publishable program status, program decision briefings and most of the acquisition documentation could be replaced with “Passive Oversight” of program planning and tracking information.

Every program utilizes some form of program management automation and tracking activity such as Microsoft Project. Each software tracking system offers the ability to publish project status, to a website interface, with easy to read graphic dash boards that show project green, yellow, or red status (as well as drill down details). This project status is created by the PM’s staff and/or development contractor entries in the planning and tracking application.

Passive oversight would be accomplished by MDA oversight reviewers continuously monitoring each program’s published status to track program health. Programs would continuously publish status, for all authorized reviewers to access passively through web accessible dashboards. If a project is showing green or yellow, no oversight action would be taken or allowed. If a project is showing red, an appropriate level of oversight action would start, beginning with a phone meeting to better understand the situation.

For green and yellow status programs, “letter” MDA approvals could be processed to eliminate the lengthy MDA decision cycle. ACAT MDA authority would continue as it currently exits and could be delegated downward based on successful passive oversight results. The freed up oversight staff time, and fewer meetings, could be used to reduce the size of oversight staffs and support contractors at all levels, thereby saving resources. PEOs and PMs would be fully accountable for any purposely misrepresented program status and punished accordingly.

3. OTA Prototype to Production – The most useful Congressional change to contracting law over my career is the current extension of OTA prototyping authorization to all DoD programs. Not only does the proper use of OTA prototyping help a program quickly discover COTS and non-traditional defense contractor products, it also helps quickly eliminate ineffective solutions, thereby, using less program time and resources.

Commercial companies use proof of concept prototypes (POC) to validate COTS products, new system ideas, and technology maturity, before full adoption into a product line. Using a series of prototypes to validate POC capabilities enables the technical crawl, walk, run needed to support speed to capability.

Low cost OTA prototypes can be used during the material solution analysis period to help inform Milestone A, followed by more extensive prototypes that inform Milestone B. Following Milestone B, OTAs can produce early limited production proof of concept prototypes to inform Milestone C and full rate FAR contracting. OTA Prototyping to Production” helps inform strong technical understanding early in the life of a program or modernization activity, while also helping to inform program planning and reporting to support passive oversight.

DoD OTA consortia, now processing billions of dollars in OTA transactions each year, are helping to unburden FAR contract staffs, while shortening contracting time for early program phases. Time is money and long drawn out and overly protested contract activity is a large expense in the lifecycle of a program.

4. Strong Technical Leadership – Excessive acquisition oversight and bureaucratic processes have driven many strong technical people away from a Navy acquisition career path. Couple that with the DoD culture that believes any Defense Acquisition University (DAU) qualified person can manage any program, and the Navy has a perfect storm in the face of peer-competitor National Security challenges. Simultaneously, systems have become so complex and integrated that writing a FAR build specification contract and delivering a successful cost, schedule, performance program is highly risky.

To know that acquisition is on the wrong path, one must only ask how the Navy invented and delivered highly technical nuclear submarines, submarine launched ballistic missiles, AEGIS ships, and Tomahawk missiles, all within cost, performance, and short timeline schedules; something that isn’t repeated today despite the extra DAU training, information productivity tools, automated design, and automated tracking systems.

Since those early Navy acquisition successes, the workforce has migrated away from deep technical understanding of the systems being built. At the same time, most PMs use their technical directors as trouble shooters and technical commenters, rather than direct program line authority. Because deep technical understanding is not a requirement for assignment as PM or Assistant PM, programs are often managed with little understanding of technical issues that sidetrack effective program delivery.

Independent of the program requirements, budgeting, and contracting activities, it is almost always technical challenges and solutions that define acquisition program success or failure. By putting a “strong technical manager” directly underneath a PM, to manage all things technical, the PM is freed up to focus on the constant challenges of budgeting, contracting, and oversight, while also making final decisions on technical issues.

A review of the history of the AEGIS weapon and shipbuilding program, or the Strategic Systems Program, shows that both organizations used a strong technical manager directly in line under the PM. These were the people often promoted to the PM position, following that senior technical position, thereby insuring that the PM also had deep technical knowledge of the program, and likewise had usually been with a single program for a large portion of their career.

By implementing “Strong Technical Leadership,” in conjunction with the recommended changes for program “Speed to Capability,” the workforce will migrate toward stronger technical understanding by rewarding program technical experience and expertise. This also facilitates trading support contractor briefings and acquisition documents for engineering planning, tracking, and automated documentation tools, while incentivizing a workforce that leverages these automation aids.

Improving the DoD acquisition processes has been a constant theme for the past twenty years. To date, all of the well intentioned policy changes have not solved the problem of long expensive acquisition programs that fail to deliver as planned. If anything it has gotten worse. These four ideas:

  1. Speed to Capability
  2. Passive Oversight
  3. OTA Prototype to Production
  4. Strong Technical Leadership

… require no significant DoD 5000 acquisition policy changes and no Congressional law changes. By implementing these changes Navy would begin to adopt a buy before build culture and remain closer to the leading edge of commercial IT capability. Adopting these relatively easy changes would give the Fleet Design vision a fighting chance.

 

* FAR Subpart 12.101 Policy.

“Agencies shall—

(a) Conduct market research to determine whether commercial items or non-developmental items are available that could meet the agency’s requirements;

(b) Acquire commercial items or non-developmental items when they are available to meet the needs of the agency; and

(c) Require prime contractors and subcontractors at all tiers to incorporate, to the maximum extent practicable, commercial items or non-developmental items as components of items supplied to the agency.”

This entry was posted in Cybersecurity, DoD IT Acquisition, Global Perspectives, Leadership, Technology Evolution. Bookmark the permalink.

17 Responses to Navy Acquisition Can Easily Be Fixed

  1. Nice work Marv. We were recently revisiting and discussing AEGIS, leaving me wondering if such a system would have even been possible in recent years.

    • Marv Langston says:

      Mark, given that our Navy forefathers build a nuclear powered sub five years, ballistic missiles to fire from them in about the same short time, I am certain it couldn’t be done in our current structure…

  2. Steve Lines says:

    I believe the root of the problem lies in the statement “most PMs use their technical directors as trouble shooters and technical commenters, rather than direct program line authority. Because deep technical understanding is not a requirement for assignment as PM or Assistant PM, programs are often managed with little understanding of technical issues that sidetrack effective program delivery.”
    These PMs don’t understand the technical aspects of the project, but they certainly do understand the PM process. The focus is then on the process, not the product.

    • Marv Langston says:

      Steve, exactly correct, we have the pendulum swung to far to the process side leaving the technical engineering and prototype validation out in the cold…

  3. Rob says:

    Sounds pretty straight forward Marv!

  4. Bill Bowes says:

    Marv, very well said and hard to disagree with any of your recommendations. COTS can always help in speed to capability, but only if the DOD fully understands the COTS system to ensure it does not contain hidden traps. The only addition I would make is adding a willingness to fail. In Tomahawk we had numerous failures, but the requirement was so strong that the culture accepted the failures until success was achieved.

    • Marv Langston says:

      Admiral, great point on failure acceptance. I should have make that more clear. The great thing about quick setup prototypes is the early failures that can help shape the final course. Of course, Tomahawk is much more complicated than an IT driven system but OTA prototype to production can still be applied to those challenges.

      • Marv,

        I think it’s probably worth drilling down a bit further specific to AI systems. Our knowledge systems shop was a pioneer in lean venturing and fast fail in mid-1990s. It was appropriate at the time relative to the Internet and www as few things had been attempted, the technology and medium wasn’t designed for what most were attempting, resources were thin and organic modeling still worked.

        While we maintained the same culture over time in part in DNA, the systems challenge and physical needs led me towards a more formal R&D mindset. For brevity essentially the optimal method in AI systems is to still employ the experimental algorithmics, but do so on top of a well designed system. Otherwise what we see even in high performance corporations is very slow redundancy. Too slow and redundant in most cases for this environment.

        This begins to touch on why I think the DoD needs flexibility between complete COTS systems and traditional new program RFPs. This becomes more obvious in looking at behavior in the top few AI systems companies, particularly in their M&A efforts.

        For example few if any turnkey AI systems exist today that are already approved by regulators in commercial settings, other than components in a network like chatbots. Autonomous cars provides a decent example, but only one. Since it would be foolhardy for the DoD to risk waiting until mature, they really need the flexibility to deal with constraints–physical, economic, regulatory, competitor trajectory, etc.

        While we are now seeing signs of movement in DoD AI center proposed, etc., and many internal projects, I’ve been driving home the importance of this issue even if a bit difficult to get arms around if not immersed in it. Good progress, though still mainly at the service branch level in science and engineering, only partially reflected in larger recent RFPs and awards.

  5. Marv, I wonder if changes in the Navy’s Engineering Duty Officer program has had some influence here? I and I’m sure you remember the EDs we worked with including yourself, Admiral Rickover, Admiral Meyer, Admiral Gauss, etc. And there are some less than successful programs such as SIAP that may be exceptions, but here the “retired ED” was only the TD. Also, when I came in NAVSEA I was one of 26 that came from a Shipyard Co-Op program. Most of those engineers stayed for the full 30 years. I don’t think we have that type of program anymore and I’m not sure of the talent we are attracting lately. I have seen a lot of Management Analyst classifications filling what should be Engineering billets.

    Then, of course, DoD has been in kind of an acquisition and technical refresh slump in the recent past, even back to the end of the cold war in the 90’s.

    I also wonder about the recent legislation concerning Modular Open Systems Architecture (MOSA), and Mission Engineering (ME). From what I have seen through the NDIA it looks promising. Another initiative called “Digital Engineering” is also being pursued in OSD which emphasizes Computer Models rather than paper in acquisition and program reviews looks promising but very challenging .

    Complex problem, but I think your thoughts are a good start, however passive oversight has me a little worried given how much politics I have seen in past and current project reporting.

  6. Palmer Sims says:

    Marv
    Yes! Thx
    The way forward will be to get things done soonest.
    Leaders with game who empower people and process available will enable the new capabilities needed to accomplish the fight.
    OTA…Forward Fast or Fail Fast.. Both goodness..

  7. Rex Buddenberg says:

    Marv,

    IT systems never come from one source nor from one PM (independent of the make/buy issue). What’s missing is a modularization model. The modularization model at the communications level is simple: all comms should come as routable networks and the modularization boundary is at the router. Whatever happens within the module boundary is the PM’s concern; whatever is on the other side of the router is (blessedly) out of scope.
    The internet has changed things rather profoundly: one infrastructure and 1001 applications. We can live with 505 of the 1001 applications and certainly need to build a few specific to certain needs. But we need to get the infrastructure (terrestrial-WANs, radio-WANs, LANs) right — the foundation on which everything else in IT systems rests. Litmus test: are we building intra-battle group comms as routable networks?

    Modularity within applications. Almost all apps these days will be susceptible to a mix of COTS and custom software. We historically haven’t been very good at this. If the system sniffs of ‘operations’ or ‘tactical’, then it tends to be all-custom even though some parts (like messaging) have little reason to be.
    Modularity and life cycle maintainability are two sides of the same coin. You’ve been in this business long enough to remember the mantra ‘never buy anything from Microsoft until Version 3’. It’s unlikely that we’ll get the requirements right the first time as the new technology spurs imaginative thinking … and new requirements. Even if the requirements process and program genesis were perfect, we’d still have to update things over life cycles. Is the system modular enough to do that? Navy’s got lots of grey box bad examples to prove the hypothesis.

    Adapting from COTS. Commercial applications (look at your cellphone for example) abound and some of them are good. But they routinely lack three features that we need (this applies equally well to emergency services and military):
    – end-to-end security. In ISO Reference Model terms, layer 6/7 security. This security provides authenticity and confidentiality of content and implementation is independent of the comms infrastructure.
    – manageability. End systems and applications need Simple Network Management Protocol agents. Foremost among a myriad of needs is fault management. This manageability meets the third principle of high availability engineering (prompt detection of faults as they occur).
    – multicast. Most data generated by military nodes has to go more than one place. Multicast is defined as delivery to >1 destination for the price of a single transit over the comms system. In anything more than the nearest stem, conservation of spectrum (and radio-WAN capacity) will always be a constraint. Multicast is about the only rabbit remaining in the hat (and something we got right a few times: fleet broadcast and Link 11 are two examples).

  8. Eric Westreich says:

    Always right on Marv.

    When it comes to oversight, there is much less pressure on managers when they manage actions instead of outcomes (e.g. did we follow lean six sigma, or did we test prototypes from three different vendors). But getting the outcomes right, and linking them to metrics may be a critical component to implementing your great thoughts.

    • Marv Langston says:

      Good points Eric… When are we going to stop measuring inputs/process and start measuring outputs!!

  9. Jim Churchill says:

    Marv, Fixing defense acquisition requires addressing the drivers that cause program cost, requirements and schedule dilation. Two of the major drivers are requirements creep and diffusion of authority. Requirements creep occurs in both legitimate and insidious ways. Cybersecurity measures could be placed in the legitimate category, while “requirements” for added features, data sets, functionality, etc are often imposed well below, or at least outside, the visibility of the PM’s reporting chain.

    Your suggestion for passive oversight will partially address the diffusion of authority but not entirely. Government is not built for speed or even efficiency; it is built for fairness and legitimacy. Ensuring the latter two seems to come at the expense of the former. Is it necessary that this be so? Could fairness and legitimacy be obtained more efficiently?

    It would be very revealing to compare the project timelines, including all decision making and stakeholder management, between a DoD acquisition program and a similarly scoped infrastructure modernization project in the private sector. Comparing GE’s recent move to digital processes to Navy’s efforts to modernize, say, maintenance and supply, could be a very good graduate school thesis – and revealing.

  10. Gary Wang says:

    Marv,

    A couple of comments

    1. When one examines the IT dollars for federal, a majority of the projects do not fall under a POR and traditional DOD 5000.

    2. The lexicon in your article still references DOD phraseology. for example “speed to capability” should be replaced with “speed to market” . too many folks get wrapped up in requirements vs capabilties documents . This discussion been an albatross around our necks for many years.

    3. The crux of the issue has not been one of oversight, but one of having contracting offficers with the technical breath and understanding to write good performance work statements for IT services and or commodities. We particularly see poorly written contracts as we migrate to the cloud.

    4, Too many folks are drinking the OTA kool aid, there are other contracting mechanisms such as BAA’s and BPA’s

    5. We also need to consider growing an esprit de corp of PM’s that are hired guns to execute programs. Just taking the training does not qualify one as a good PM. There needs to be a track record, with a ratings system graded by industry and from within and recognizing such with a good compensation package.

  11. Chuck Alcon says:

    Marv- Sorry for the delay in responding; I have read and studied the blog and the many “Right on Time” comments and responses. When my wife worked for Seagate we would get the quarterly company newsletter. I distinctly recall one newsletter when the company proudly announced 13 new products were introduced that quarter; I thought surely they jest, we can’t even complete a project PDR and CDR in one quarter. I believe the Navy can streamline the procurement/development process only if it understands, completely, the private industry process for complex developments and then agrees to temporarily waive or suspend selected FAR requirements, only for that specific development. Fair, probably not, competitive, yes if announced up front, effective, yes if a repetitive approach is implemented across the board; OR, give industry your high level performance specs and release one company to provide the solution.

    Chuck

Leave a Reply

Your email address will not be published. Required fields are marked *