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.
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.)
"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.
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.
This article will be printed in the October -- December issue of Army AL&T magazine.
Social Sharing