Providing strong, clear direction in the face of ambiguity is vital to an acquisition program’s success.
by Col. Luke Cropsey and Mr. Peter Burke
There is an old adage about what the command “to secure the building” means to each military service. It goes like this: The Navy would turn out the lights and lock the doors. The Army would surround the building with defensive fortifications, tanks and concertina wire. The Marine Corps would assault the building, using overlapping fields of fire from all appropriate points on the perimeter. The Air Force would take out a three-year lease with an option to buy the building.
Although this adage is, of course, a joke, it also serves as a cautionary tale about the importance of a strong and clear problem statement within successful acquisitions. To “secure the building” barely describes “what” is to be done and leaves out the other two critical elements, “why” and “how.”
Consider the situation facing a project manager (PM) who prepares for a team meeting the next day to kick off the materiel solution analysis for the Army’s newest guided mortar cartridge. He read the capability development document, received some guidance from his program executive officer (PEO), spoke to his customer counterpart at the U.S. Army Maneuver Center of Excellence and met with his resource manager at HQDA. He needs to unleash his team to generate a wide range of possibilities to meet the user’s requirements while balancing cost, schedule and risk, and he knows that a good problem statement is critical to kick off the discussion. Framing it too narrowly could mean missing valuable opportunities for better capabilities, but making it too vague could result in months of program churn as the integrated product team chases tasks that have nothing to do with the real problem facing the customer.
How should the PM proceed? They key is to arrive at an appropriate level of detail so there is clear understanding about the problem without overly constraining the options that may be available.
INCOMING!
A 155-mm Copperhead anti-armor projectile nears its target. Operating issues with the Copperhead left thousands in inventory and unused for decades despite two tank wars in Iraq. The problems may have been prevented if the critical elements of “why, how and what” were employed early on in the projectile’s development. (Photos courtesy of the authors)
In the process, the PM must control the complexity of the problem, allowing him to understand the entirety of the problem in the process of solving it. Current weapon systems are some of the most complex man-made entities the world has ever produced, and a PM can quickly become lost in the myriad of variables, options, interdependencies and priorities, with little better than serendipity to fall back on when the program runs into challenges. The PM can control complexity by developing a clear problem statement that focuses on the most important issue.
Carefully constructed problem statements resolve ambiguity, control complexity and focus creativity. These three factors are central to a well-structured effort. It is human nature to jump out of the problem definition stage and into solution-seeking before fully understanding or articulating the true problem. A clearly articulated problem statement prevents this.
NO STATEMENT, NO SOLUTION
Unless the problem statement is constructed carefully, bias, ambiguity and missing needs can occur with disastrous results. In the 1970s, a laser-guided, 155 mm artillery projectile known as Copperhead countered the threat of massed Soviet armor in Eastern Europe. Copperhead could detect, guide-to and hit an armored target, and the large, shaped-charge warhead was consistently lethal against its target set.
Its development and qualification were successful, and industry produced thousands of projectiles for the Army in the late 1980s. However, more than 20 years later, nearly all of the Copperheads are still in inventory despite U.S. forces fighting two wars against armored threats in Southwest Asia. Anecdotal comments from field artillery units may explain why, such as:
- Most Soldiers never trained with the Copperhead in a live-fire situation.
- The projectile was expensive ($34,000 when procured in the 1980s).
- It was difficult to set up firing conditions.
- There weren’t enough laser designators in the force.
Could these issues have been prevented if the initial problem statement—including the critical elements of “why, how and what”— had been generated at the outset?
THE FRAMEWORK
A good problem statement is solution-neutral and outlines how value is created. In acquisition terms, this could be developing a materiel solution for a capability gap, finding the root cause of a test failure, solving organizational inefficiencies or a problem facing our professional workforce. (See Figure 1)
A problem statement, as defined by Dr. Edward F. Crawley, Ford professor of engineering in the Massachusetts Institute of Technology’s Engineering Systems Division, must include:
1. To… (enterprise or stakeholders’ intent, or the “why” you are attacking the problem; what value are you trying to create?).
2. By… (the “how,” using solution-neutral verbs such as create, destroy, transport, transform, compare, etc… ).
3. Using… (the “what,” or statement of structure; this introduces cost).
4. While… (detailing other important goals or constraints).
It is very important to carefully construct the “how” statement with solution-neutral verbs to spur divergent thinking that will create ideas for solving the problem. Unintended framing can occur if the chosen verb instantly narrows the possibilities and converges on a smaller set of possible actions. For example, if a hospital is looking for ways to improve the speed of care to car accident victims, inserting the word “driving” into its problem statement can shut out many other possibilities such as air, rail or water transport, or even virtual care applied at the scene by first responders.
Had the original problem statement for the Copperhead included goals addressing the training of field artillery units in this new capability, such as, “while ensuring that a realistic and affordable training system for unit home station and national training centers (less than $1,000 per training mission) is completed prior to production,” the warfighter might have gotten more value from the large investment made in its development and production program.
Including “live or die” goals, key metrics that will guide thinking during development, ensures that the team understands what is most important to the user. An easy place to start is in the key performance parameters (KPPs) of requirements documents. In the case of the Copperhead, had a KPP included a defined goal (with a clear metric for measuring the achievement of the goal) for an affordable and realistic training system, the round might have been put to more widespread usage in combat. Once these metrics are inserted into the problem statement, all team members will know what the guiding, tangible goals are, and they will influence their thinking. For example, the phrase “average unit cost of $5,000 (FY16 dollars)” is much more powerful than a nebulous term like “low cost.” A clear dollar amount will shape which materials are chosen, manufacturing processes, technology maturity and design complexity for the remainder of the program.
The following system problem statement is an example of a poor start for the PM’s materiel solution development phase. (In this example, assume that an analysis of alternatives has been completed, and a materiel solution, a new mortar cartridge, is the most effective approach.)
STAYING INSIDE THE BOX
Judiciously build the “how” statement with solution-neutral verbs to spur divergent thinking that will create ideas for solving the problem. Unintended framing can occur if the chosen verb instantly narrows the possibilities and converges on a smaller set of possible actions. (Image courtesy of the authors)
“Provide the U.S. Army with a cost-effective precision mortar cartridge to defeat enemy targets.” This is not a complete problem statement: It is too ambiguous, system goals are undefined, there is no explanation of the “why” or the stakeholder’s intent, and there are no clear metrics.
A much better statement would be, “Provide the U.S. Army a system to quickly defeat personnel with low collateral damage, by destroying enemy combatants with XX percent expected fractional casualties in Y rounds or less, using a mortar cartridge with a program average unit cost of $ZZ,zz.” This statement includes the key facets to focus the team’s attention and creativity, as it includes: “To…” (intent) + “By…” (solution-neutral process) + “Using …” (process attribute + object) + “While …” (object attribute).
THE ANTIDOTES
- Challenge problem statements continuously. Almost without exception, the initial articulation of the problem will be insufficient or even flat-out wrong. Asking a series of “why” questions will help continue to refine the overall intent and desired functionality of the solution. A good problem statement requires an iterative process with multiple passes to get the scope, level of detail, and solution concept right.
- Watch for unspoken assumptions by people framing the problem in solution-specific terms. For example, using functional verbs such as “tape” that drive the team in one direction may too narrowly frame solution sets, especially in the early phases of the effort. A better verb for keeping options open would be “attach.” Force the additional rigor in the process to begin with solution-neutral functional statements. This will naturally turn the dialogue to clear statements of what creates value and leave the trade space as broad as possible in the early stages.
- Carry expanded and contracted versions of the problem statement as options. It is sometimes difficult to truly understand what your stakeholders really need, so be flexible in your thinking. A key method of building alignment across the PM team is to work collectively with the problem statement by expanding and contracting the scope until the team can condense around the level of detail. The scope should be within the PM team’s ability to control (ideally) or influence (at worst), or the outcomes will be outside the team’s ability to affect.
- Invite diverse thinkers to early meetings. Too many people who “think just like you” can lead to a biased viewpoint. Seek out people with big ideas or from different backgrounds (contracting officer, cost analyst, system analyst, etc.)
- Make sure stakeholders buy in. The “why” of what you are doing is critical to maintaining their support and their confidence in the team. The “representative of true success” must be revisited on a regular basis to ensure that the solution actually matters. In the words of Winston Churchill, “No matter how elegant the strategy, someone should occasionally look at the results.”
- Create early models to test attainability. Does your program office’s estimate for development cost show that a course of action is within budget? In a technical problem, does your finite element analysis tool show that stress levels are within the material properties of available material technology? How much margin does a given solution provide on the cost, schedule and performance requirements? How much affordability risk does a particular concept or solution create? The longer it takes to produce the solution, the higher the risk of funding instability, requirements creep or threat evolution.
Testing your stakeholders’ interest in the “why” of your statement can also illuminate your path. For example, if you, as the PM, framed the original “why” from the perspective of your PEO, modify it one level up to the perspective of the PEO’s boss, the service acquisition executive. In the example of the mortar cartridge, another measure of success might include system compatibility with a future platform or low cost of maintainability over its shelf life. Likewise, move the perspective down one level below the PM to the system engineering lead. Does that person’s measure of success for creating value include ease of platform integration? If your problem statement aligns with your key stakeholder’s interests, is solution-neutral, and solvable by real people, you are off to a great start.
ON TARGET
The Copperhead, shown here impacting its target and developed in the late 1980s, was consistently lethal against its target set. With a few modifications to the program’s development process—a better defined goal and a clear metric for measuring achievement of it—the round might have seen more widespread usage in combat.
CONCLUSION
Programs get bogged down when they’re ill-defined. That lack of definition only gets worse when a new PM rotates through. If the problem statement results in a materiel solution that takes too long to deliver or does not meet customer needs, it could waste millions of dollars.
Consider the situation facing a PM who has just taken over a program to produce the Army’s newest guided mortar cartridge. A well-defined program, based on a well-defined problem statement, should allow for program business to continue as usual, with little or no ambiguity facing the team, and little danger of the program getting bogged down.
For more information, contact Peter Burke at peter.j.burke.civ@mail.mil.
COL. LUKE CROPSEY is the senior materiel leader for the Direct Attack Program under the Air Force’s Program Executive Officer for Weapons at Eglin Air Force Base, Florida. He holds an M.S. in system design and management from the Massachusetts Institute of Technology, an M.S. in materials science from Michigan State University and an M.S. in national resource strategy from the National Defense University. He is a distinguished graduate of the United States Air Force Academy with a degree in mechanical engineering. He is Level III certified in program management and in engineering, and is a member of the Air Force Acquisition Corps.
MR. PETER BURKE is the deputy project manager for combat ammunition systems under the Army’s Program Executive Office for Ammunition, Picatinny Arsenal, New Jersey. He is a graduate of Harvard Business School’s General Management Program, and holds an MBA from the Florida Institute of Technology and a B.S. in industrial engineering from the New Jersey Institute of Technology. He is Level III certified in program management and in engineering, and is a member of the Army Acquisition Corps.
This article will be printed in the October – December 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.
