Been there, done that

Been there, done that: The weight thing

Those ugly extra pounds—or even grams—can derail your program or product.

by John T. Dillard, Col., USA (Ret.)

I can honestly say that just about everyone wants to lose weight. A multimillion-dollar weight loss industry attests to this. It’s no different in the armed forces. All defense products typically have that one thing in common: They’re too heavy. From missiles to radios, satellites to submarines, aircraft to land vehicles, heavy weapons to small arms—not just the man-portable items—they all need to weigh less.

Over the decades, I’ve seen many system development efforts struggle to attain their weight goals. Often they have weight as a key performance parameter (KPP), among their many other technical performance requirements.

WEIGHT IS A REQUIREMENT THING

As a young acquisition officer, I wanted to carry that perspective forward into whatever programs I became involved with that developed Soldier-carried items. I was thrilled to be able to work on the M-4 carbine initiative at Picatinny Arsenal, New Jersey, back in the 1980s—shortening the M-16 A2 rifle—along with more exotic technology base efforts involving mini-grenades and even caseless ammunition.

In 1987, we contributed our concepts and early prototypes, along with the other Army research, development and engineering centers, to an advanced technology demonstration at U.S. Army Natick Soldier Research, Development and Engineering Center to show what the “Soldier of the Future” would look like. But on demonstration day, we were horrified when we all suddenly realized that everything Army labs were doing was collectively adding weight to the basic Soldier load—whether giving the Soldiers increased ballistic protection, new rations (which required water to hydrate), optical rifle sights, night vision, computerized radios and even a new bayonet (with sharpening stone). There was no doubt that Soldiers needed these new capabilities, but darned if we weren’t all adding weight to our warfighters with our individual high-tech advancements.

Upon entering a major program management office with a portfolio of close combat munitions, I saw firsthand an early “bunker buster” munition development program that was canceled before it could even get off the ground—because no prospective contractor could honestly bid on our request for a 10-pound solution. The requirements community had stood firm on that one. It would cost them time. It was years later that they eventually had to accept several solutions in the 15- to 17-pound range (the FGM-172 Short-Range Assault Weapon and the Mk 153 Shoulder-Launched Multipurpose Assault Weapon).

Yep, when it comes to weight as a system or program requirement, it can be a real biggie for you to consider. Is it a measure of your product or program success?

WEIGHT AS DESIGN CONSTRAINT

Of course, our materiel development team derives our users’ requirements and translates them into design specifications. So it’s especially important for you to know this: While weight is one of many possible technical performance parameters, it’s one that affects others to perhaps a unique degree.

Just think about the trade-offs among performance parameters of range, payload, speed, mobility, fuel economy, survivability, lethality, transportability and even reliability (if stress-over-strength comes into play with various components). It might also factor into durability or robustness—not-so-often-used terms intermingled with reliability and utility. Weight can ripple through your system design like water, as second- and third-order effects are realized when things grow out of hand.

Remember that complexity is defined basically as the known and unknown interactions of many different connected pieces, and our business is the business of managing complexity. People want us to do things fast, but it’s more important to do things right. The following examples illustrate some of the implications of being overweight.

‘I ONCE HAD A WEIGHT PROBLEM …’

The highly successful Javelin anti-tank missile was a deeply troubled development program in the 1990s—and was almost canceled over its weight problem. Entering this program management office (PMO) in the middle of the engineering and manufacturing development (EMD) phase, I learned weight was one of our four KPPs. We had known it was a risky goal right up front, along with several others. But at milestone B, we said, “We can do it.” It was a much-needed capability to replace the legacy 72-pound (and highly unreliable) Dragon missile.

We had conducted a 27-month technology maturation phase and had selected one prototype from three to take into advanced development. But we were a long way from anything that looked like a true configuration of the finished product. As EMD began, our preliminary design review had only been sufficient to map out the basic design and componentry to be “invented.”

About 18 months into our 36-month EMD phase, approaching critical design review (and before actually building a representative engineering design model), we realized we were not going to be able to make the 35-pound desired (objective) or even 45-pound required (threshold) weight required by the user in the requirement document.

During a typical system development, functionality, weight, cubic dimensions, interfaces and a host of other specifications are allocated to various producers. It may be quite some time before designs evolve, progress is realized and forecasting actual system weight is even possible. No excuses, though: We bit off more than we could chew.

STATISTICS ADD UP

Also, there is an additional weight “stack-up” issue to deal with consisting of even the tiniest of screws, fasteners and other components. With the Javelin, we realized that there could be a statistically possible (though highly improbable) 2-pound difference between the lightest and heaviest possible assembled systems within the same production lot—assembled, of course, from many parts from many respective production lots.

Makes sense, right?

So, consider this: Before the design was complete—before the parts were assembled, with computerized data coming in from our subcomponent suppliers—we knew well in advance that we could not deliver, and that we would likely be in the range of 47 to 50 pounds. (See Figure 1.) So we went all the way up to the Joint Requirements Oversight Council to request a KPP requirement threshold increase to 49.5 pounds. Fortunately, our user friends supported us all the way.

Trouble was, nothing on the Javelin weighed 5 pounds that we could do without—the reduction had to be accomplished by “salami-slicing” the weight “budget” for individual components—changing materials and redesigning to reduce weight without sacrificing durability or reliability for such environments as rough handling, loose cargo transport, water immersion and vehicle storage rack mounting.

It actually took all of us in the PMO a while to fully realize that to get weight out of our system, practically every component would have to be redesigned.

We went into “gram management mode” to monitor the technical performance measurement of the weight in each subcomponent. (Yes, there are 454 of those little grams in a single pound.) We spent millions of dollars in component redesign.

Our little Javelin project slipped 50 percent in its advanced-development schedule and more than doubled its advanced-development costs—in large part because of weight-reduction redesigns throughout the entire system (though we did indeed have other technical challenges to contend with). (See Figure 2.) Naturally, that threw off all of the funding allocations tied to the program objective memorandum- and future years defense program schedule funding, and necessitated formal program re-baselining with congressional assistance to “re-color” the money.

Eventually, redesigned components arrived for assembly. So along the way, as development moved to completion, we had a mixed bag of about seven different Javelin configurations with substantial differences among them—a complication for testing and evaluation, reliability analysis and scoring, etc. These all settled down to one final configuration by the time operational testing rolled around. We used the extra schedule to fully test these subcomponents as they came in, to be sure we hadn’t sacrificed other important properties when we shaved off the weight. As a result, system-level testing went off without a hitch. And we came in just under the 49.5-pound threshold.

WHAT – AGAIN…?

Later, as product manager of the Joint Advanced Special Operations Radio System, I inherited a radio program that also had weight as a KPP. And I once again found it to be a challenge.

During the technology maturation phase, while receiving a briefing on a completed and functional 21-pound multiband transceiver prototype that was supposed to get down to 10 pounds in coming months, our prime contractor indicated that it was going to lose weight by making things more compact inside.

The radio largely consisted of five densely populated Standard Electronic Module, Format E cards with a planned reduction to only two. Having the benefit of the Javelin experience behind me, I knew what question to ask: “How much do the three cards being eliminated weigh?” The answer was 2 pounds each—not at all adding up to the 11 pounds we had to lose—and eyes in the audience began to widen. “Great, now how are we going to lose the other 5 pounds?” I asked. For a moment—just a very brief one—I was the smartest soul in the room. It didn’t help much, though. We were already on our way.

TIMING IS EVERYTHING, AND A WORD TO THE WISE

For program managers, realizing that weight is an important parameter up front and early is important, but not nearly enough alone to alleviate weight’s programmatic perils. Even though contract incentives can be put in place for weight goals, the cost-reimbursable contract environment typical of most development efforts puts the government at significant risk if weight concerns are not fully identified and addressed before EMD.

Stringent controls must be issued to subcomponent suppliers that will severely constrain their individual weight allocations if preliminary design reviews should reveal an issue. A weight problem may at first appear to be like many other technical performance shortfalls where specifications have simply not yet been met. And a program can often proceed with sub-spec prototype testing until the final configuration test articles eventually emerge. But as I’ve explained here, the implications can be significant.

Since 2001, when technology readiness levels (TRLs) and assessment methodologies came more fully into use, I have found it curious and troubling that nowhere in the listing of levels 1 through 9, which range from glimmer-in-the-eye to fully ready to go, did the word “weight“ appear in the descriptions of tactical maturity or readiness.

Even today, we seldom find mention of this important parameter of near-final design configuration. (However, descriptions including this parameter later become more specific and are now found in references like the Technology Readiness Assessment Deskbook, 2009, specifically in supporting information for consideration of TRL Level 6.) Corporately, we are finally beginning to learn the lessons.

While it is easy not to expect early prototype hardware to be fully of “form, fit and function,” we do ourselves a disservice if we dismiss the challenges of weight and the many technical and financial implications it can have on a program.

CONCLUSION

Program managers would do well to heed the advice of those who have gone through the pain of weight reduction programs. Hopefully, those of us who have been there have touched upon implications of design costs versus programmed funding, configuration management, diligence in measurement, testing and the managing of requirements:

• PMs must watch out for over-optimism in the area of weight.
• Realize the cost and schedule implications of extensive component redesigns necessitated by weight constraints, along with their attendant configuration and reliability risks.
• Discover your weight situation early.
• Revisit the requirement if you must. Consider the following, for example:
  • Does it have to be one-man-portable or could it be crew-served?
  • Does it really have to be C-130 transportable, or would a C-117 be sufficient?
  • Does it really have to fly a round-trip sortie of 400 miles? Users might not appreciate your questioning, but they’ll like even less your failing to deliver what was promised. We simply cannot promise to deliver things that violate the laws of physics, like a light tank, for instance, that is armed to a caliber required for lethality but with a chassis so light it cannot possibly sustain the recoil forces of mass times acceleration.Extensive modeling and simulation may curtail an imprudent investment and allow developers to “just say no” to the impossible.Early testing and evaluation is another real way of understanding things fully a bit later on, but that involves hardware investment up to the point of engineering design models and test article manufacture.Be cognizant of the stack-up phenomenon, and manage to the gram if necessary.

Above all, whenever weight is mentioned in a development effort you are involved with, perk up your ears and look for the red flag. You might become the smartest soul in the room, if ever so briefly.

JOHN T. DILLARD, COL., USA (RET.), managed major weapons development efforts for most of his 26-year career in the U.S. Army. He is now a senior lecturer in systems acquisition management at the Graduate School of Business and Public Policy, U.S. Naval Postgraduate School in Monterey, California. He has also served on the faculty of the U.S. Army War College and as an adjunct professor of project management for the University of California, Santa Cruz. He holds an M.S. in systems management from the University of Southern California and is a distinguished military graduate of the University of Tennessee at Chattanooga with a B.A. in biological sciences.

---

This article is published in the April – June 2018 issue of Army AL&T magazine.

Subscribe to Army AL&T News, the premier online news source for the Acquisition, Logistics, and Technology (AL&T) Workforce.

---