Printer Friendly

Rapid deployment capability in action: the Automatic Identification System.

Since 9/11, the Automatic Identification System (AIS) has received significant attention within the Departments of the Navy, Defense, and Homeland Security. Numerous friends and allies, systems commands, commercial shipping firms, and others are fielding AIS initiatives at varying levels of maturity. From a program management perspective, this commercial off-the-shelf capability hits the grand slam of acquisition: it is inexpensive; it is innovative; it is simple to understand; and most important, it provides a useful capability to a variety of customers at all levels of warfare.

AIS is fielded in the Navy today primarily via the Rapid Deployment Capability process. The RDC process has received significant attention lately, because it seems to offer a means for program managers to surmount chronic challenges embedded in the Joint Capabilities Integration & Development System process: untenably long delays between functional needs analysis and deployment; costs resulting from JCIDS-related events and deliverables; and acquisition processes often more focused on risk aversion than risk management.

As the saying goes, "You can have it good, you can have it cheap, or you can have it fast--any two of the three."

In that light, the following provides our thoughts, high-fives, wishes for do-overs, and lessons learned from our experiences working rapid deployment in a life-cycle management world. Please note that we are cheap and we are fast; we will leave the reader to determine if we're good.

The AIS Initiative

AIS, a commercial VHF Line-Of-Site transceiver, connects vessels and shore sites that purchase the capability. This virtual network shares hull, location, deployment, and other information. AIS has been around for years but began to gain traction in the aftermath of 9/11 as Defense and Homeland Security leaders reconsidered the implications of the post-Cold War world. In 2002, several events significantly raised awareness of AIS. The International Maritime Organization established guidance on the mandatory carriage of AIS transceivers aboard merchant shipping of a certain tonnage. The U.S. Navy provided implementation guidance for AIS for the first time. Soon after, a variety of U.S. Navy platforms and organizations, largely in U.S. Central Command, began local AIS installations. The fleet provided extremely positive feedback on these early initiatives.


In his fiscal year 2006 Global War On Terror Implementation Guidance Memorandum (July 2005), the chief of naval operations (CNO) directed OPNAV [Operational Navy] N6/N7 Warfare Requirements and Programs, in coordination with Fleet Forces Command and OPNAV N8 Warfare Assessments, to develop a plan to procure and install AIS systems for all surface ships by the end of fiscal 2006. OPNAV tasked our office within PEO C41 and Space to pull together the specifics of this plan.

As program executive office action officers started to clarify and define the operational, budgetary, and acquisition-related requirements for fielding, we began to realize that unlike our previous experiences in acquisition, getting appropriate operational and budgetary oversight and execution approvals was proving relatively easy. For example, an AIS concept of operations drafted by the Third Fleet staff and facilitated by Naval Warfare Development Command quickly evolved from first draft to Commander Fleet Forces Command approval in less than a year. Similarly, in conjunction with OPNAV staff, we generated budget estimates, identified funding streams, and received congressional authorization to spend resources in less than six months.

We were greatly aided by the simple fact that AIS is easy to understand from an operational and systems engineering perspective, and the costs associated with fielding were extremely low. The low cost of AIS was especially significant when compared to the overall value-added of this unique datastream for commanders at all levels of warfare. Additionally, senior Navy leadership's need for new, relevant capabilities in support of maritime domain awareness and the global war on terror provided great momentum for our efforts.

SECNAVINST 5000.2C, Section 2.8.1 [Secretary of the Navy Instruction 5000.2C, "Implementation and Operation of the Defense Acquisition System and the Joint Capabilities Integration and Development System," Section 2.8.1] explicitly relates RDC to "the ability to react immediately to a newly discovered enemy threat(s) or potential enemy threat(s) or to respond to significant and urgent safety situations through special, tailored procedures." In our submission, we used safety and enemy threat language in our justification. Specifically, we discussed AIS in support of safety at sea, maritime domain awareness, and homeland defense. While some may joke that an RDC designation acts as a "get-out-of-jail-free card," in actuality RDC is more of an "acquisition permission slip" that assists the RDC manager in expediting decisions within the requirements, planning, programming, budgeting, and execution (PPBE), and acquisition management communities.

Four pages in all, our RDC submission included a brief description of the operational requirement and urgency of the threat; the range of available AIS products; quantities required; identification of funding; deployment date; logistics and maintenance support requirements; plans for testing; and manpower, personnel, and training requirements for fielding. The assistant secretary of the Navy for research, development and acquisition approved the RDC plan in January 2006.

In a typical acquisition cycle, funding for research, development, test, and evaluation (RDTE) acts as the primary resource during the first years of a program. As a program evolves into its operations and support phase, procurement and maintenance funding grow. Meanwhile, a fundamental risk within the acquisition community is requirements creep. Based on our experience with AIS, an addendum to this risk is as follows: a fundamental risk within the rapid deployment capability process is rapid requirements creep within a given execution year in which scarce resources were pulled together at the eleventh hour for the RDC in the first place.

In the case of AIS, we received procurement dollars after approval of our RDC. This funding allowed for commercial off-the-shelf purchases and installation but did not support any development in support of additional fleet requirements to our initial baseline capability. To mitigate this lack of funds to handle emergent requirements, we requested RDTE funding through the Office of Naval Research's Rapid Technical Transition (RTT) process, to begin integrating AIS information into the Global Command and Control System (GCCS) family of systems. Simultaneously, the calls for integrating AIS into the common operational picture grew louder as the fleet's AIS concept of operations matured. We used this RTT-provided RDTE to deliver a significantly greater capability than originally envisioned in the CNO's guidance, based on rapid creep of operational requirements. Essentially, we provided a second increment of the AIS capability that fed tracks into GCCS-M [Maritime] within three months of receipt of the RDTE funding. Without this additional RDTE funding, we believe our RDC efforts would have been considered a colossal failure by Navy operational commanders.

Fielding the AIS Capability to the Fleet

We considered our integrated AIS capability, developed using the RTT RDTE based on rapid requirements creep, to be an 80 percent solution for the fleet. But by getting our AIS capability quickly into the hands of operators, we received significant operational feedback that allowed us to make measurable and attainable improvements to our baseline in weeks, not years. The flip side of this effort, of course, was that configuration management became a tremendous pain. We believe our configuration management headache, however, has been more than offset by the benefit of quickly deploying this technology to the warfighter. The admirals and commodores who led our afloat strike groups became our strongest and most effective advocates.

As we are writing this article, the initial AIS RDC capability has been fielded on about 60 U.S. Navy unit-level ships and the integrated AIS capability on six U.S. Navy force-level ships. The ongoing fleet AIS lessons learned will go a long way toward defining capabilities as AIS transitions from RDC to Program of Record. We hope to achieve a positive Milestone C decision during the first half of fiscal year 2008.


In certain cases, the RDC process provides an incredible opportunity within the Navy and DoD to get new capabilities fielded quickly. Whenever these new capabilities provide "the ability to react immediately to a newly discovered enemy threat ... or to respond to significant and urgent safety situations through special, tailored procedures," we recommend program managers invest the time and energy to consider this acquisition strategy. While an RDC designation is not a get-out-of-jail-free card, it significantly streamlines dialogue and decision making within the requirements, PPBE, and acquisition management communities.

The authors welcome comments and questions and can be contacted at and

After a distinguished career in Naval Intelligence, Poor has been the deputy assistant program manager for global war on terror intelligence, surveillance and reconnaissance at PEO C41 since 2005. Case has 28 years of combined military and government service and has been the PMW180 acquisition manager at PEO C41 for the last two years.

RELATED ARTICLE: Do you develop and implement PBL strategies?

Then you really need to know about DAU's PBL Toolkit.

The Performance-Based Logistics Toolkit is a unique Web-based resource, hosted by the Defense Acquisition University, that provides PMs and logistics managers a step-by-step process and readily available resources to support them in designing and implementing PBL strategies.


The user-friendly online PBL Toolkit is aligned with current DoD policy and is available 24/7 to provide--

* A clear definition and explanation of each PBL design, development, and implementation process step

* The expected output of each process step

* Access to relevant references, tools, policy/guidance, learning materials, templates, and examples to support each step of the process.

The PBL Toolkit is an interactive tool that allows you to--

* Contribute knowledge objects

* Initiate and participate in discussion threads

* Ask questions and obtain help

* Network with members of the AT & L community and learn from their experiences.

To guide you through the development, implementation, and management of performance-based logistics strategies--count on the PBL Toolkit from DAU.

You'll find it at

RELATED ARTICLE: Top Ten Lessons Learned

Flag-level Support. The explicit CNO Guidance from July 2005 acted as the key enabler for our effort. Without senior leadership urgency of need, getting approval to move forward would have been unlikely. Once the RDC was approved, senior leadership provided critical hands-on support in expediting our tasks required to field.

Stakeholder Coordination. Immediately following the CNO's July 2005 Guidance, we convened regular telephone conferences with action officers from OPNAV, type commanders, fleet units, and the acquisition and technical communities. The telephone conferences provided a convenient forum to get stakeholders on the same page early in the process. This coordination was critical in maintaining the rapid pace needed to meet fleet expectations and manage the rapid requirements creep inherent in an RDC.

Rapid Requirements Creep. Having operational requirements as clearly defined as possible should help reduce rapid requirements creep. But in an RDC effort, the time required to flesh out and prioritize requirements with the operational community is not available. Essentially, our engineers and Navy operators learned about AIS at the same time. In hindsight, we should have more aggressively pulled lessons learned from early fleet do-it-yourself installations in Central Command's area of operations. We tried to be sensitive to their high operational tempo within Operations Enduring Freedom and Iraqi Freedom, but we erred on the side of caution. From an acquisition perspective, the RDC request itself was the most critical document. It must balance schedule and performance information while allowing some leeway for expansion of the initial requirement. This leeway allows managers to incorporate operator input normally collected during the concept refinement, technology development, and system development and demonstration phases of a typical JCIDS program of record. In any case, our biggest headache throughout the RDC has been managing fleet expectations under severe time and budget constraints. Without our RDTE plus-up, our best efforts would probably still have been considered a failure by our customers.

Road Shows. One of the ways we could have better managed fleet expectations would have been to visit key senior Navy leadership and action officers and give a road show on our RDC. Without the road shows, our action officers were nearly driven into the ground by the volume of questions and requests for briefings.

Funding Streams. We had to be innovative to garner funding. By definition, an RDC system is not fielded or funded via the typical PPBE process. Therefore, congressional supplementals, global war on terror supplementals, research laboratories' developmental resources, and below-threshold reprogramming dollars make the difference between success and failure.

The 80 Percent Solution. Our mantra this year was, "If we field we win." When we began to field, our customers became our strongest advocates--and our most severe critics. The lessons learned and momentum we received from these early installations significantly improved the initial 80 percent solution we provided. In the same light, if we had waited to complete more of the systems engineering typically associated with an acquisition program, we would not have been rapid--and so not an RDC.

Operational Test Community. We engaged with the operational test community soon after receiving initial approval from the CNO on our plan. SECNAVINST 5000.2C states that under an RDC the program sponsor may obtain an operational test assessment of operational effectiveness and suitability. In actuality, our Milestone Decision Authority required appropriate levels of developmental and operational testing prior to giving his approval for procurement and fielding. Bringing Commander Operational Test and Evaluation Force test personnel into our plans early added to our workload up front in the RDC process but became a great facilitator as we coordinated our quick reaction (operational) assessment.

Proof of Concept. Even before we began our RDC process, we worked with the fleet to demonstrate an extremely early prototype in a venue consistent with the required application. We received authorization to conduct a Proof of Concept integrated AIS installation on USS Theodore Roosevelt through the hard work of ship's company and staff personnel. This "warts-and-all" temporary installation provided enough information on the military utility of our capability to key stakeholders to garner support quickly for our RDC efforts.

Teaming. In hindsight, we should have spent more time teaming with other systems commands and programs. In an effort to maintain our momentum for the RDC, we centralized the early technical decisions within our office and did not delegate many of the fielding actions until nearly a year after we began. Teaming with providers of similar products and services should greatly reduce an RDC's risk.

Socializing the RDC Process. Finally, we cannot stress enough that socializing the RDC process itself is critical to success. Within our program office, command, and the entire Navy, there was virtually no corporate knowledge on the RDC process. In hindsight, as we socialized our capabilities with our stakeholders, we should have made a more focused effort to socialize the means by which we provided our capability: the RDC.
COPYRIGHT 2006 Defense Acquisition University Press
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2006, Gale Group. All rights reserved. Gale Group is a Thomson Corporation Company.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:LESSONS LEARNED
Author:Case, Randy
Publication:Defense AT & L
Date:Nov 1, 2006
Previous Article:Generation Y in the workplace.
Next Article:It's all in the talent: what DoD can learn from Hollywood.

Related Articles
Talisma Introduces SFA Suite.
After-action reviews: MTMC Intranet offers operational insights.
DHS office to focus on science and technology.
SDDC helps 25th Infantry Division move to two conflicts in two months.
The AT & L performance learning model.
Formative evaluation of a CSCLIP lesson.
Annual summit on Unique Identification.
The U.K.'s defense logistics transformation program: learning the lessons from Iraq.
When the warfighter needs it now.

Terms of use | Privacy policy | Copyright © 2022 Farlex, Inc. | Feedback | For webmasters |