This week, some thoughts on requirements shaping. The concept is simple enough, and I've discussed it in some depth previously. The core shaping principle is to present the customer with strong reasons to discard capability requirements that would be weaknesses in a potential offering and embrace capabilities that are strengths or discriminators specific to your company's profile. As a refresher, at the foundation, the government establishes an operational requirement, which may be highly conceptual at the beginning. The customer depends on industry to enter dialog with them to help bound the requirement in terms of technical complexity, cost, or development schedule metrics. This dialog may be formal, as in the case of a request for information (RFI), or informal, as in the case of visits and briefings. An emerging need may indeed be real, but available technology may make development or acquisition impractical without establishing limits on specific elements of the required capability. To be sure, there is little that can't be done in the technology domain given enough money and time. We proved that we could go to the moon if cost was not to be considered a limiting factor. Modern acquisition programs don't generally enjoy that latitude however. Identifying for the customer the areas where cost, schedule, and performance may introduce risk to their acquisition plan is an expected and necessary element of defense and the broader government acquisition process. The other side of the shaping coin involves advertising a capability (that you have) relevant to the operational need that perhaps hasn't been clearly recognized by the customer. If this is a company discriminator, the shaping strategy at its core is to present this to the buyer as a value added element of their basic requirement with the goal of incorporating it in the performance specification. Although conceptual briefs taken on a road show to decision makers is a common tactic, nothing succeeds in this domain like good old hard test data, and to the extent that the capability can be shown to actually exist and perform, one will find far stronger customer interest and willingness to take action in modifying the capabilities description.
So how about the actual mechanics of shaping. Who do you visit and when? There are two primary stovepipes in the acquisition process and tiers within them. First, operational requirements begin with operators. Interaction with the actual "boots-on-the-ground" war-fighter is the best way to understand the real operational need and environment and to start a bottoms up campaign. If the operator embraces your capability and absorbs the art of the possible, he or she will carry that message up the chain. Dialog should then occur at intermediate levels up to key operational and theater commanders to ensure transmission and continuity of this message. This should also include the warfare requirements officers who are the primary government bridges to the second stovepipe which is the system command. The systems command is where it is appropriate to advertise development challenges. The acquisition work force is charged with taking the capabilities documents from the operators and building an executable program. Accordingly, the right initial interface is with the government program manager and program executive officers. They invariably understand programmatic risk and the concept of cost as an independent variable.
Lastly, I'll provide an old axiom from the acquisition world: Follow the money. More about that next week!
Comments