Can you hear me now? How to stay connected in Afghanistan
WIN-T project manager faced political and technical problems in theater
In “WIN-T gears up to deliver on-the-move comms” (July 2010, Defense Systems), Warfighter Information Network-Tactical Project Manager Army Col. William "Chuck" Hoppe discussed some of the lessons he learned during the six months he spent in Afghanistan as the principal staff member for command, control, communications and computer (J6) for U.S. Forces-Afghanistan South in Kandahar. At the LandWarNet conference in August, Hoppe offered a more detailed examination of lessons learned during his time at Regional Command South (RC South).
In this new magazine section named Lessons Learned, we will occasionally share observations and recommendations from military program managers and principals who have recently returned from theater operations. Defense Systems Editor-in-Chief Barry Rosenberg attended the briefing, and he summarized Hoppe’s observations. Look for more Lessons Learned sections in future issues.
Hoppe is the program manager of WIN-T at the Program Executive Office for Command, Control Communication-Tactical, based at Aberdeen Proving Ground, Md. Hoppe began his career in 1983 at the U.S. Military Academy at West Point, and he has since commanded B Company, 5th Battalion, 16th Infantry Regiment, 1st Infantry Division, based at Fort Riley, Kan. He was also commander of the Army Research Development and Acquisition Information Systems Activity and product manager of the Acquisition, Logistics and Technology Enterprise Systems and Services division at Radford, Va. Hoppe also has earned three master's degrees. He became part of PEO-C3T in 2006 and has been WIN-T's program manager for more than three years.
Interoperability in the Field Among NATO Allies
I kind of expected the U.S. staff to work with the coalition, but there is some fiction in there that I didn’t understand. What I truly was not ready for was U.S. arrogance. In RC South, RC West and RC North, it was truly a coalition fight. I’m not saying that RC East didn’t have a coalition environment, but in RC South Kandahar area, we had 18 nations, including the battle groups from the United Kingdom, Canada and Australia; two U.S. [brigade combat teams]; and the Marines. It was a joint coalition fight, and every time the U.S. would bring a solution set to the table, it was a U.S. [Secret IP Router Network-based] solution. So there was no way the U.K. battle group commander could see to U.S. units. There was no way the U.K. two-star division commander could talk directly to his brigade commanders because we brought U.S. stovepiped solution sets.
Ramp Ceremonies for Fallen Soldiers
Every regional command had its own way of starting a repatriation of a fallen hero. In RC South, we had a ramp ceremony where every one of the nations represented would show up at the open ramp of a C-17 or C-130 — whatever happened to be dedicated for that flight that day — and as the unit color guard and pallbearers would take that fallen hero and put them on that aircraft, they would walk through a cordon of coalition units. The watch phrase for us was to do everything we could to minimize the number of ramp ceremonies. From a communications standpoint, this is always about move, shoot, communicate, and this was very much about how we make sure people communicate across the U.S. and coalition networks.
Operation Iraqi Freedom vs. Operation Enduring Freedom Mentality
What is the first step in problem solving? Define the problem. Here is my problem. I’d go into a meeting with coalition guys, U.S. guys — it didn’t matter. We wouldn’t even so much as get half the problem statement out and somebody would say: "Here’s how we did this in Iraq in 2003." I would let them go on for a little while, and then I would say "OK, but we’re in Kandahar, or we’re on the Pakistan/Afghanistan border, and it's 2010." So let’s define the problem as it exists today and get out of the experiential discussion and get into what is the problem we're trying to solve today.
Systems Integration in Theater
Try not to do systems integration in theater. Everybody wanted to help by bringing in a new piece of a kit that was going to solve somebody’s problem. What happened is that we wound up spending a lot of time doing the integration on the ground in theater instead of doing that integration back [in the] United States.
Hardware Failures in the Field
I had a number of problems with antenna control units. At one point, I had 10 terminals down, and I was losing them on a regular basis. We worked with the [original equipment manufacturer] and got that resolved, but there isn’t much backup when you’re fighting and you lose this piece of kit. So we had people scrambling on alternate and emergency communications setups. Getting stuff to them, at times, to get it fixed was sometimes a challenge.
Unrealistic Expectations for Resources
We didn’t have any or very little intra-Kandahar fiber. We were very sparse in terms of network connectivity. We had no external fiber out. Everything was running on generator. We had a small piece of Kandahar that was run on prime power, and that was being run by NATO. So everything that was being run was being run off a generator. I had an organization come into Kandahar that was doing its site survey. They showed up with 17 72-inch racks of equipment as a replacement system for something. And, of course, they needed power, environmental control units, fiber, and all this stuff as part of their site survey. That was not happening.
Again, that was a U.S SIPRNet solution. It wasn’t even going to provide anything to the coalition fight that was going on there.
We really do need to figure out a way how to build systems that are interoperable and that will help us work joint — Army, Navy, Air Force and Marines. I was the only Army guy on the J6 staff. Everybody else there was Air Force or Navy. We don’t do a good job in the joint arena, and we did a really lousy job of it on the coalition side. We had a lot of repetitive and competing solution sets. We had more than one organization that would come in with a piece of kit to solve a problem — the same problem. And when you asked them who they were sponsored by or how they were going to do this, you found at that it was never coordinated. These were genuinely good people wanting to help solve problems, but when you’re at that point when you see it all starting to come together, you see the redundancy and waste caused by a lack of communications.
Importance of Architecture
We were doing very well across the board. There were a lot of things that with just a little bit of coordination and, from an engineering standpoint, just walking that engineering systems kill chain, we could do a lot better. I made a comment to Brig. Gen. Brian Donahue, [director of command, control, computers and communications systems at the Army’s Central Command], before I left theater, I said, "Sir, if I were king for a day, I would not let another piece of kit come into theater that didn’t have two things: the complete architecture so you know end to end how it is being connected and, two, an information dissemination architecture so you knew that the people who were supposed to be the end-users got the benefit of that data."
In every conversation where you talked kit, you had to walk [through] the systems engineering kill chain. You may bring a piece of kit, and you say that it is a capability, but it is not a capability until you have walked the entire system of everything that makes that piece of kit effective — the transport, the database that it connects back to, the power, etc.
Everyone talks about rapid acquisition or rapid equipping. So what are some of the things we can do? How do we stop the infatuation with the next shiny toy? How do we discipline ourselves so we say that before the next piece of kit goes in, we identify what comes out of the architecture?