Contrast the Army Signal Corps SOW [Statement of Work] for the Wright Brothers’ heavier-than-air flying machine in 1908 to the Air Force SOW for the Advanced Tactical Fighter in 1986. Requirements in the 1908 SOW (e.g., be easily taken apart for transport in Army wagons and be capable of being reassembled for operation in an hour, carry 350 pounds for 125 miles, and maintain 40 miles per hours in still air) and other contract conditions were specified on one page. The requirements section in the 1986 SOW for the Air Force Advanced Tactical Fighter is 85 pages long with 300 paragraphs of requirements. Today’s SOWs are much more complex requiring greater attention to detail.
That was from the 1996 MIL-HDBK-245D, DoD Handbook for Preparation of Statement of Work (SOW). The authors suggest that more complex technology requires more complex contract requirements, and that’s simply a fact of life. However, within the last few years even complex programs have moved to broader Statement of Objectives (SOO).
One program that was touted for taking a more streamlined approach to their requirements is OMFV (at least for the 2nd solicitation attempt, the 1st had only one bidder). The Phase 2 concept solicitation has 17 pages in Section C, Work Statement. Most of that is enforcing a modular open systems architecture (MOSA) and definition of key system interfaces. The whole solicitation is 136 pages. By no means is OMFV as streamlined as major contracts up through the 1950s, but perhaps it is trending in the right direction.
It seems to me that one of the biggest hurdles is the architecture. If the entirety of the open systems architecture is to be planned for in the initial proposals to assure the government it won’t be vendor locked, then it really limits the ability for solicitations to be streamlined. In turn, the complexity of the solicitations and detailed paper planning requirements push away the exact companies the government wants to bring in for competition.
There’s the catch-22. If government streamlines to requirements to target high-level outcomes, then it fears proposals stacked with proprietary elements. If the government enforces detailed MOSA planning, then it bundles together too much paperwork and boxes out non-traditional contractors.
The major question is whether government can avoid vendor-lock so long as major interfaces are fully documented with government purpose rights. Success may not need extensive before-the-fact planning and rights to all the “black boxes.” Particularly for software, API documentation can be delivered to third parties at relatively low cost.
And moreover, the promise of the STITCHES tool to translate between different interfaces allows for “federated” development. Interoperability could be achieved without a return to a massive upfront planning exercise for the system of systems. This is still an open question, however.
Leave a Reply