Why Requirements Definition is Hard

Whether you're a Program Manager or a Contracting Officer in the federal government, or a contractor trying to address a Request for Proposals, you've undoubtedly experienced frustration trying to understand how to interpret contract-level requirements. The federal government is usually good at defining the high-level capability requirements for a program but the translation down to contract-level requirements is usually where the breakdown occurs. That's largely a function of the fact that there is no real process for taking what was developed through the structured Systems Engineering process and cascading it down effectively to an actionable statement of work for industry to digest. Simply put, getting the same very smart people who defined what the government needed to fill a particular capability gap to then define what they need a company to do to help fill that same gap can be quite a challenge.

This disconnect between high-level program requirements and contract-level requirements manifests itself every day across the federal landscape. And it doesn't matter what type of system is being acquired or supported - it's hard across the board. The inability to effectively translate acquisition requirements into procurement requirements results in frustrated government officials and companies alike. Outcomes should be the ultimate measurement when it comes to Federal contracting success and getting to the right outcome is predicated, fundamentally, on both government and industry knowing what the right "ask" is when it comes to outsourcing needs. So, for example, how do we take that Requirements Traceability Matrix that the Program Manager developed and use it as a framework for writing a statement of work that will make sense to all parties involved in the procurement process?

I've seen this classic catch-22 play out numerous times in my career. If I were creating a comic strip about the issue it would look something like this:

Scene 1 - A Program Manager (PM) and Contracting Officer (CO) meet about a contract that the PM needs to execute his program. The CO informs the PM that a Statement of Work (SOW) is needed and the PM stares back at the CO in deafening silence.

Scene 2 - The PM asks the CO to write the SOW. The CO laughs uncontrollably.

Scene 3 - Several months go by and the CO asks the PM again for the SOW. *Crickets*

Scene 4 - The PM delivers a poorly-written SOW (because he is understandably busy trying to establish or run his program) and the CO spends several weeks trying to decipher/convert it into a product that industry can understand. Ultimately, the CO gives it back to the PM after failing to translate it into something that can work effectively for an RFP. "Back to the drawing board!"

Scene 5 - Frustrated, the PM tells the CO that she just doesn't understand what the program is trying to accomplish and, begrudgingly, agrees to revise it. Several more months go by.

Scene 6 - With time running out, the PM tells the CO that additional rework on the SOW cannot be accommodated and that the contract must get awarded soon before the funding expires.

Scene 7 - The CO acquiesces and puts the RFP out on the street. "I guess we'll just have to see what sticks."

Scene 8 - Companies complain to the CO that they don't understand the government's requirements. Several weeks go by while the government answers a myriad of questions from potential bidders.

Scene 9 - At the 11th hour, the CO awards a contract to the successful bidder. Several months go by as the contractor begins performance. However, it becomes painfully obvious to the PM that something is amiss ...

Scene 10 - The PM tells the CO that the company isn't doing what they need them to do and the CO asks the company to come in for a meeting.

Scene 11 - The PM and CO ask the Vice President (VP) of the company why "X, Y and Z" haven't been done in accordance with the contract.

Scene 12 - The VP, with stone face, tells them oh-so-politely ... "That's not what you asked for."

In my opinion, the way to alleviate this problem is to create a defined, structured, process for developing an actionable SOW with clear linkages to program/capability requirements and it can be as simple as these four elements:

Form - and sequester - an Integrated Project Team. All of the right individuals have to be in the room (even if its virtual), at the same time, and they have to be allowed by their respective managers to do nothing else but work on the SOW until it's deemed actionable by the CO.

Use a Requirements Traceability Matrix. If the program isn't large enough to have a PM (e.g., it's not a certified Acquisition program), the project manager responsible for getting the contract done can still use this tool as a good best practice to break functional requirements down based on discrete work packages that link to the government's needs. Using a more methodical approach, instead of just leveraging an existing SOW from somewhere else, will ensure that the product is developed based on the unique needs of the program. Half the problem is that contract SOWs are treated as if they're fungible.

Develop the Quality Assurance Surveillance Plan Simultaneously. Thinking through how the government will monitor the contractor's performance at the same time the SOW is being developed will help to inform and shape those important contract-level requirements by addressing existing capabilities and constraints on the government's side.

Issue a Draft SOW to Industry. Give the same companies that are likely to bid on the work an opportunity to vet the contract-level requirements before the RFP is even finalized. There is so much learning that can happen, on all sides, stemming from this best practice and it can do nothing but help to drive optimal outcomes.

Translating program or project level requirements into contract-level requirements doesn't have to be as challenging as we make it on the government side. Taking a more strategic approach to the task of writing requirements, coupled with increased communication with industry, can win the day and result in better return on investment for the agency's spend.