1. Statement of work CDRL, And Tracking Tool (SCATT) Mr. Jeremy Cucco
November 2011
Mr. Jeremy Cucco

2. Agenda Overview & Introduction Brief History SCATT Tool Components
SOW Questionnaire
CDRL Wizard
CDRL Tracking Tool
Who uses the SCATT Tool?
What is a SOW?
Practical Application

3. Introduction Jeremy Cucco Systems Engineer,
Marine Corps Systems Command
Systems Engineering, Interoperability, Architectures and Technology (SIAT)
SCATT SME
Milan Peich, L3/Qinetiq N.A.
24 Center St. 2nd deck
SCATT Content and Database Administrator

4. Mission Statement
Originally developed for the Marine Corps System Command;
To assist the Program Offices in the Marine Corps System Command in developing performance-based SOWs and CDRL packages and to assist in tracking contractor performance after contract award.

5. SCATT History Desktop Install 2001-2007 Aug 2007 - present
Continual updates made to Website via SME and IPT input.

6. The SCATT tool is comprised of three separate applications
Introduction
The SCATT tool is comprised of three separate applications
Web
The SOW Questionnaire contains a series of Yes or No questions to develop a draft SOW and CDRL package. Web-based tool.
Local
The CDRL Wizard allows tailoring of draft CDRLs for submission to Contracts. Import XML into Access Database.
The CDRL Tracking Tool is utilized after Contract Award to follow program status and monitor contractor performance in the area of data deliverables.

7. SCATT Model Draft CDRLs Draft SOW SOW Questionnaire Draft SOW
Utilizing an IPT environment YES/NO questions develops:
Draft SOW
CDRL file
Import the XML file generated by the SOW Questionnaire into the CDRL Wizard Database and tailor the CDRLs.
Monitor contractor performance after contract award with the CDRL Tracker & produce status reports.
Final
CDRLs
Program
Events
Draft CDRLs
Draft SOW
Contract
Award

8. SOW Questionnaire Notes
Provides change infor for each update to the FA version.
Open
Access the SOW Questionnaire.
View
Shows the list of Questions (and answers) for that Area.
Reset
Resets all the answers for that FA.
Note: When a Functional Area is complete, a reset is the only way to modify your answers
26 Functional Areas
Complete?
Yes or No indicates if the questions in that Area have been completed
Lead
Drop down box to allows you to assign other team members to a Functional Area of your project
Lead
Project Admin assigns Users
Locked?
No = Allows changes to questions in FA
Yes = Questions in that Area are currently being answered
Latest
SCATT is a “living tool” so updates may have been made since you last answered questions. Version control allows you to have the most current information.
Project
This is the version your project is using.
Red = New version available
Green = Started but not complete

9. Functional Areas IROAN/Rebuild Information Assurance Power
Program and Data Management
ESOH
Technical Publications
Government Furnished Property
Configuration Management
Support Equipment
Meetings/Reviews
Engineering Drawings
Training Products and Services
Systems Engineering
Item Unique Identification
Packaging, Handling, Storage and Transportation
Open Architecture
Integrated Logistics Support
Contractor Performance Measurement
Producibility
Maintenance Planning
Transportability
Testing/Verification
Supply Support
Software
Parts Management (DMSMS)

10. SOW Questionnaire
SCATT was designed for MCSC system/equipment acquisition programs coverings 26 areas
Over 200 Yes/No questions, - View the SOW paragraphs - Data Item Descriptions (DIDs) - Add comments
Project administrators invite and assign team members to complete functional areas.
Produces a draft SOW in .rtf and corresponding CDRLs in .xml. The draft SOW may be edited and the CDRLs tailored using the CDRL Wizard

11. SOW Questionnaire

12. CDRL Wizard

13. CDRL Wizard
The “Wizard” is a Microsoft Access database tool downloaded from the website and run locally that contains the DD Form (CDRL).
Tailors CDRLs and prepares them for submission to Contracts
Key features include:
- A link to view the corresponding DID
- Global changes to quickly update all CDRLs
- Imports the XML CDRLs from SCATT Web Version
- Dropdown boxes with standard entries IAW DoD M
- Distribution Statements for Blocks 9 and 16
Exports CDRLs to MS Word or database format compatible with CDRL Tracking Tool

14. CDRL Wizard

15. CDRL Tracking Tool

16. CDRL Tracking Tool
The “Tracker” is a Microsoft Access database tool that is used after Contract Award
Utilizes the Final CDRLs from the CDRL Wizard and key Program Events to track data submissions and monitor contractor performance
Each Submission for all CDRLs can be scheduled in accordance with an actual date or tied to a Program Event
Generates a wide range of reports that may be used for briefings on program status and contractor performance

17. CDRL Tracking Tool

18. Interest
Web Version – Released on 1 Aug 07 SCATT currently has approximately 1500 user accounts.
SCATT Training – The course is 8 hours in a computer lab and consists of both classroom instruction and hands-on application.

19. Better SOW’s – Better Contracts!
Benefits
Reduces the development time Development of an initial performance-based draft SOW and CDRL package does not require a “start from scratch” approach.
Ensures current MCSC policy/procedures are included Helps eliminate major revisions to the SOW/CDRLs during the review process.
Provides a more complete product Specific questions are asked which may have not been previously considered and possibly omitted if SCATT had not been used.
Standard Format SCATT ensures proper format for SOW and CDRL packages by utilizing MIL-HDBK-245D guidelines and principles, thus assisting in standardizing these documents that form part of Section C of the RFP.
Better SOW’s – Better Contracts!

20. Backup Slides

21. SOW/CDRL Guidance
Before getting too far into the details of how SCATT works, it is important to understand the basics of a SOW, CDRL and DID.
Since SCATT simply develops a DRAFT SOW and CDRL package, there is much work involved in tailoring the results of the SOW Questionnaire to meet your program needs.
The strengths of the CDRL Wizard are usually only realized by those who are familiar with the process of completing the DD Form (CDRL).
The CDRL Tracking Tool is of no use without understanding CDRLs and data deliverables.

22. Request For Proposal Part I. A. Solicitation/Contract Form Part II.
B. Supplies or Services and Prices/Costs
C. Description/Specifications/Statement of Work
D. Packaging and Marking
E. Inspection and Acceptance
F. Deliveries or Performance
G. Contract Administrative Data
H. Special Contract Requirements
Part II.
I. Contract Clauses
Part III.
J. List of Attachments (CDRLs, financial data, etc.)
Part IV.
K. Representations, Certifications and Other Statements of Offerors
L. Instructions, Conditions, and Notices to Offerors
M. Evaluation Factors for Award
The SOW is part of Section C of the RFP along with the Specification. Note that CDRLs are typically located in section J, List of Attachments.

23. SOW
Describes the work to be done in developing or producing the goods to be delivered or services to be performed by a contractor
To be written in performance terms by telling the vendor “What” you want them to do, not “How to” do it
Sections: 1. Scope; 2. Applicable Documents; 3. Requirements
References:
MIL-HDBK-245D, Handbook for Preparation of Statement of Work
Program Work Breakdown Structure (WBS)
Acquisition Strategy or Technology Development Strategy (TDS)
Initial Capabilities Document (ICD) or Capability Development Document (CDD)
The SOW is not like the Specification which has 6 sections. The SOW has but 3.
Acquisition Strategy states how you are going to contract, develop, test, and field the system.
The TDS is for programs prior to Milestone A.
ICD or CDD or CPD - provides the requirements and testing information that is a contractual document

24. Section 1: Scope
The SCOPE contains a “Brief Statement” of what the SOW should cover
Address the breadth and limitations of the work to be done
Background information should be limited to only provide the vendor with the basic acquisition requirement
Work tasks, requirements and deliverable products should NOT be included
1.0 Scope. This Statement of Work sets forth the effort required by the contractor for the manufacture, testing, production, delivery and support of the ABC System. It includes the associated program management, human engineering, manufacturing and logistic support efforts required to ensure compliance with the performance specification.
1.1 Background. The ABC System program has been initiated to procure, test and deploy a system that will lay and retrieve ABC’s at a faster rate than the current method. Currently, the ABC System program has entered the Production & Deployment Phase (Milestone C) to procure the ABC System approved acquisition objective.
We want to vendor to know just where we are in the acquisition process. What phase are we in?
Are we just starting to explore the requirements, and need studies?
Are we ready to make a buy?
Is this a rebuy?
The program description is a summary of where we have been.
The scope defines the breadth and limitations of the work to be done.
Background information should be limited to only that information required to acquaint the vendor with the basic acquisition requirement.
Do not include directions to the vendor to perform work tasks, data requirements, or description of deliverable products. Those go in Section 3 Requirements.
The end result is the end result of this contract not necessarily the whole acquisition program.

25. Section 2: Applicable Documents
2.0 APPLICABLE DOCUMENTS. The following documents of the exact date and issue specified form a part of this Statement of Work to the extent specified herein. In the event of conflict between the applicable documents and this SOW, the SOW shall take precedence. All second tier and below references cited shall be considered as guidance only. Nothing in this document, however, supersedes applicable laws and regulations unless a specific exemption has been obtained.
2.1 Military/Federal Standards and Specifications Mandatory
2.2 Military/Federal Standards and Specifications Guidance Only
2.3 Drawings
2.4 Handbooks (Guidance Only)
2.5 Other Government Documents
2.6 Non-Government Documents
2.7 Forms
This section is just a list of documents that are referenced in the SOW.
You must list the number of the spec. or standard along with the revision number, the exact title of the document, and the date of publication. Each standard may require a waiver as previously discussed.
Guidance only requires the same identifying number and title as the mandatory government documents however since they guidance and do not require the vendor to comply with them and they do not require a waiver.
Handbooks - These are Military handbooks, government instructions, service regulations, technical orders, and policy letters. They are for guidance only and are used to clarify statements in SOW or suggest formats.
Forms are any forms that may have to be filled out for the acquisition program.
If a paragraph is not needed, simply put “N/A” (not applicable) for that paragraph. This way the reader knows that this area has been addressed, as opposed to renumbering the remaining paragraphs.

26. Section 3: Requirements
Section 3 is the main portion of the SOW and contains all the requirements that the contractor must perform. All functional areas should be addressed:
- Program and Data Management
- Systems Engineering
- Producibility
- Environment, Safety, and Occupational Health
- Configuration Management
- Testing/Verification
- Integrated Logistics Support
- Open Architecture
- Technical Publications
- Support Equipment
- Training Products and Services
- Software
- Contractor Performance Measurement
This is a sample of what might be in section 3. This is not a complete listing.
Program and Data Management - Here we ask the vendor how he will conduct Program Planning, Schedule and control, Subcontractor Control, Data Management, Management and Accountability of GFE, GFM, GFI, Meetings, Formal Reviews, Conferences, and Audits.
System Engineering - Covers the performance requirements of the item. It also covers Human factors, HAZMAT, and R&M.
ILS - Here we plan to conduct Integrated Logistic Support for the item. In most cases the contractor will document his plans in a Integrated Logistic Support Plan.
Supply Support - Here we give the the vendor the parameters for spare parts.
Etc.

27. DO’s and DON’Ts Do: - Focus on “What” the contractor is to do
- Be specific and write in clear, understandable terms to define the tasks
- Know all reference documents and tailor them appropriately
- Put data delivery information on the CDRL, not in SOW
Don’t:
- Focus on “How” the task is to be performed
- Be wordy and write broad and vague requirements that are open for interpretation
- Use references just because they were used in the last SOW
- Confuse the SOW with the Specification and include specific technical requirements
- The next 4 slides discuss some the rules for writing a SOW and are not meant to be a complete listing of does, don’ts, words to use and words not to use, MIL-HDBK-245D contains the whole list.
- Focus on what you want to get from the vendor not how you want him to do it. The vendor knows his business better than you do.
- In writing be clear and concise tell him just what you want him to deliver. Writing in a vague manner will not help the vendor know what you want delivered.
- When you want a task done state it such as “the vendor shall conduct a first article test”. You don’t want to open to interpretation, no two people will interpret a vague statement the same.
- Write in terms of output in other words results. Don’t tell the vendor what to put into an analysis or study. Tell the vendor to conduct an analysis not how to do it.
- Writing by the pound doesn’t help. The more words you put into a SOW the harder it is for the vendor to wade through and find out what you want delivered.
- Cut and paste from existing SOWs is one of the more common methods of putting together a Statement of Work. It is exactly that putting together it is not writing. The most common reasons for doing this are poor writing skills, it was good enough for the other SOW and it will save time. The save time reason is not a very good one. The time saved is usually lost when the SOW is reviewed and sent back because it is fragmented an doesn’t hold together. Have you ever reviewed a SOWs where it was quite obvious that it was a cut and paste job because they forgot to change the acronym of the other program.

28. SOW vs. SPEC
A SOW defines all work performance requirements for contractor effort IAW MIL-HDBK-245D.
A Specification describes the qualitative and quantitative technical performance requirements of the system/item being developed or produced IAW MIL-STD-961E.
EXAMPLE: The Specification may cite reliability and maintainability (R&M) requirements using mean-time-between-failures (MTBF) and mean-time-to-repair (MTTR), while the SOW might task the contractor to establish, implement, and control an R&M program.
It is quite common to see specification requirements in a SOW, because the Program Team gets so wrapped up in the system or item being procured. The differences must be kept in mind when writing both documents.
MIL-STD-961E - DoD Standard Practice, Defense and Program-Unique Specifications Format and Content

29. Rules For Writing - Shall = Mandatory Action by the contractor
Define all abbreviations and acronyms
Use of “Shall” and “Will”
- Shall = Mandatory Action by the contractor
- Will = Government Action
If possible state only one requirement each paragraph
Avoid using these terms:
“Carefully performed” “Accurate workmanship”
“Unless otherwise directed” “As necessary”
“If required” “As required”
“In the opinion of the contracting officer”
- Define all abbreviations and Acronyms, you may know what the acronym means, however, vendors looking at the SOW may be doing it for the first time and not be familiar with military acronyms.
- Make every attempt to avoid ambiguity. Use consistent terminology. Do not use pronouns – repeat the noun to avoid any misinterpretation.
- Use the active voice, remember you are telling the vender what to deliver and when to deliver. Example: “The Contractor shall establish a program” instead of “A program shall be established by the contractor.
- “Shall” is used when you want the vendor to do something. “Shall” is a mandatory action and is legally binding. “Will” is used when committing the Government an action and simply expresses a declaration of purpose or intent. Do not use “Shall” for the Government, you don’t want to lock the Government in.
- You will find “as necessary” is not a good phrase to use. Most vendors will find that whatever you think is necessary is not. If required, “as required”, as well as, “as necessary” is vague, the contractor cannot determine the scope of the work.
- Once again I cannot say it too many times, tell the vendor what you want him to deliver, not how to do their job, they already know how or else they wouldn’t be in business.

30. Consequences Poorly prepared SOWs can often lead to:
- Confusion as to scope of work
- Delays in vendor selection
- Unnecessary litigation
- Disputes and claims
- Contract cost overruns
- Strained vendor/Government relations
Your goal is relay to the exactly what you want or you may not get it.
Delays will start the moment you send out the SOW for review. It will come back all marked up and take time to rewrite, and then will have go out for review again.
Unnecessary litigation and disputes and claims can be lumped together. Since the SOW becomes part of a legal contract, a vague and open to interpretation SOW is a field day for lawyers. This leads to the next bullet cost overruns.
When you have the Government and vendor on opposite sides of court case there are going to be some bad feelings. If the Government wins and the vendor has to eat the cost of the mistake, do you think the vendor will bid on the next RFP. There are number of vendors that have been burned and refuse to do business with the Government again. A few years ago the Marine Corps needed to do a rebuy of sniper scopes. The snipers want the eurtel scope since it is the best and all ready in use. The company had so many problems with the last contract they refused to even bid. The Marines had to buy a lesser scope.

31. Sample SOW Paragraph
EMI Test Report. The contractor shall prepare and deliver an Electromagnetic Interference (EMI) test report documenting the compliance of the SLERD’s EMI requirements of the contract specification.
DI-EMCS-80200B, Electromagnetic Interference Test Report (EMITR)
This is a sample paragraph that calls out a deliverable. The same requirement may be written many different ways and therefore there is no one “school solution”. Every request for a data deliverable must have a corresponding CDRL and authority (usually a DID, sometimes a TM).

32. Example SOW Paragraphs
Which SOW Paragraph should you use?:
a. The contractor will host the Post Award Conference 30 days after Contract Award. Other conferences and meetings may be held at contractor facilities as required.
b. The contractor shall host the Post Award Conference within 30 days of Contract Award. At the conference the contractor shall present management, key personnel, and program implementation processes.
c. The Government will host the Post Award Conference at a time to be determined. The contractor shall present management, key personnel, and program implementation processes.
The answer is b.
Uses “will” for the contractor. What if exactly 30 days after Contract Award is a Sunday? Are you going to have a PAC on a Sunday? No you are not. Also what other conferences and meetings? How many? These vague requirements leave the door open for future problems. It’s also hard for the contractor to price this work out.
Don’t use “shall” with the Government action. Furthermore, the Gov’t never hosts a PAC so simple logic and good business practice needs to be used when developing a SOW requirement.

33. Preferred Method
The Program Manager convenes a SOW IPT Meeting (usually 2-3 days long)
Review Program Status and Technology Development Strategy or Acquisition Strategy
Determine work requirements and data deliverables (if not already accomplished)
Develop the Draft SOW and CDRLs using SCATT and tailor to specific program needs
The SOW IPT, which is convened by the Project Officer, is when the program manager and the LEMs develop the requirements for the SOW based on the acquisition strategy.
A data call is a request to the LEMs (or users) for data products they will require to perform their function. The LEMs must justify all data requirements.
Every data product must have a corresponding DID in order to be a deliverable.
All players in the acquisition should be at the SOW IPT. It is here the scope of work is determined and the data deliverables are chosen.

34. Statement of Objectives
A Statement of Objectives (SOO) is a Government prepared document that describes the basic, top-level objectives of the acquisition. The contractor uses the SOO to propose a SOW and CDRL package. The SOO is not a contract compliance item. (typically 2-4 pages)
The SOO can be used where the intent is to provide the maximum flexibility to each offeror to propose an innovative development approach.
The SOO provides the Government with an opportunity to assess the offeror’s understanding of all aspects of the effort to be performed.
Section 5 of MIL-HDBK-245D describes the SOO
SOO are being used quite a bit in the Air Force. However in my experience researching and evaluating SOO across the services, they often combine both Performance Specification and SOW requirements into one document and call it a SOO. This is not in compliance with MIL-HDBK-245D and other SOO development guidelines.

35. Statement of Objectives
RFP Package
Development
Contractor
Proposal
Formal
Contract
Government
SOO
Proposal
SOW
Contract
SOW
Acquisition
Strategy
Acquisition
Program
Baseline
CDD
This shows the process of generating a SOO and the eventual creation of a contract SOW and the associated technical specification.
The SOO is drafted by the government program office with assistance from relevant technical experts (systems engineering, testing, and logistics) and is subject to approval by the contracting office. The Acquisition Strategy, Acquisition Program Baseline, Operational Requirements Document, user inputs, and original thinking from the project team are used in preparing a SOO. If the RFP has been issued in draft form before its formal release, input from industry may be available.
The offeror uses the SOO (along with the rest of the RFP) as the basis for preparing his proposal, including the proposed contract work breakdown structure (CWBS), the SOW, and CDRLs.
The SOO establishes the objectives for the product or service to be acquired. The acquisition project team uses this document as a key element of the solicitation and acquisition requirements documentation, and contractors use it as the basis for proposal preparation.
Does anyone see any potential problems in using a SOO?
Gold plating.
Government still needs to know what they want in their evaluation of the SOW sent in by the Contractors.
Proposal
Technical
requirements
documentation*
Contract
Technical
requirements
documentation*
Functional
Description
Technical
requirements
documentation*
Industry
inputs
(optional)
Negotiation
* Technical requirements can be changed
due to performance/cost tradeoffs.

36. CDRL Contract Data Requirements List (CDRL)
- Also known as the DD Form 1423
- Contractual vehicle that ties the DID to the SOW
- Provides the delivery schedule for the Data Item
- Allows the Program Office to tailor the DID using block 16 to meet their specific program needs
- DoD M, “Procedures for the Acquisition and Management of Technical Data” contains policy and guidance information on CDRLs
The CDRL is used to order the data required and tailor the DID.

37. SAMPLE CDRL Code Inspection Acceptance
Block A. Contract Line Item Number (CLIN), corresponds to section B of the RFP.
Block B. The exhibit (examples: A=ADMN, B=NDTI, C=????) that contains the CDRL.
Block C. TDP – Technical Data Package, TM – Technical Manual, Other – most check this.
Block D. The name of the system/item that is being procured.
Block E. This is contract number of the procurement. Should be blank if this is sent out as part of an RFP, a contract # has not be established.
Block F. Contractor’s name. Should be blank if this is sent out as part of an RFP, since a contractor has not be awarded as of yet.
Block 1. Data Item Number. This is the number assigned to this CDRL in the exhibit. AKA Sequence Number
Block 2. Title of data item.
Block 3. Subtitle of the data item, if there is one.
Block 4. Authority. This is the DID or TM/Spec/Standard document number.
Block 5. Contract Reference. The SOW paragraph were this data item is required.
Block 6. Requiring Office. This is the office that will ensure adequacy of this data item.
Block 7. This is the code that identifies how this data item will be accepted (LT = Letter of Transmittal Only). A DD 250 is a Material Inspection and Receiving Report (MIRP) prepared by the contractor for acceptance of equipment/data by the Gov’t, contractor invoice for payment, a packing list for shipping and receiving, and evidence of Gov’t quality inspection. A DD 250 is only required when SS, DD, or SD is selected. More: This block designates the location (contractor's facility or destination) for performance of Government inspection and acceptance. The applicable codes for inspection and acceptance are cited below. The Government activity to perform the destination acceptance task is entered in Block 14 as the first addressee.
Code Inspection Acceptance
SS *Source (DD Form 250) *Source (DD Form 250)
DD Destination (DD Form 250) Destination (DD Form 250)
SD *Source (DD Form 250) Destination (DD Form 250)
DS Destination (DD Form 250) *Source (DD Form 250)
LT Letter of Transmittal only
NO No inspection or acceptance required
XX Inspection/acceptance requirements specified elsewhere in the contract.
*Source indicates contractor's facility
Block 8. Check this box if the data item requires advance approval prior to acceptance. Approval Code. Items of critical data requiring specified advanced written approval, such as test plans, are identified by an "A" in this field. This data requires submission of a preliminary draft prior to publication of the final document. When advanced approval is not required, this field is blank.
Block 9. This is the Distribution Statement of the actual data item. Not the same as block 11 of the DID, though it may be. The Contractor needs to know if this is classified or what in order to appropriately mark and label the document.
Block 10. The frequency is how often we want the data item delivered.
Block 11. The cut off date for data collection. Leave this blank! As of Date (AOD). When data it submitted only once, this block indicates the number of days the data is to be submitted prior to the end of the reporting period; e.g., "15" would place the AOD for this report as 15 days before the end of each month, quarter, or year depending on the frequency established in Block 10; "0" places the AOD at the end of the month, quarter, or year. Further guidance is shown in Block 13 or 16 as required.
Block 12. Date of First Submission. This block indicates the initial data submission date (Year/Month/Day). When the contract start date has not been established, this block indicates the number of days after the contract start date that the data is due; e.g., 30 days after contract (DAC). Further information, if required is contained in Block 16. "DFDEL" indicates deferred delivery.
Block 13. Subsequent submissions. For multiple submissions. Date of Subsequent Submission/Event Identification. When data is submitted more than once, the date(s) of subsequent submission(s) is indicated in this block. Example: "Not later than (NLT) 15 days before start of production"; "45 days before first article", etc.
Block 14. Distribution and Addressees. The addresses and number of draft copies and/or final copies either regular or reproducible. The Requiring Office is usually listed first. Addressees and number of copies (draft/regular/reproducible) to be forwarded to each addressee as cited in this block. Addressees are indicated by office symbols (i.e., AMSIO-XYZ). A list explaining these symbols and their addressees is attached to the form or elsewhere in the RFP. When reproducible copies are required, the type of copies required will be cited in this block or Block 16.
Block 15. The total number of deliverables determined by the Distribution list.
Block 16. Remarks, this is where you clarify any of the other blocks. Also this is where you tailor the DID. If you use any other Distribution Statement besides “A”, then you must issue a warning here in block 16.
There are two ways of tailoring:
1. Stating the deletion: “Blk 10 - Paragraph 10.4 does not apply.”
2. Stating only the requirements that apply: “Blk 4 - Only paragraph 10.4 applies.”
Blocks 17&18. These blocks are completed by the contractor for pricing the data item.

38. DID Data Item Descriptions (DIDs):
- Describe the data products to be delivered by the contractor
- The DID itself cannot be changed, however certain requirements in the DID may not be necessary and can be tailored out using block 16 of the CDRL
- Approved DIDs are listed in the Acquisition Streamlining and Standardization Information System (ASSIST), see
- DoD M, “Procedures for the Acquisition and Management of Technical Data” contains policy and guidance information on DIDs
DIDs are governed by the Defense Standardization Program. More info can be found on this at under the “About the DSP” link on the left.
The DID’s use is to describe the data’s format and content requirements. If certain elements of the data are not needed, the DID should be tailored downward noting deletions in CDRL Block 16.

39. REQUEST FOR PROPOSAL (RFP)
SPEC-SOW-CDRL-DID
Relationship
OPERATIONAL
REQUIREMENT
DATA ITEM
DESCRIPTION
Training Plan
1. PREPARATION
INSTRUCTIONS
WORK TO BE
PERFORMED
PERFORMANCE
PARAMETERS
REQUEST FOR PROPOSAL (RFP) S P E C I F A T O N
STATEMENT
OF WORK
(SOW)
“3.5 The contractor shall
develop a training plan
IAW....”
SECTION C
SECTION J
CDRL
DD FORM 1423
Training plan
SECTION B
CLIN 0004
004 Training Plan
This is a graphic representation of how the SOW and System Specification fits into the RFP.
The Specification covers the performance requirements of the system to be procured.
The SOW covers work for the vendor to perform
The SOW will state a requirement for a data product.
Each data product requires a DID which describes what to deliver.
Section B “Supplies or services and prices/costs” contains brief descriptions of supplies/services including quantities, NSN’s, and part numbers. Section B identifies each item by a Contract Line Item Number (CLIN).
The CDRL (DD Form 1423) cites the DID and modifies its contents. Section J “List of Attachments” contains the CDRLs.
Down in the bottom left you see sections L and M. This is telling the vendor what expertise is required to be demonstrated so the Government knows the contractor can perform the task, and how the Government will evaluate them.
The RFP must work together each time you have a requirement you need to check each section to make sure the requirement appears.
REFERRED TO ON THE
CDRL FORM
Section L (Instructions)
Offeror shall provide
experience in developing
training programs, etc.
Section M (Evaluation)
Specifies importance
of training programs, etc.

40. Summary
Be familiar with MIL-HDBK-245D in order to develop a well written, performance-based SOW or SOO
SCATT is comprised of 3 separate applications: the SOW Questionnaire, CDRL Wizard, and CDRL Tracking Tool
A DID may be tailored using the CDRL to only invoke the specific requirements that the contractor must meet
ASSIST is the official database for DoD standard, specification, and DIDs:
SCATT is a “living” tool. Use the SCATT Web Version at for the latest information

41. Web Demo
MCSC Website

42. Contact Information
Marine Corps System Command SCATT website
marcorsyscom.usmc.mil/sites/scatt
SCATT Tool
Jon Wills
SIAT, M&JIC
Milan Peich
Qinetiq-na (QNA)
L-3/MKI Systems

43. Wrap-Up and Comments
Thank you for attending the SCATT Orientation Course!
As with any training, if you don’t use SCATT and its applications regularly you may forget some things. Don’t hesitate to contact me for help:
Milan Peich
L3 / MKI Systems Dept
(QinetiQ North America Subcontract)
24 Center Street, Stafford, VA