… acquisition productivity is at an all time low for command and control and information systems…
Warfare has always been a tactical activity designed to coordinate large groups of people and weaponry to better the opposing forces. Those who win do so using superior warfare operations built upon advanced knowledge of enemy location, tactics, weapons, and plans. Such knowledge is obtained through forward sensors or scouts able to accommodate the commanders needs and communicate obtained information back to the commander in sufficient time to make a difference; i.e. Command and Control (C2) the battlefield.
Modern command and control remains dependent upon best knowledge of the opponents location, tactics, weapons, and plans, now supported by an elaborate array of remote and local sensors tied together with communications used to quickly move and evaluate sensed information. Through computer automation we are able to store, analyze, and display information designed to augment the commanders knowledge, and hence advantage, before and in time of battle.
…The problem is that our enemies have access to the same commercial information technology used within the DoD. If they become agile with this technology, our operating forces could be at a disadvantage despite our Country’s confidence that our high technology weapon our high technology weapon systems will always prevail.
Today’s information technology is dominated by the convergence of:
- Very dense integrated circuit chips;
- Packet switched communication networks; and,
- High speed computation in small physical packages.
The application of this technology has shifted the source for the bulk of command and control system technology from DoD “created” to “adoption” of commercial systems and software packages. Our current and future command and control system capabilities fall short of commanders needs because the complex DoD acquisition system has not adequately adapted to pace commercial technology advances and best practices, despite bureaucratic proclamations to the contrary.
DoD Directive 5000 is the policy “bible” for acquiring material systems and infrastructure for the Department which is designed to provide timely systems by definition.
“3.1. The Defense Acquisition System is the management process by which the Department of Defense provides effective, affordable, and timely systems to the users.”
According to DoDD 5000, five key areas describe the primary policies that govern the Defense acquisition system:
“4.3. The following policies shall govern the Defense Acquisition System:
4.3.1. Flexibility. There is no one best way to structure an acquisition program to accomplish the objective of the Defense Acquisition System. MDAs [milestone decision authority] and PMs [program managers] shall tailor program strategies and oversight, including documentation of program information, acquisition phases, the timing and scope of decision reviews, and decision levels, to fit the particular conditions of that program, consistent with applicable laws and regulations and the time-sensitivity of the capability need.
4.3.2. Responsiveness. Advanced technology shall be integrated into producible systems and deployed in the shortest time practicable. Approved, time-phased capability needs matched with available technology and resources enable evolutionary acquisition strategies. Evolutionary acquisition strategies are the preferred approach to satisfying operational needs. Spiral development is the preferred process for executing such strategies.
4.3.3. Innovation. Throughout the Department of Defense, acquisition professionals shall continuously develop and implement initiatives to streamline and improve the Defense Acquisition System. MDAs and PMs shall examine and, as appropriate, adopt innovative practices (including best commercial practices and electronic business solutions) that reduce cycle time and cost, and encourage teamwork.
4.3.4. Discipline. PMs shall manage programs consistent with statute and the regulatory requirements specified in this Directive and in reference (b). Every PM shall establish program goals for the minimum number of cost, schedule, and performance parameters that describe the program over its life cycle. Approved program baseline parameters shall serve as control objectives. PMs shall identify deviations from approved acquisition program baseline parameters and exit criteria.
4.3.5. Streamlined and Effective Management. Responsibility for the acquisition of systems shall be decentralized to the maximum extent practicable. The MDA shall provide a single individual with sufficient authority to accomplish MDA-approved program objectives for development, production, and sustainment. The MDA shall ensure accountability and maximize credibility in cost, schedule, and performance reporting.”
Given the millions of professionals from both within the DoD and from across the contractor community struggling to provide effective command & control and information systems for the DoD, one has to wonder what has become of the policy to provide “effective, affordable, and timely systems to the users.” Even more intriguing is what has become of the five strategic policies of flexibility, responsiveness, innovation, discipline, and streamlined and effective management. For information based systems characterized as “software intensive,” it is even more curious where the notion of evolution and best commercial practices has gotten lost.
The answer lies in the bureaucratic creep of the thousands of well intentioned military, civil service, and political appointed personnel engaged in the acquisition practice of “program oversight” which is designed to prevent program failures and the misuse of taxpayer revenue. If one could easily count up the number of people engaged in program oversight in software intensive C2 or information system programs relative to the number of people actually 
creating software and supporting system infrastructure, it would be easy to see that we are operating from the upside down triangle approach to resource allocation. That is, we have far more people engaged in program oversight than we have actually writing computer programs and assembling system capability.
If this were only about effectively spending tax payer dollars and delaying command & control capability to the war fighters it would not be as serious. The problem is that our enemies have access to the same commercial information technology used within the DoD. If they become agile with this technology, our operating forces could be at a disadvantage despite our Country’s confidence that our high technology weapon systems will always prevail.
In summary:
- Today’s military warfare commanders and business leaders share a common need
- Both must dynamically access the environment and create an effective response
- Rapidly evolving information technology provides the basis for assessment of the environment and coordinating the organizations response
- Success for both is tightly coupled to the effectiveness of their information systems and the related obtained knowledge
- Those that adapt to the changing environment succeeded over those that fail to adapt
- Our Nations’ risk adverse military acquisition system is strangling military information systems and jeopardizing our over tasked military commanders
Thanks all for the good comments. I plan to take this forward by arguing for a two step process that we can pilot as proof of concept prior to making big policy changes. The first important step is to get general agreement that IT acquisition is different than general weapon system acquisition. This should be easy because everyone knows this in their gut but they don’t know what to do about it. The second part will be about piloting a way forward incrementally so that we can prove value prior to creating the policy changes. More on this in the next post which is about ready.
Marv,
Thanks for stimulating the discussion.
A well founded and articulated strategy, aligned with the executing elements of the organization ( to include resources) are the key to success. Flat organizations requiring that there be a reason for each stop on the trail. Know the mission and how to support it. Have a chain of command that is short, and responsible.
Information age solutions, provided with industrial age methods… doing things the same exact way and expecting the outcome to be different can be defined as…. an acquisition career.
v/r John
John, great point and many of us have made nice careers this way. Issue is that our Country and possibly the globe can no longer afford for careers to pass before we fix the problem:-)
Thanks Marv,
I’m not sure what I read, but I felt it had food for thought. Remember I’m 10 years older than you and the “little grey cells” don’t work like they once did.
Love ya anyway,
Myrna
Great approach Marv! You need to get industry to buy in – we buy ships with networks that are at best 10 years old and when the ship is commissioned they can’t operate because either they are “different” or technology has moved on. The thought process of “buying” networks that are 10 years old when they’re delivered HAS TO CHANGE! Part of that change has to support buying “things” that are current and operable!
We are at the point in time when ships can be built as the carrying platform that they are. NAVSEA avoids this and the shipbuilders argue against it but the lack of flexibility delivered by the current methods will not sustain our needs going forward.
Marv,
Thanks very much for writing and for moving thoughts forward here. This is a huge challenge for all of us. I really appreciate the way you capture the problem and look forward to more dialog here on possible solutions.
Cheers and v/r,
Bob
I don’t think any acquisition reform will be successful unless we get the implementation/execution lined up with objectives and goals. Urgency does not exist in our processes today, therefore like a rubber band we keep going back to where we have started. I am always amazed on how history repeats itself but as human how little we learn or pay attention to it. I can’t get over the fact that during WWII, how we were able to build such a complex weapon systems in such a short period of time ….I call that acquisition reform, why can’t we duplicate that line of thinking again, by that I don’t mean to build more but build smarter.
I also do believe that our thinking and behavior is more geared toward Industrial era than Information era. Information is more accessible, collaboration is much easier, however using information still is challenging. The real reform needs to get us over this phase.
DOCKING POOL!
Every four years we ‘reform the acquisition system’. This is the fourth year.
(and the administration is making all the right preparatory noises).
So, what date will the term ‘acquistion reform’ show up on the front page of a nationally respected paper (or news web page)?
Marv,
All information systems are made up of the same four Greek elements:
I. end systems that attach to the network. These include
A. sensors
B. decision nodes
C. actors
II. the network that connects all the I. parts up.
That’s it. Complexity can be explained by nesting and chaining of the same four elements. Look at your own nervous system as an illustration.
Your point about ‘different types of IT’. The applications live in the end systems — what kind of sensors? What decision support tools we build? But the internetwork is invariant — it hauls bits between the end systems … and is (should be) agnostic about what the bits represent. Therefore, we can modularize the ‘GIG infrastructure’ away from the end systems — it requires some constancy of purpose but doesn’t have a great deal of requirements volatility. By contrast, end systems change all the time, for both supply-side and demand-side reasons.
Herein you have the reason why GIG-BE was a successful program and NMCI was not. GIG-BE carefully separated out all the applications noise (over in NCES, for which the jury has not yet returned) and marched ahead with the upgrade of the terrestrial backbone. 3 years and the program is done. NMCI, on the other hand, is an artisan-based, vertical slice — a good case study in how to contract stovepipes.
Gotta quarrel with ‘common architectures’. First, knock off the ‘s’ — we need AN ARCHITECTURE. The proper definition for this grossly overloaded and poisoned term is ‘modularization model’. You need one model for the end systems that attach to the network and another for the internetwork itself … and that modularization model needs to be applied to all programs.
Right now, DoD 5000.2 requires each PM to cook a half dozen DODAF views. The only one that comes close to being a modularization model is SV1 (and you have to do some major definition disentangling to get there). As long as each PM cooks his own SV1 instead of dealing with a DoD-common one, then we continue to have multiple ‘architectures’ — no interoperability, no large information systems, no modularity.
Marv,
You are right on target. I
Bruce, I think we will need to distinguish between different types of IT. Building services applications upon a GIG network riding SOA services will be different than adding capability to the GIG network infrastructure. We will need a identifiable process that meets your short time lines for each. We also need to spread common architectures that facilitate speedy improvement cycles pushed out across the DoD rather than left up to individual Service or agency components.
The basic problem is the culture of the entire acquisition system. If we ever hope to acheive true Network Centricity with Network aware Applications we are going to have to learn to trust our “peers” and be willing to share some operational “control”. Both of these needs are the antithesis of Military Communications. Secondly, we are going to have to learn to truly “Crawl, Walk, Run” instead of our normal acquisition mindset to make EVERYONE happy and met EVERY requirement. We need reliaable, assured 80% solutions in 12 months not 99% solutions in 6 years plus 24-36 months of slips with 75% cost growth. We need to solve one or two requirements at a time so that we can actually solve the need not just put window dressing on the problem.
Marv,
Great discussions, I remember through acquisition reform era….the government agencies especially DoD tried to become more like the private sectors…actually I remember we changed everything including terminologies, to match industries practices, I think that is all that we have accomplished, the true acquisition reform has not happened yet.
I also believe that in order for either the private or public organizations to succeed in any acquisition is to modularize, development and implementations. Our private companies don’t have all necessary expertise in one place and neither our Government organizations.
Another element missing from today’s acquisition processes is simplicity (I think it should be added as the sixth element). Our enemies are using their imagination and simplicity to meet their objectives. We need to develop processes to make life simpler, and to be measurable against some specific objective.
Roger on the integrated chip. But if you buy the Eli Whitney analogy, that would be looking at the firearms interchangeable parts problem from the aspect of screws with common threads.
Our problem is not to employ chips; it’s to build information systems. And ones with interchangeable parts.
The analogy I use is to look at your own information system — your nervous system. You have sense, decide and act functions which are readily identifiable (and studied in biology class as separate organs … aka modules). And you have the neurons that hang all together.
The smaller version of the problem is to build complete information systems. I see a whole lot of programs and wannabes that only have one part of the information system (e.g. the decision support node). The larger version is two complete information systems that need to be interoperable with each other.
One warning that I take from our ‘acquisition reform’ history is that we’ve sallied forth to change the bureaucracy … without much idea of what the objective is. And we all know the result we get from that. It’s critically important that we have a clear objective: interchangeable parts and cross-program interoperability and information system modularity. And some good idea how to get that. THEN we can tinker with the bureaucracy productively.
Marv,
What you write is correct, but IMHO, not complete:
- the acquisition system is geared to producing platforms (tanks, planes, ships, etc) but not information systems that hang them together. cross-platform interoperability.
- most programs don’t produce any interchangeable parts, at least not in the C2 area. We’ve been building firearms with interchangeable parts since Eli Whitney, but we’re not doing same in the IT business.
- we seem to not learn very effectively from our failures. The IT landscape in DoD is littered with multi $M failures …. yet we never seem to hold autopsies or burials.
- no two programs are modularized the same way. Each program is required to do it’s own modularization … and then we wonder why we don’t have any interoperability.
- the language we use is very sloppy. As an example, pick a handful of DoN CIO and DoD CIO instructions. And a handful of programs (that are also required to produce glossaries) … and compare them. A particularly entertaining one is the n+1 different definitions of ‘waveform’.
- the sloppy language, egregious in itself, is only a symptom of the larger non-modularity problem.
… how many pages do you have here;-)
Rex,
All good points. I think it is because software is deemed to be too complex for policy and management to impact it with modularity requirements. Like guns, the primary enabler of the information age is the integrated circuit chip. Had they not modularized we would be back to 1959. Services Oriented Architecture is trying to move in the right direction but is just the newest technology in a long line of attempts to change this paradigm. But I do actually hold out more promise for SOA. I believe it is closer to the 3rd wave of computing paradigms following main frames, then client-server systems.
“Even more intriguing is what has become of the five strategic policies of flexibility, responsiveness, innovation, discipline, and streamlined and effective management.”
We have been hear before, and have developed and implemented approaches in the past to respond to deliver. After Desert Storm the Navy was required to make drammatic changes to it IT infrastructure, Navy required more SATCOM bandwidth, we needed modern networks (e.g. IT21). We met this challenge through challenging our leadership to allow us by-pass the bureaucrats, and found folks that were willing to manage the risk of implementing change across the Navy. Not just new systems & technology, but new tactics, training and procedures.
It might be well to consider two factors: 1) vulnerability of using software and firmware products that have been developed in environments the U.S. DoD doesn’t have insight into and can’t control (Supply Chain Vulerability), and 2) the importance of thinking about how to use COTS (what warfighting processes will use Service Oriented Architecture (SOA) components, for example, and to what extent will SOA components need to have deteriminstic-deadline performance for some warfighting functions, for another example).
Thanks for starting this blog, Marv, I think it will be very useful!
Marv – Until JFCOM embraces title 10 authority (much like SOCOM has) and starts building joint C2 systrems (with their own funding stream) from the ground up, we will continue to be sub optimized in joint C2.
VR, Dave
As noted we have increased oversight and input from numerous stakeholders that limits the ability of any Agency to effectively meet the tenants of “better, faster, and cheaper.” Unfortunately many of our adversaries do not have the U.S. political structure in place that focuses more on how many jobs and how much money does a project deliver to a particular constituency then how much required and immediate capability does it deliver to the warfighter.
One only has to read the recent articles about the ability or lack thereof by Defense Secretary Robert Gates to effectively review, limit, and in some cases cancel large defense programs with significant cost, schedule, and performance issues.
Chris, great point about the use of COTS which adds the advantage of using rapidly evolving technology but playing on a level field with our adversaries. We do not know how to accommodate this condition and have not spent adequate time trying to sort it out.
In an attempt to mitigate the maximum amount of risk as possible, we have created an acquiisition system rife with oversight layers and required stakeholder inputs. With respect to C2, never before in the history of warfare have our adversaries had access to simimlar technologies. We must maintain a technological edge but to do this we also need speed in acquisition, or we will face fog of war consequences.