Post Comand

8/4/2019 Post Comand

http://slidepdf.com/reader/full/post-comand 1/24

3 | A Publ cat on of the Defen e Acqu t on Un ver ty www.dau.m l

Keywords:Command Post of the Future (CPOF),

Battle Command, Science and Technology (S&T)Initiative, Risk Management, Tailored Process, Army Battle Command System (ABCS)

image designed by Harambee Dennis »

COMMAND POST OF THEFUTURE: SUCCESSFULTRANSITION OFA SCIENCE AND

TECHNOLOGY INITIATIVETO A PROGRAM OFRECORD

BG Harry Greene, USA, Larry Stotts,

Ryan Paterson, and Janet GreenbergThis article outlines how the Command Post o the Future(CPOF) program was success ully transitioned rom theDe ense Advanced Research Projects Agency (DARPA)to the U.S. Army. Use o a tailored DoD 5000 acquisitionstrategy allowed the new CPOF technology to be eldedas a technology insertion into the Army Battle CommandSystem (ABCS). Key to the success o this transition includedthe use o risk management techniques to drive the program

orward, use o early and sustained eedback rom the usercommunity, maintaining transition unding stability, andhonest and open communication between all stakeholders.The DoD 5000 acquisition strategy was tailored to x therisks over time, rather than trying to develop the per ectproduct in one delivery.






backgr und

In 1999, Under Secretary o De ense or Acquisition, Technology, andLogistics Jacques Gansler tasked [then] Director, De ense Research andEngineering (DDR&E) Hans Mark to nd out how many Service Scienceand Technology (S&T) programs make it rom research into developmentand acquisition. This tasking was part o the under secretary’s e ort todevelop a plan or Acquisition Re orm. A ter conducting a comprehensiveworkshop, the participants determined that or all the Services only about25 percent o all S&T programs transitioned. One o the major issues was

technical maturity o the S&T results, which o ten caused cost growthsand schedule slips while the program manager tried to x problems duringthe development cycle. The result was a complete rewrite o the 5000series (Department o De ense, 2000), as illustrated in Figure 1, whichclearly shows that S&T products can be inserted throughout the entireprocess. The intent was to get more products transitioning rom the S&Tcommunity to acquisition programs.

As part o this new process, the rewrite team recognized that technicalmaturity must be addressed up ront. Usually, technology was nottested thoroughly; rather, it was o ten trans erred to acquisition withoutknowledge o how well the technology worked or what improvements wereneeded to build a reliable product. In response, the minimum entrancerequirement or any S&T products at Milestone (MS) B was a Technology

Readiness Level (TRL) 6. The TRL 6 entrance criterion or Milestone Bwas chosen because it provided the government with con dence that theproposed technology would not require multiple test cycles. This requiressome developmental-like testing prior to MS B, as well as some LimitedUser Tests (LUTs) to minimize risk.

This article outlines how the CPOF program was initiated, executed,and transitioned. By documenting our experiences, we hope to provide

BLOCK 2

BLOCK 3

Technology Opportunities & User Needs

Relationship to Requirements Process

MNS ORD

Single Step orEvolution to

Full Capabilty

IOT&E FRP Deci sion Rev iew

All validated byRequirements

Authority

Pre-SystemsAcquisition

Systems Acquisition(Engineering and Manufacturing Development,

Demonstration, LRIP & Production)

Sustainment

Concept & Technology

Development

System Development& Demonstration

Production & Deployment Operations & Support

IOC FOC

Process entry at Milestones A, B, or C (or within phases)“Entrance criteria” met before entering phase

A B C

FIGuRE 1. DEVELOPMENT AND ACQuISITION PROCESS (AS

OuTLINED IN DOD 5000.2)






design o a user inter ace that would be intuitive in an in ormation-intensiveenvironment like that ound in tactical Army Command and Control.

The history o CPOF at DARPA is broken out into our very distinctphases, which were led by three di erent program managers; the programendured at DARPA rom 1997 until it ully transitioned to the Army in 2006.

During the initial phase o the program, DARPA invested in exploring richdisplay technologies, arti cial intelligence agents, learning technologies,and in erence engines. This phase looked toward the uture commandpost—a high tech theater where commanders would be assisted byintelligent agents in making battle eld decisions, and where holographic

and high resolution displays would turn the Tactical Operations Center(TOC) o today into a command theater.

With Phase I complete, DARPA received some very speci c guidancerom senior o cers in the Army and Marine Corps about the e orts to

create a high tech command theater. During this phase, retired militaryadvisors led technologists through a series o decision support exercises,including eld exercises. The intent o this phase was to bring militaryoperators and technologists into the same environment, creating anatmosphere where the technology and operations could co-evolve.

The CPOF inter ace was developed and re ned during the third phaseo the program. Working in conjunction with the Marine Corps War ghtingLab and active duty units rom the Army and Marine Corps, a uniquedevelopment environment was created. It tightly coupled operators andtechnologists as they explored the possibility o radical changes in theway operators per orm their jobs with new technologies.

1990 1994 1996 1997 1998 2003 2005

1994-1996:Development of information-centric UIparadigm. Founded on cognitive psychologyand human-computer interaction principles,Visage system supports natural interactions inhighly information-intensive environments.

1998-2003:Application of CoMotion to Command andControl problem creation of lab prototypefor CPOF. Evolution of the Double Helixdesign methodology.

2003-2005:Intense focus on taking lab prototype forCPOF and making it scalable and deployableto transition to the Army PEO.

Oct 2003:Decision to eldCPOF to 1CD.

Apr 2005:General DynamicsC4Systems acquiresMAYA Viz.

Early 1990s:Development of SAGE expertsystem automating visualizationdesign, based on characteristicsof data and user tasks.

1996-1997:Visage-Link extendsinformation-centric UI todeep collaboration model.

1998:MAYA Viz founded tobuild CoMotion productcapturing principles ofinformation-centrismand deep collaboration.

Basic Research (CMU and MAYA Design): Systems (MAYA Viz) : Transit ion (MAYA Viz and General Dynamics):

FIGuRE 2. HISTORY OF CPOF PROGRAM



Command Po t of the Future: succe ful Tran t on of a January 2010 | 8sc ence and Technology in t at ve to a Program of Record

In the all o 2003, CPOF was introduced to [then] MG Peter W.

Chiarelli, USA, commander o the 1st Cavalry Division (1CD). MG Chiarellirequested that CPOF deploy with his division to Iraq. In this phase—42systems and servers—a team o technical and operations subject matterexperts were deployed in-theater. In March o 2004, working with MGChiarelli, the DARPA team deployed systems throughout the divisionheadquarters and to each o the brigade headquarters. The deploymentteam was able to work with operators to incorporate CPOF into part otheir daily battle rhythm.

With the early success o CPOF and its deployment with 1CD,

an agreement was codi ed in a Memorandum o Agreement (MOA)between DARPA and the Department o the Army. This agreement called

or continuing the deployment o CPOF to Iraq as an experiment, andurthering the experiment by elding CPOF to two additional divisions in

subsequent years. It also provided or a subsequent decision on transitiono CPOF to an Army Program o Record (POR). Transition was dependenton three measures:

• The ability to scale CPOF to 200 users• Demonstration o the use o CPOF over standard tactical

communications• Demonstration o interoperability with the ABCS.

oPeRAtionAl, tecHnicAl, AnD PRoGRAMMAtic collABoRAtion With the 1CD deployment into Iraq underway, a collaborative e ort

between DARPA and the Army began in earnest. DARPA’s e orts to datehad been ocused on creating the most intuitive collaborative inter ace.Very little work had been conducted to harden the system or operations

in a tactical environment. Together, a team that included a Marine Corpsprogram manager rom DARPA, soldiers rom the Army’s Training andDoctrine Command (TRADOC) and 1CD, and acquisition pro essionals

rom PEO C3T (Program Executive O cer, Command, Control, andCommunications–Tactical) and Army G-8, worked to put in place a 2-yearplan to cover operational, technical, and programmatic concerns. Seniorleadership o the division took ownership o the test- x-test process,allowing war ghters to dictate the requirements. MG Chiarelli understoodthe technical issues that needed to be conquered, and was willing to

accept the risk to see CPOF success ully integrated into the division.In parallel with MG Chiarelli’s use o CPOF in-theater, the Army and

DARPA decided to look at how best to continue CPOF development.DARPA and the Army came to an agreement, documented in the 2004MOA. DARPA would continue to und the advanced technology researchneeded to harden the system and exploit technical lessons learned. TheArmy would und the operational support and hardware procurements




necessary to execute the continued eldings. During this collaborative

phase o the program, DARPA provided $13.5 million o unding, and theArmy provided $37.5 million. DARPA would maintain primary control othe program or 2 years. The MOA also called or CPOF eldings to threeArmy Divisions (Operation Iraqi Freedom 2 through 4) and technologicalimprovements to CPOF so tware in the areas o scaling, satellitecommunications, and ABCS integration.

Some hurdles, however, needed to be overcome—none o which wereinsigni cant in the way the acquisition community procures new systems.

• DARPA’s involvement with and unding o CPOF wasscheduled to end at the conclusion o the 1CD rotation in Iraq.

• CPOF was not in the Army Program Objective Memorandumor unding, nor was there an o ce established that would

be able to take on a new program with many technicalchallenges still ahead.

• No approved requirement document was in place calling ora stand-alone system like CPOF.

• CPOF needed to meet the requirements imposed by theacquisition regulations and laws.

• Signi cant risks—namely scalability, per ormance, andABCS interoperability—still needed to be reduced to enablea broader use o CPOF.

• CPOF had minimal capability to interoperate with otherArmy and Joint systems.

To tackle these hurdles and maintain the momentum o the CPOFprogram, the PEO C3T and DARPA joined orces.

The Army Acquisition Executive (AAE) assigned CPOF management

authority to PEO C3T, and directed that the designated programmanagement o ce enter into an agreement with DARPA to support thetransition o CPOF technology to the Army. PEO C3T gave responsibility

or CPOF to PM Battle Command. In October 2004, the Army opened asmall program o ce or CPOF.

The 2 years’ leadership overlap, rom 2004 to 2006, between DARPAand the Army allowed time or relationships to develop, or technologytrans er to occur, and or the acquisition steps necessary or an ArmyPOR to be developed and approved. The Army PM shop integrated CPOF

requirements into the Maneuver Control System (MCS) CapabilitiesProduction Document (CPD), wrote a Test and Evaluation Master Plan(TEMP), and obtained the necessary Army and Joint approvals necessaryto eld and sustain a POR.

Formal transition o CPOF to the Army occurred in April 2006, andis documented in PEO C3T’s CPOF Decision Point 1 (DP1) AcquisitionDecision Memorandum (ADM).



Command Po t of the Future: succe ful Tran t on of a January 2010 | 1 0sc ence and Technology in t at ve to a Program of Record

ong ing Deve pment

MoDelinG AnD siMulAtion CPOF developers relied on modeling and simulation as well as heavy

experimentation to quickly grow CPOF into a success ul theater-widesystem. CPOF had three major technical challenges to overcome in thenear term: scalability, system stability, and ABCS interoperability. To meetthese challenges, new technologies and data management strategieswere modeled or their impact on the architecture. For example, a mid-

tier server concept was introduced to ease the bandwidth utilization overtactical networks. Through modeling and experimentation, CPOF wasable to demonstrate signi cant bandwidth reduction.

The rst step in any e ort to develop so tware is to get consensusrom the user community, including the direct users, on a concise set

o requirements. O ten this can be di cult, but since CPOF was eldedto select users as a commander’s tool in 2004, direct user eedbackwas readily available. The user and Field Support Representative(FSR) eedback was the primary source used to de ne and re ne therequirements. Each time a new capability was added, it was evaluated and

eedback was again given by the end-users and the FSRs. This constanteedback loop provided gradually increased capability by allowing the

so tware developers to ocus directly on the issues identi ed by theusers. It produced a higher quality, more use ul end product in a veryshort period o time.

The use o experimentation reduces program risk by continuallytesting out new unctionality and incorporating real-world eedback.Resources are not applied against a capability—either hardware orso tware—until the users and support people concur that it is worth the

cost and additional risk.

sPiRAl DeveloPMent The employment o end-user and FSR eedback in an “experimentation”

mode allowed a tighter or aster spiral development process to occur(vice the traditional so tware water all development). Following is adescription o the key capabilities o the rst two major spirals in the CPOFdevelopment, each about a year apart.

CPOF version 2.4 was the version resulting rom the spiral developmentthat was occurring in-theater. Some characteristics o this version are:

• Operates with latency o up to 1400 ms• Bandwidth use up to 18–28 Mbps during peak usage to

support a division elding



1 1 | A Publ cat on of the Defen e Acqu t on Un ver ty www.dau.m l

• Scaled to 200–250 users on a single master repository, with

40 users at the mid-tier• Supports 7 ABCS threads and 41 common tactical graphics.

The next version, CPOF 3.0 that 4th In antry Division used, improvedall o these characteristics:

• Operates with latency o up to 2,100 ms• Bandwidth use up to 5–6.5 Mbps during peak usage to

support a division elding

• Scaled to 300+ users on a single master repository, with 60users at the mid-tier

• Supports 14 ABCS threads and 89+36 common tacticalgraphics

• Increases stability via almost 300 CPOF bug xes.

Figure 3 shows the CPOF maturation and development through presentday that continues to address war ghter issues.

FIGuRE 3. CPOF MATuRATION OVER TIME

Feb 04CPOF InitialIssue to 1CD in Iraq

Feb 04CPOF In-TheaterAssessment

Jan-Mar 05Upgrades forInterop withPlatforms andC2PC

May 05Ver 2.2Upgrade

Apr 06CPOFTransitionedfrom DARPAto PM BC(Tech insert)

Apr 06Ver 3.02P2Rel for Test

Sep 05Ver 2.4 Upgradew/Mid-Tiers

Feb 06CPOF Expanded Fieldingto MNC-I and MNDsincluding USMC (Repos,Clients & FSRs)

CPOF 1G CPOF 2G CPOF 3G

1000

0

2000

3000

4000

5000

6000

2004 2005 2006 2007 2008 2009

Aug 06CPOF IOC

Feb 07Ver 3.1Rel for TestNOT FIELDED

Nov 07MCS/CPOFCo-Hosted

Mar 07Ver 3.02P4Rel for TestNOT FIELDED

Jun 08TBC (MCS) CPDJROC Approved

Nov 08QR1 Fldg DecisionNov 08Ver QR1 Upgrade

Sep 06Ver 3.02P2

UpgradeOct 06CPOF Transitionto PdM TBC

Nov 06CPOF MSB/C Decision

OIF ExpansionIncluding Clientsand FSRs

OEF SiteSurvey & Expansion

CGSCFielded

CTCs Fielded

BCTCs FieldedJoint & CoalitionMFE & Use

CGSC ExpansionKosovo Expansion

FY09 OEFExpansion

Jun 04 - 47 Nov 05 - 140

Mar 06 - 200 (Mid-Tier)

Jul 06 - 300

Jan 07 - 450

May 07 - 1523

750 -OIF TPE World-Wide FSR Support

135-OEF TPE

Oct 07 - 2062

Apr 08 - 3214

Oct 08 - 4495

Jul 09 - 5794

Fielded Clients

DARPA-ArmyTransition




At this point CPOF had met the Army criteria or transition rom

DARPA to the Army in the April 2004 MOA. In parallel with the DARPA-sponsored spiral development work in-theater, the Army program o cedeveloped an acquisition strategy to transition the program into a POR.

DeveloPMent of tHe BAttle coMMAnD vision foR tHe futuRe The Battle Command Migration Plan was developed and re ned to

map out the development, elding, and nally, retirement path or ABCSor the near- and long-term uture. It was developed in the context o the

current Army environment—the Army at war in Operation Iraqi Freedom/Operation Enduring Freedom (OIF/OEF), the need or increased Jointinteroperability, and Future Combat Systems/Net-Enabled CommandCapability (FCS/NECC) schedules. The plan took into account the need ortechnology insertions due to the rapidly changing available commercialproducts, and the need to upgrade existing so tware to better use thetechnologies that are available. The goals o the Battle Command MigrationPlan included lowering li e cycle cost by moving to a smaller ootprint;making the systems easier to use, train, and con gure; and elding a singlestandard capacity to every unit that provides the basis or their uniquetailoring needs.

CPOF was one o the rst technology insertions into the existingABCS 6.4 System o Systems. The Battle Command vision is to leveragethe CPOF technology, including its collaboration services and graphicaluser inter ace, as a ront end or all Battle Command applications/usersand possible trans ormation into the single visualization system or BattleCommand. Key development tasks are planned to enable this, including:

• De ning an open set o Application Program Inter aces

(APIs) and a Third Party Development Kit (3PDK) to enablemultiple vendors to build CPOF-enabled modules orspecialized Battle Command unctionality

• Leveraging DoD standard mapping services, such as theCommercial/Joint Mapping Tool Kit (C/JMTK), to providea richer set o mapping capabilities, including commonsymbology and maps

• Leveraging common Active Directory services or commonuser management and authentication across CPOF and the

Battle Command in rastructure• Leveraging a uture PEO-provided Tactical Enterprise

Voice Over Internet Protocol (VOIP) solution; War ghterIn ormation Network-Tactical (WIN-T) is the targeted PORto provide this capability.




One o the key ideas in this vision is leveraging the capability in CPOF

to which the soldiers in the eld consistently give high marks—ease o useand ease o training. This common plat orm provides a consistent map andset o graphics, greatly enhancing interoperability.

Reducing Ri k

All o the above—the experimentation in-theater, spiral development,and development o the vision or the uture—was done in parallel. The

goal o all o this was to get the ullest capability to the soldier rapidly,while laying the groundwork or uture development—all while reducingprogram risk.

RisK MAnAGeMent Risk management was one o the major project management tools

or CPOF development, test, and elding. The CPOF e ort is continuouslyevaluated to determine exposure to risk and how to best handle suchexposure. Speci cally, the risk management aspect o the CPOF aimsto allow CPOF to be elded to the user community with as many risksidenti ed, mitigated, or categorized as acceptable, as possible (Thomas& Cook, 2005).

The Product Manager, Tactical Battle Command (responsible orCPOF), and the contracted development team are both responsible orper orming risk management activities. The contractor is responsible

or assigning appropriate parties and/or organizations or en orcing andper orming risk management activities.

An example o a risk matrix is shown in Figure 4. It identi es risks,

categorizes them, and suggests possible mitigation. One o the things thatmakes this management tool so e ective is that the risks and possiblemitigation paths are publicly discussed. In this way, the entire communitycomes to a similar understanding o the capabilities and limitations o theproduct. The acquisition strategy was directly tied to the risk analysis. Theevents and decisions were based on the identi ed risks. Major risk areasidenti ed were:

• Scalability

• Interoperability• Supportability• Full-Spectrum Operations• Architecture

Development e orts were designed to address these major risk areas.








Speci c tasks to address these risks have been developed and

crosswalked with the TRADOC Capabilities Manager (TCM)-developedrequirement. Then these requirements are balanced with the expectedresource availability to develop the build plan.

Risk assessments were done in parallel with the early DARPAdevelopment. It was clear that CPOF, while providing needed capabilityin-theater, needed work to become “productized.” Risks to the program—technical and programmatic—were identi ed. Then mitigation plans weredeveloped openly or each risk. This in-theater eedback loop—short allsidenti ed, ed back into the risk plan, mitigated, and xes sent back in-

theater—allowed incrementally better product to get into the soldiers'hands quickly.

tAiloRinG Acquisition stRAteGY to AccePt tHe new tecHnoloGY usinG A sPiRAl PRocess

The standard DoD 5000 acquisition strategy was tailored speci callyto allow the new CPOF technology to make it to the eld sooner ratherthan later. It was also tailored so that CPOF could be incorporated as atechnology insertion into the ABCS System o Systems.

The acquisition strategy was speci cally designed around mitigatingrisks. An honest risk assessment was the rst step—do the analysis oCPOF’s short alls and put mitigation plans in place or each identi edrisk. The development tasks ell out o the mitigation plans. For example,one risk was scalability in-theater; i.e., moving rom 200 users to morethan 1,000 users. The mitigation plan noted that the server architecture

Elections

ATECC&LReport*

OPER Assess3 ID Scaling

ID CPOF“Low Hanging Fruit”

DARPASW DeliveryCPOF 3.0 TRADOC

PrioritizedReq

OPER Assess4 ID “Big 3”

KTR Test Risk Assess

Reprogram FY06 OPASustainment of in theaterBuild to requirement

Reprogram FY06 OPASustainment of in theaterBuild to requirement

TransitionProgram Review

Contract Award

CDRDP1ADM

DP2ADM

Tech AssessmentRisk Mitigation Plan

ProgramReview

ATEC User Test Baseline Risk Assess(1 CD?)

CTSFThread/LatTest 3.0/6.4

OPACPOF forIn theatreSustainment

RDTESE/BC ARCHRisk ReductionCPOF Eval

OPAACQ of all unitsRetro t

RDTESE/BC ARCHDevel Next

SW Block 4.0

YES

NO

YES

NO

Nov 05 Dec 05 Jan 06 Feb 06 Mar 06 Apr 06 May 06 Jun 06 Jul 06 Aug 06 Sept 06

3rd ID4th ID

FIGuRE 5. ACQuISITION DECISION FLOW CHART

*Based on 4th Infantry Division Mission Rehearsal Exercise (MRX) (29 Jul-4 Aug),

1st Brigade Combat Team National Training Center Rotation (6 Sep-4 Oct) (and the

3rd Infantry Division Full Operational Assessment III in-theater—Tentative)




would not support that many clients (users). The redesign o the server

architecture to add mid-tier servers was a key development task. Thestrategy was developed to x the risks over time, rather than trying todevelop the per ect product in one delivery.

The Acquisition Decision Flow Chart is shown in Figure 5. It showstwo decision points (DP) where leadership had the opportunity to reviewthe progress o the program and to decide i the program was ready tomove orward as planned. Each o these decision points was linked to anevent that could be used to demonstrate whether or not CPOF was readyto move ahead. These decision points enabled the leadership to evaluate

program risk to determine the best path orward.The acquisition strategy included two key decision points as shown

in Figure 5. These were selected in advance at junctures in the programwhere go/no go-type decisions could be made. These decision points werenot selected based on schedules, but rather on whether the program wascapable o proceeding to the next step in the acquisition process, i.e., theydemonstrated readiness or trans er and reduction o risk. Decision Point1 (DP1) was held to determine i CPOF had met the transition goals or theArmy to accept the technology rom DARPA. DP2 was a Milestone C-likeevent to determine i CPOF was capable o being elded as part o theso tware block to the entire Army. For Decision Point 2 (DP2), a brie wasgiven to the community, including the General O cer (GO) leadership,showing that CPOF had the capability, certi cations, documentation, andsustainment capability to support the decision or elding.

The CPOF Addendum to the MCS Acquisition Strategy was signed byMG Michael R. Mazzucchi, USA (Ret.), in July 2005.

• CPOF is a technology insertion into MCS, which was in ullrate production.

• To ensure that DARPA met the conditions o the Army-DARPA MOA and that CPOF was per orming satis actorily inunit operations, the Army conducted a Level I DevelopmentTest (DT) event and a series o Level II OperationalAssessments o CPOF in elded units. These assessmentsprovided data or in ormed decisions at DP1 and DP2,respectively.

• DP1 was conducted in March 2006, and documented inthe PEO C3T DP1 ADM dated April 2006. The purpose o

this decision point was to accept transition rom DARPAand approve Research, Development, Test, & Evaluation(RDT&E) unding to reduce risk and baseline/assess theCPOF system; and to approve Other Procurement, Army(OPA) unding to support theater and continental UnitedStates elded units. DP2 included a CPOF Block II MilestoneC to determine whether the current block o so tware/




hardware was suitable or elding in accordance with the

ABCS 6.4 schedule. DP2 also included CPOF Block IIIMilestone B to authorize research, development, and testactivities or continued CPOF development.

• The CPOF acquisition strategy refected the use oinnovative solutions and utilized best practices in the

ollowing aspects:{ Extensive use o integrated government-developed

so tware and COTS so tware{ Streamlined acquisition processes wherever appropriate

• Capability is to be provided incrementally, putting the besto 80 percent solution into the eld quickly.

• Contracting Strategy { So tware—So tware development, so tware

maintenance, felding support, feld service support,

training, and documentation were procured via a 5-year

sole source (i.e., a 1-year basic plus our 1-year options)

basic ordering agreement with the so tware developer.

Upon attaining a success ul DP2, task orders were

awarded on an annual basis as required to support

additional felding o the baseline CPOF product and

related activities.

{ Hardware—Hardware and peripherals to support CPOF

feldings were procured via award o task orders on a

competitively awarded hardware ordering contract.

Hardware procurement included a 5 -year warranty or

all items.

Design and Program Reviews were also scheduled at regular intervals.

These gave the leadership and the rest o the community an opportunityto evaluate CPOF. This helped ensure that CPOF development stayed insync with the rest o the Army programs, and that the program risk waswithin acceptable limits. The acquisition plan also speci ed design reviews.These reviews were publicly held and covered technical, programmatic,and unding issues. They were intended to engage the community. Again,the philosophy is that the more that is known about a system’s capabilitiesand limitations, the better the ocus that can be brought to solve issues.This allows a more capable, use ul system to make it to the eld.




le n learned: be t Practice f r a succe fu Tran iti n

Inserting a new technology into an existing System o Systems is nota straight orward or easy task, but some key lessons were learned duringthe CPOF transition.

leADeRsHiP Leadership o both the technology provider and the receiver must

be ully engaged and supportive. The MOA helped ease the transition by

providing a 2-year window, along with adequate unding, or the DARPAand Army teams to collaborate on how best to grow CPOF into a eldedsystem used by soldiers every day.

vision A vision, both near-term and long-term, greatly helps in both

acquisition and technical issues. The vision to use CPOF as the commonplat orm or collaborative services has stretched the original system to llgaps le t by the other ABCS system o systems. The vision provides the

ramework or breaking large strategic goals into smaller, more executableones. It also helps prioritize e orts.

eXPeRiMentAtion Experimentation is needed in developing a success ul product.

Exposing ideas to actual (vs. laboratory) conditions changes the waydesigners and developers view the system. Many improvements toCPOF were made because the system was deployed in-theater so early

in its development cycle. Even a ter CPOF was integrated into the ABCSsystem o systems and had scaled to over 5,000 systems, experimentationcontinues. A concerted e ort is underway to continually solicit andincorporate all user eedback into the system to make it relevant to thecurrent ght. Experimentation must involve the user up ront and earlywith a tight eedback loop with the developer.

event-DRiven PRocess

The spiral process used to insert CPOF into the ABCS POR was atailored DoD 5000 process. It was event-driven, using regular, scheduleddecision points to proceed. At each, the system was honestly evaluated todetermine progress and to steer towards the optimal path orward.




MAnAGinG cHAnGe

Any new system or technology will require changes or adjustmentsonce exposed to real-world conditions. CPOF, in the years that it hasbeen in the eld, has changed signi cantly. It has been scaled up rom

just a hand ul o systems and now inter aces directly into ABCS. CPOFis an o cial part o the LandWarNet (LWN)/G3 so tware baselines thatare elded to Army. This has only been possible because all parties haveembraced the new technology and worked hard to incorporate it andtailor it to best advantage. Accepting and managing the change havemade this possible!

coMMunitY RisKs Most importantly, communicating risks and issues in an open, honest

way helped manage expectations o soldiers, leadership, and technologists.Regular risk assessment and mitigation discussions at all levels helped

ocus resources where they were needed most. For example, one earlytechnical risk was the concern about how the CPOF network would scalein-theater. The mitigation or this risk, which was actually executed, was toincrementally grow the network in-theater. This was success ul and allowedthe users and technical support to address smaller issues as they occurred.

C nc u i n

The transition o CPOF rom DARPA to the U.S. Army was success ulor a number o reasons. Tailoring the DoD 5000 acquisition strategy

allowed new CPOF technology to be elded as a technology insertioninto the ABCS. The keys to this success ul transition can be linked to the

e cient use o risk management techniques to drive the program orward,use o early and sustained eedback rom the user community, maintainingtransition unding stability, and honest and open communication betweenall stakeholders.

AcKnowleDGMents The authors would like to thank LTC Richard Hornstein, USA, Product

Manager, Tactical Battle Command, and his team or answering many

questions and helping ensure the accuracy o the in ormation. They wouldalso like to thank Ms. Sheri Silverstein or assisting with the research.




A h r B graphBG Harold J. Greene , USA, serves as the

military deputy commander o the U.S. ArmyResearch, Development, and EngineeringCommand. He previously served as the U.S.Army Project Manager, Battle Command,where he led the transition o CPOF to the U.S.Army. BG Greene holds a PhD in Engineering

rom the University o Southern Cali ornia(USC), as well as master’s degrees rom

USC, the Army War College, and RensselaerPolytechnic Institute.

(E-mail address: [email protected])

Dr. Larry Stotts is the deputy directoror the Strategic Technology O ce at the

De ense Advanced Research Projects Agency(DARPA). He is a Fellow o the Institute oElectrical and Electronics Engineers andSociety o Photo-Optical InstrumentationEngineers. He has published over 85 ar ticles.Dr. Stotts’ awards and recognition includea National Partnership in ReinventingGovernment Award, two DARPA TechnicalAchievement Awards, two Secretary oDe ense Medals or Meritorious CivilianService, the Technical Cooperation ProgramTechnical Achievement Award, and a Naval

Ocean Systems Center (NOSC) TechnicalDirector’s Achievement Award.





Mr. Ryan Paterson is currently the

ounder, president, and chie executive o cero IST Research, LLC. He previously served asthe DARPA Program Manager or CommandPost o the Future. The CPOF programdeployed to Iraq and transitioned to the Armyduring his tenure. He is also a veteran o theUnited States Marine Corps. Mr. Patersonholds a BS in Mathematics rom VirginiaPolytechnic Institute and State University and

an MS in Applied Mathematics rom the NavalPostgraduate School.


Ms. Janet Greenberg is currently asystems engineer working in the StrategicBattle Command o ce at Fort Monmouth,New Jersey. She has over 25 years o so twareand systems engineering experience inboth military and commercial applications.Ms. Greenberg received her BSE and MSEdegrees rom the University o Pennsylvania.Ms. Greenberg holds two U.S. patents.





REFERENCESDepartment o De ense. (2000, October). The defense acquisition system (DoD Directive

5000.1). Washington, DC: Author.

Myers, B., Malkin, R., Bett, M., Waibel, A., Bostwick, B., Miller, R. C., Yang, J., Denecke, M.,

Seemann, E., Zhu, J., Peck, C. H., Kong, D., Nichols, J., & Scherlis, B. (2002, October).

Flexi-modal and multi-machine user interface. Proceedings o the Fourth IEEE

International Con erence on Multimodal Inter aces (ICMI’02). Pittsburg, PA: IEEE.

Retrieved July 24, 2009, rom http://www2.computer.org/portal/web/csdl/doi/10.1109/

ICMI.2002.1167019

Thomas, J. J., & Cook, K. A. (Eds.). (2005). Illuminating the path: The research and

development agenda for visual analytics. Richland, WA: National Visualization and

Analytics Center.




APPENDIX

List o Abbreviations and Acronyms

1CD First Cavalry Division3PDK Third Party Development Kit4ID Fourth In antry DivisionAAE Army Acquisition ExecutiveABCS Army Battle Command SystemsACQ Acquisition

ADM Acquisition Decision MemorandumAPI Application Program Inter aceBC Battle CommandBCTC Battle Command Training CenterBDE BrigadeBN BattalionC2PC Command and Control Personal ComputerC&L Capabilities and LimitationsCDR CommanderCHS Common Hardware SystemsCGSC Command and General Sta CollegeC/JMTK Commercial/Joint Mapping Tool KitCM Con guration ManagementCOTS Commercial O -the-ShelCPD Capabilities Production DocumentCPOF Command Post o the FutureCTSF Central Technical Support FacilityDARPA De ense Advanced Research Projects AgencyDDR&E Director, De ense Research and Engineering

Devel DevelopDIV DivisionDoD Department o De enseDP Decision PointFCS Future Combat SystemsFldg FieldingFOC Financial Operational CapabilityFSR Field Support RepresentativeGO General O cer

Interop InteroperabilityIOC Initial Operational CapabilityIOT&E Initial Operational Test and EvaluationJROC Joint Requirements Oversight CouncilKTR ContractorLat Lateral




LRIP Low Rate Initial Production

LUT Limited User TestLWN LandWarNetMCS Maneuver Control SystemMFE Material Fielding ExceptionMNC-I Multi National Corps IraqMND Multi National DivisionMNS Mission Needs StatementMOA Memorandum o AgreementMS Milestone

NECC Net-Enabled Command CapabilityNET NetworkNOSC Naval Ocean Systems Center (Navy Laboratory)OEF Operation Enduring FreedomOIF Operation Iraqi FreedomOPA Other Procurement, ArmyOPER OperationalORD Operational Requirements DocumentPASS Publish and Subscribe SystemPdM TBC Product Manager, Tactical Battle CommandPEO C3T Program Executive O cer, Command, Control, and

Communications—TacticalPO Program O cePOR Program o RecordQR1 Quarterly Release 1RDT&E Research, Development, Test, and EvaluationRel ReleasedRepos RepositoryRIN Risk Identi cation

S&T Science and TechnologySE/BC ARCH Systems Engineering/Battle Command ArchitectureSoS System o SystemsSW So twareTBC (MCS) CPD Tactical Battle Command (Maneuver Control System)

Capabilities Production DocumentTEMP Test and Evaluation Master PlanTRADOC Training and Doctrine CommandUID Unique Identi er

TRL Technology Readiness LevelTSM TRADOC Systems ManagerUSMC United States Marine CorpsVer Version




Documents

Post Comand