This article is the sixth in a series of articles that discusses the most critical steps necessary for a successful program. This article focuses on the fifth critical task which is the development of an Acquisition Package for a contract for a major system or service. Critical steps previously discussed in this project management series are:
- Requirements Document
- Business Case Analysis (BCA)
- Work Breakdown Structure (WBS), Part 1 and Part 2
- Acquisition Plan
The “acquisition package” forms the heart of the contract for the program or project by providing all of the customer’s unique program requirements that must be included in the contract. It consists primarily of the following documents:
- System Specification
- Statement of Work (SOW)
- Contract Data Requirements List (CDRL)
- Data Item Descriptions (DID)
- Contract Line Item Numbers (CLINs) structure
- Other critical information necessary to execute the contract
Why are so many different documents required?
People unfamiliar with large program acquisitions/contracts wonder why so many different documents are required for a contract. The primary reason is to ensure all requirements for each type or category of program requirements are sufficiently addressed in the contract in a clear, complete, accurate, logical, and categorized manner. The primary types or categories of requirements usually required for major programs are:
- System/service performance and design requirements
- System/service test and evaluation requirements
- Documents or deliverables that must be prepared for the system or service
- Hardware and software, support services and other items that must be either developed or procured and delivered under the contract
- Quantity of each type of system, services, equipment, or other items that will be, or may be, procured and delivered under the contract
- Guidance that the customer wants the contractor to specifically follow for the design, development, test, production, delivery, and support of the system or service
What information should be included in each of these documents?
It is advantageous to address each major type of contract requirement in one of the above listed contract documents for completeness and to avoid redundant, confusing, or contradictory guidance. The following are very high level descriptions of what contract guidance information should be addressed in each of the contract documents:
System/Service Specification
All requirements that specify the design and performance for the system or service must be provided in this document. A handy rule to follow is the system/service specification “tells” the contractor “what” the customer wants. A few specific examples of performance and design requirements that may be addressed in a specification are:
- System performance requirements such as types and quantities of information to be obtained or processed
- Any specific hardware or software that the customer wants
- Human factors, reliability, maintainability and other design requirements
- Test and evaluation requirements
- System operational and inherent availability requirements
- Production requirements
- Size of the system and other unique installation requirements
- Anything the customer does not want in the system or service
SOW
All requirements that specify the processes and procedures to be used to design, develop, and test the system or service are addressed in the statement of work. The handy rule to follow for the SOW is that it “tells” the contractor “how to do” what the customer wants. Some examples of what information and guidance goes into the SOW are:
- Detailed guidance for each of the processes to be established under the contract (e.g., program management, configuration management, reliability and maintainability requirements, risk management, quality assurance, human factors, etc.)
- Design reviews, program management reviews, and other meetings and conferences
- Integrated logistics support (ILS) information and requirements (e.g., training, spare parts, system manuals, etc.)
- Information and guidance for system tests (e.g., reliability, maintainability, software, etc.)
CDRLs
The CDRLs are used to specify what documents are to be prepared and delivered to the customer under the contract. Examples of the information normally contained in the CDRLs include:
- Required delivery date for each document
- Submission frequency if more than one delivery is required
- The DID that is used to provide additional guidance information
- Format, number of copies and the distribution list for each CDRL
- Review, resubmission and approval cycles and time frames for each document
- Customer’s organization or representative authorized to approve each CDRL
DIDs
A DID is required for each CDRL (or document) to be delivered under the contract. The DID must provide the detailed guidance to be used in the preparation of each document.
CLIN structure
The CLIN structure is usually a separate section in a contract and is used to provide the following contract information:
- Type and quantity of each system or service to be procured each year
- Quantity and type of services or support required each year (e.g., training courses, sets of spare parts, engineering services, system installations, etc.)
- Specifies if each CLIN item is a “firm” requirement or an “option”
In summary, the following should be used to remember the purpose of each of the major components of an acquisition package:
- The specification is used to tell the contractor “what” the customer wants
- The SOW is used to tell the contractor “how” to do it
- The CDRLs are used to tell the contractor “ what” documents the customer wants and “when”
- The DIDs are used to explain to the contractor what detailed information the customer wants in the CDRLs
- The CLIN structure tells the contractor “what and how many items” the customers will or may purchase and “when” they will purchase them
Do’s and Don’ts for an Acquisition Package
Some examples of things to do and not to do in the preparation of an acquisition package are:
- Never include any requirement in a system/service specification that cannot be tested or measured. This will result in several problems, including, disagreement between the customer and the contractor as to whether or not this requirement was “met” and confusion, delays, and unnecessary costs encountered when the contractor and customer attempt to test or “accept” this non-testable system or service requirement.
- The specification and SOW should be written in clear “shall” or “must” statements to specify what requirements the system or service has to have. Never use “may”, “should”, or other similar words to specify a requirement that the system or service must have.
- Never “gold plate” the requirements for a system or service. While it is always a good idea to include “hooks” or the capability for “pre-planned product improvements” (PPPI) for probable future operational or support requirements when you are procuring a system or service, it is a waste of time and money to include “performance, design or support” enhancement capabilities that likely will never be required. An example of this might be the inclusion in the initial radar contract specification for the computer processing capability being expandable to process 10 times the number of aircraft that will ever be necessary.
- Always remember to specify every performance, design, and test requirement that you want in the system/service specification. The contractor is not obligated contractually to do anything that is not contained in the specification or contract.
- Always remember to specify every “document” that you want prepared and delivered in the CRDLs. Again, the contractor is not contractually obligated to provide any document that is not specified in the CDRLs. The same guidance goes for the DID’s – a contractor is not required to provide any information in a document that is not specified in the DID for that document.
- Proprietary technical data/design rights. This is an issue that frequently arises in the procurement of a system or service – that being if the buyer has any rights to the technical design of the system or service. This issue needs to be carefully assessed during the acquisition strategy phase of a program to preclude purchasing a system or service that ties the buyer to a lifetime contract with the “seller” of the system or service unless this result is acceptable to the buyer.
- Design and supportability requirements should be in consonance with the projected “life cycle” of the system or service. Again, it is a waste of money and time to include requirements that will be encountered beyond the projected life of the system or service.
- Make sure all stakeholders are involved in the preparation of the acquisition package to ensure all requirements are identified up front for the system or service to be procured. It will always cost more money and take more time to add requirements later.
This brief article is only intended to provide a high level overview of what should be addressed in the acquisition package for a large complex system or service. Please contact us if you would like to have more detailed discussions concerning the planning and execution of programs.
This is only intended to provide a high level overview of what should be addressed in the acquisition package for a large complex system or service. Please contact North Star Group if you would like to have more detailed discussions concerning the planning and execution of programs.
