Army Acquisition has been called many things. A team sport. A challenge. An opportunity to support the warfighter.All of these can be true on any given day in Army Acquisition, with the primary goal of pacing the threat, or as said more bluntly like a mantra by Maj. Gen. Kirk Vollmecke, the Program Executive Officer for Intelligence Electronic Warfare & Sensors: "deliver now."
In order to do this leadership has identified critical areas in their policies, procedures and personnel that they can alter, streamline for efficiency or create whole cloth.
This series will explore some of their tasks and implementations from the first steps in acquisition beginning with "hatching" new products to meet the needs of the warfighter to when the product "leave the nest" and become part of sustainment.Some of these targets were mandated at the highest levels of the acquisition, some were mandated through evaluating team requirements and capabilities and some were driven by PEO ingenuity.
This series will examine the hows and the whys of these changes, what they mean, and what they hope to accomplish.Process to Product Part 1: How To Prevent An Unrecognizable SandwichThere is a training drill that military instructors often use at the advanced level in the United States Army.The instructor divides a class of 10-20 people into about six groups. These six groups are given a seemingly simple task: write a military style Standard Operating Procedure (SOP) for the making of a peanut butter and jelly sandwich. They are given about an hour and a half to write this SOP.The instructor then collects the SOP's, and proceeds to execute using only what is written. Without fail, the room watches in horror as the instructor proceeds to follow the SOP to the letter.If the twist tie on the bag is not mentioned? The instructor tears open the bag of bread. If the sides of bread -- where the spreadable material is meant to go - are not designated clearly? One slice will end up with peanut butter and jelly on one side, facing out, with an unadorned slice underneath it. Worse, the peanut butter and jelly will end up on the outside of the sandwich with nothing in between the bread slices.This lesson in culinary carnage ends with the instructor placing these sandwiches-in-name-only with each SOP and the teams must identify how their SOP resulted more in an abstract art thesis than recognizable food stuff.Kam Lee, a systems engineer with PEO IEW&S, spear headed a new kind of training to prevent these "failed SOP sandwiches" on a higher level.In order to request a new technology to fulfill a need, the Army must create a Performance Work Statement. Lee created foundational training to ensure that across the board PWS's follow a standard, and further proposed that Integrated Product Team actively seek out test engineers as consultants if not full time members.This means defining the scope of a need, analyzing the results of that scope, and using that information to write the PWS. Lee's training brought a structured approach to this writing. The parameters for a product in all its phases, from its prototyping before its delivery to the government, then how many to deliver to the government for its approval, documenting system designs and changes along the way.Diane Pettersen, an engineer with the Acquisition & Engineering Division under PEO IEW&S assisted Lee with the training, and saw it as effort to build synergy throughout the acquisition process. This means ensuring a greater amount of detail, for example if the Army wanted a "car" merely designating "four wheels and a steering wheel" simply isn't enough."It might have to meet a certain weight, might have to go a certain speed, go a certain distance," said Pettersen. "All that will be in requirement spec that will inform the PWS and the whole requirement package.""[We should], make sure it's clear, legally binding and executable." said Pettersen. "We're trying to make sure everyone's on the same page: you start here, this is what you need to follow and these are the types of statements you should be using, some of the words you shouldn't be using because they are ambiguous."To that end, Lee and Pettersen taught the idea of having one person "take point" in document creation."What we're trying to instill here, beside the document, is the process. Have someone who is on point, someone is the central POC responsible for the document." said Pettersen. "That person is reading the document to make sure all the pieces are telling the same story."Similar to how a film director controls the main aspects of production, the Point Person ensures each piece from each person's area of expertise "fits the script.""You might have engineering, but you need a production engineer or someone to figure out how sustainment is going to happen," said Pettersen. "And then your tech manuals, your training, how that's going to be conducted. You need to have input from everybody."So we know one person needs to ensure that everyone is not only thinking of the "same sandwich," but also, that their area of expertise is fitting into the process. There would be a twist tie manager, a bread expert, a jelly technician, a peanut butter engineer (creamy or crunchy?) and so on.
Lee's training outlines the following functional areas for Systems Engineering: hardware, software, , program protection, test and evaluation, configuration management and quality assurance surveillance plan. Then Safety, Logistics and Program and Financial Management and any respective sub-categories.After all the data, specifications and milestones are made clear, a standard format is applied, those are a cover page, table contents and three defined sections that must appear in every PWS: Scope, Applicable Documents and Requirements. This standardization means that requirements will not only be clearer, but comparable between users and writers.Finally, Lee made it crystal clear in his lessons that language is incredibly important to the core of PWS: avoid ambiguity as often as possible. Phrases such as "as applicable," or "as required" are far too vague. Who determines what must be made and when must be clear.Another term Lee is specific in avoiding is "best commercial practices" first because it's undefined and second because what is the best commercial practice may not be best for the warfighters in the short or long term.This clarity that Lee teaches is essential not only to get a PWS out the door, but even more for Army Contracting Command, where Contracting Officer Abby Jordan works."I've been in the Army as a civilian for almost eight years, and prior to that I was in private industry." said Jordan of her experience, which informs her perspective on building a PWS.
"Part of it is really engaging with industry, early and often." said Jordan. "For example, if it's a competitive procurement, releasing draft PWS's and getting feedback from the community.""I know how to make a peanut butter and jelly sandwich, it's pretty clear to me," she said. "But a contractor, if they were to win that contract? They may look at it differently and say 'I don't know what you're saying here, are you saying A-B-C when you mean I should be doing X-Y-Z?' We've had a lot of success releasing PWS's early to the industry and just getting their take on where there may be confusion or even getting their take on how we can incentivize performance at the end of the day."Jordan will often seek industry thoughts on a PWS when she receives it, in order to ensure it's as clear as possible."I've been through many alpha contracting sessions where we go paragraph by paragraph in the PWS," she said. "The government will say 'this is what this paragraph means to me,' and the contractor will then say 'well, this is what the paragraph says to me.' Then we work together to still get the overall requirement and get rid of any misunderstandings."Lee and Pettersen's methods, combined with Jordan's pursuit of consensus with industry partner will be key in implementing these standards of PWS writing across the PEO IEW&S portfolio, and perhaps expand to the whole acquisition community in the future.