Download presentation
Presentation is loading. Please wait.
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
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.