Data Item Description.doc

Data Item Description

1.

Title – Optimization Plan

2. Identification No - 0001

3.

Description and Purpose

The Optimization Plan shall describe the contractor’s management organization, to include inter-relationships between the prime contractor, major subcontractors, and the contracting activity.

The Optimization Plan shall provide details of the specific techniques, tasks, and procedures to be used for monitoring contractor management, technical performance, configuration control, data management, risk management production, and cost control. The Optimization Plan will provide the contracting activity with a basis for reviewing and evaluating performance, and for determining contractual compliance.

4. Approval Date

5.

Office of Primary Responsibility tsa

6. DDC Required

7.

Application and Inter-relationship

This DID shall be the basis for the contractor’s management approach to program technical, schedule, and cost control.

The Optimization Plan shall be consistent with data products generated for the direction, coordination, and control of systems engineering, interface management, configuration management, quality assurance, risk management and production management.

8. Approval Limitation

9.

References

10.

PREPARATION INSTRUCTIONS

10.1

GENERAL

The Optimization Plan shall describe the contractor’s organization, assignment of duties and responsibilities, data management structure and procedures, and resource plan for conduct of contractually-imposed tasks.

10.2

FORMAT

Contractor format is acceptable. The contractor shall deliver the Optimization Plan in paper copy and electronic format (e.g., Microsoft Office suite of products) on CD-ROM, or e-mail. The Optimization Plan shall be delivered without restrictive legends and software that would limit the TSA’s ability to copy, reproduce, or modify the report using the electronic version.

10.3

CONTENT

The contractor shall develop the Optimization Plan addressing the items listed below, at minimum:

10.3.1 Introduction - This section shall be divided into the following two subsections;

· Purpose. This paragraph shall describe the purpose of the Optimization Plan in terms of its relationship to the management of the project, and performing the contractor tasks outlined in the SOW.

· Scope. This section shall contain programmatic and technical background on the system; an overview of the contractor’s approach to program technical, schedule, and cost control; authority of the program manager; the relationship of the Optimization Plan to other programmatic policies, procedures, and planning documents; and methods of incorporating changes into the Optimization Plan.

10.3.2 Project Management - This section shall provide information on the contractor’s management organization, internal management policies and procedures, an overall integrated contractor Project Schedule, relationships with TSA personnel and agencies, and roles and responsibilities of management entities within the organization. The section shall include the following subsections;

· Management Organization. Present company organizational charts and sufficient supplemental narratives to fully describe all organizational levels, plans and activities. This chart shall be hierarchical in nature and should clearly delineate all major area responsibilities and management positions. Provide a chart of the project organization to be used in performance of the contractor. Provide a narrative describing how the contractor shall fully integrate the management of all elements of the project. Identify key technical and management personnel who will be assigned to the project.

· Roles and Responsibilities. Discuss the authority of all responsible management positions identified by the organizational description. This description shall include the role of the project manager to direct, control, and commit resources to adequately fulfill their responsibilities.

· Policies and Procedures. Describe internal policies and procedures to be used in managing the contract.

· Relationships. Describe the working relationships the contractor will establish with the TSA and any subcontractor supporting the procurement of the system.

10.3.3 Management Systems - Describe the use, characteristics, and function of any automated or manual management systems to be employed in this contract, including, as a minimum, schedule management systems; resource allocation systems; and data management systems. The section shall include the following subsections;

· Schedule Management. Provide a detailed description of how the contractor will implement a fully integrated, defined, planning and control system. The description shall include discussion of inter-relationship of tasks, and tracking criticality of tasks. If subcontractors are used, similar information shall be presented, and shall include a discussion on how contractor and subcontractor schedules shall be integrated and updated.

· Resource Allocation. Provide a detailed description of how the contractor will allocate resources to meet the delivery requirements of the project. Discuss any resource allocation tools used for this purpose.

· Data Management. Describe the organization, procedures, and tools to be used to ensure that all data deliverables required by the contractor are made in a timely manner. Identify the individual responsible for integrating and maintaining the total data management effort. This effort shall involve monitoring, reporting, status accounting, and cross-matrixing (e.g., TSA change requirements versus implemented changes) of all changes to, additions of, or deletions of CDRL contents. The contractor’s procedures for controlling the generation, receipt, approval, storage, and delivery of subcontractor data, as well as its inclusion in status accounting, shall also be described.

10.3.4 Reviews and Reporting - Describe plans for all formal and informal reviews and reporting to the TSA.

10.3.5 Safety and Security - Describe the approach to provide safety and security during the development and test of the system.

10.3.6 Resources - This section shall provide a list of all company resources, personnel, and equipment available for use on the project, and a resource-loading chart showing planned resource utilization.

10.3.7 Facilities - Describe contractor and major subcontractor facilities that will be used, and the activities that will take place at each facility. Include manufacturing and testing facilities in this discussion.

10.3.8 Technical Performance Measurement - Describe the plan for monitoring the technical performance of the contractor and of related subcontractors under the contractor’s control.

DATA ITEM DESCRIPTION

IDENTIFICATION NO - 0002PRIVATE

PRIVATE

3. DESCRIPTION/PURPOSE

3.1 Provides a methodology for identifying and mitigation cost, schedule, and technical risks associated with the proposed system 4.

APPROVAL DATE

5. OFFICE OF PRIMARY RESPONSIBILITY

TSL-200

6. DDC REQUIRED

7.

APPLICATION/INTERRELATIONSHIP

8.

APPROVAL LIMITATION

9. REFERENCES

PRIVATE

PREPARATION INSTRUCTIONS

10.1 GENERAL. The purpose of the Risk Identification and Mitigation Plan shall be for the Contractor to identify the cost, schedule, and technical risks associated their proposed system, and to identify a mitigation plan(s) for each that significantly reduces, or eliminates, the likelihood or consequences of each risk.

10.2 FORMAT. The Risk Identification and Mitigation Plan shall be developed using MS Office products (e.g. MS PowerPoint, MS Excel, MS Office). The Contractor shall deliver the PPR Presentation in paper copy and Government approved electronic format (e.g., Microsoft Windows) on 3.5-inch diskette or CD-ROM. The PPR Presentation materials shall be delivered without restrictive legends and software that would limit the Government’s ability to copy/reproduce and edit/modify the PPR Presentation materials using the electronic version.

10.3 CONTENT. The Risk Identification and Mitigation Plan shall contain, as a minimum, the following;

a. Title Page - PPR Presentation Title Page; labeled with “Risk Identification and Mitigation Plan”, the project name, the Contractor’s company name, and the date.

b. Risk Identification and Mitigation Table – This table shall be presented in the following format;

Type C&L

Level of Risk Mitigation

Description of risk 1

Step(s) that will be taken to reduce or eliminate risk 1

Description of risk 2

Step(s) that will be taken to reduce or eliminate risk 2

Where, Risk Type shall be identified as “C” – Cost, “S” – Schedule, or “T” – Technical

C&L (Consequence and Likelihood) and Level of Risk shall be determined using the following;

1) First, determine the Likelihood of the risk occurring;

Approach and Process

2) Second, determine the Consequence of the risk if it did occur;

3) Finally, determine the Level of Risk;

High

Medium

Consequence

DATA ITEM DESCRIPTION

IDENTIFICATION NO (S)PRIVATE

- 0003

PRIVATE

3.

DESCRIPTION/PURPOSE

3.1 The Work Breakdown Structure (WBS) is the complete work breakdown structure for the contract.

3.2 The WBS shall provide the information on the projected, actual, and current status of the contract elements for which they are responsible 4.

APPROVAL DATE

5.

OFFICE OF PRIMARY RESPONSIBILITY TSL-200

6.

DDC REQUIRED

7.

APPLICATION/INTERRELATIONSHIP

8.

9. REFERENCES

PREPARATION INSTRUCTIONS

10.1 The Contractor shall establish, maintain, and use in the performance of this contract, a WBS system to plan and control costs and schedule, to measure performance (value of completed tasks), and to provide the data base for reporting reliable contract cost and schedule status to the Contracting Officer. The Government will review, evaluate, and approve the WBS system the Contractor will use in the performance of this contract. The Contractor shall deliver the WBS in paper copy and Government approved electronic format (e.g., Microsoft Windows/Office suite of products, etc.) on 3.5-inch diskette or CD -ROM. The WBS shall be delivered without restrictive legends and software that would limit the Government’s ability to copy/reproduce and edit/modify the List using the electronic version.

10.2 The WBS shall include all the contract elements (i.e., program management, system engineering, hardware/software (HW/SW) design software – development and productions, test and evaluation, documentation, and logistics) which are the responsibility of the Contractor. Through the WBS, the Contractor shall document work as resources are allocated and expended.

10.2.1 The WBS system shall include all the program management activities (business and administrative planning, organizing, directing, coordinating, controlling, and approval actions) designed to accomplish overall program objectives. All activities required to ensure that all cost, schedule, and performance objectives are met shall be included. Risk and requirements management activities shall also be included.

10.2.2 The WBS system shall include all systems engineering activities (analysis, design, integration, supportability, maintainability, reliability engineering, quality assurance, configuration management, and information security) associated with directing and controlling a totally integrated engineering effort.

10.2.3 The WBS system shall include all activities required to design and develop hardware and software configuration items at the contractor's facility, and the resulting integration, testing, assembly, checkout, and production. The hardware design and development items include; all activities associated with detailed design, fabrication, assembly and checkout of all hardware configuration items (HWCIs) of the initial unit(s). The software design and development items include; all activities associated with the detailed design, prototyping, development and unit-level checkout of all computer software configuration items (CSCIs). A CSCI is an aggregation of software, or any of its discrete portions, which satisfies an end use function and has been designated for configuration management. The HW/SW integration, assembly, test and checkout include all the activities associated with development site integration, assembly, and checkout of hardware, software and telecommunications components. Included are interface materials and parts required for the in-plant integration and assembly into the system within a suppliers’ facilities, and all materials and parts or other interfacing equipment furnished by the integrating agency or contractor. Production Engineering activities include all activities involved in taking the development system to production. This includes developing and maintaining production process documentation. Production activities include all activities associated with full-scale production necessary to fulfill contract quantity requirements, including procurement of COTS or NDI. IT includes all activities related to contractor-conducted testing performed on each end item before it leaves the factory to verify that the end item conforms to applicable specifications, and is free from manufacturing defects. The WBS includes any non-recurring production start-up costs associated with the production of the solution such as facility expansion or construction, retooling or production equipment acquisition or modification, etc.

10.2.4 The WBS shall include all test and evaluation activities necessary to verify and validate that the system meets specifications, satisfies requirements and is operationally suitable and effective. This includes contractor and in-house activities associated with this effort, e.g., software validation and verification. All support activities (e.g. technical assistance, maintenance, labor, material, support elements and testing spares, etc.) required during this phase of testing are included. The Contractor's WBS shall also include all support activities (e.g. technical assistance, maintenance, labor, material, support elements and testing spares, etc.) required during this phase of testing.

10.2.5 The WBS shall include all documentation activities associated with production, delivery and internal review of contractor documentation deliverables. Included are managing, coordinating, editing, scheduling, auditing and assembly of the documents and review packages necessary to the functioning of the program. It includes acquiring, writing, assembling, reproduction, packaging and shipping the data. The WBS shall also include reproducing and shipping the contractor deliverables.

10.2.6 The WBS shall include all logistics activities associated with the acquisition of test and measurement equipment, support and handling equipment, support facilities, initial spares and repair parts and the training required to support and maintain the system or portions of the system through the complete delivery of the system.

10.3 The Contractor shall likewise require that subcontractor(s) supporting the program establish, maintain, and use a system for reporting reliable cost and schedule status to the Contractor. All subcontractor(s) required cost and schedule information shall be provided to the Government on request.

10.4 If the Contractor uses a cost/schedule control system for this contract that has been previously accepted by the Government, that system may be used to satisfy the requirements in Section 10.1 above.

10.5 The Contractor shall use the WBS as the primary framework for contract planning, budgeting, and reporting of costs and schedules status to the Government.

10.5.1 The Contractor shall develop the WBS that contains a minimum of following five (5) levels

a) Level 1 – Project Name – The name used by the Contractor to refer to this project.

b) Level 2 – Phase – The Development Phase name.

c) Level 3 – Functional Area – The name of the functional area.

d) Level 4 – Functional Area Task

e) Level 5 – Functional Area Subtask

DATA ITEM DESCRIPTION

IDENTIFICATION NO - 0004PRIVATE

PRIVATE

3.

DESCRIPTION/PURPOSE

3.1 The Project Schedule shall show the flow of work necessary to accomplish major program objectives and deliverables of the acquisition contract.

3.2 The Project Schedule shows the dependency of the events and activities, and to determine the longest or most critical path of these dependencies from start to program completion.

3.3 The Project Schedule shall be used to assure planning by the contractor has been done, and is in sufficient detail to evaluate total program cost, schedule, technical progress, and re-plans or alternate courses of accomplishing work; and to pretest schedule change decisions prior to implementation to determine affect on future events.

4.

APPROVAL DATE

5.

OFFICE OF PRIMARY RESPONSIBILITY TSL-200

6.

DDC REQUIRED

7.

APPLICATION/INTERRELATIONSHIP

7.1. This DID contains the format and content preparation instructions for the data product generated by the specific and discrete task requirement for this data included in the contract

7.2 This DID is applicable to all work task planning and shall reflect the WBS; and shall be traceable to the cost/schedule control baseline; and the master production schedules, and the contract data delivery schedules 8.

9.REFERENCES

PREPARATION INSTRUCTIONS

10.1 CONTRACT. This data item is generated by the contract that contains a specific and discrete work task to develop this data product. This data item shall also be referred to as the Contractor Project Schedule.

10.2 FORMAT. The Project Schedule shall be a graphic representation of the time-phased work relationships displayed in logic flow format. All networks (hand-drawn or automated) shall not exceed 4 feet by 8 feet in size. Project Schedule shall be submitted in hardcopy and Government approved electronic format (e.g., Microsoft Windows/Office suite of products, e.g., MS Project) on 3.5-inch diskette or CD-ROM. The Project Schedule shall be delivered without restrictive legends and software that would limit the Government’s ability to copy/reproduce and edit/modify the Project Schedule the electronic version.

10.2.1 Tabular Reports – Tabular reports generated from network data shall include the following:

10.2.1.1 Duration Changes – This report shall document all activities where the activity duration has changed by more than 2 weeks during the reporting period. This report shall list the activity, amount of change, and reason for change. The contractor may group similar changes as long as the reasons for the changes are clearly documented.

10.3 The Project Schedule shall be hardware and software oriented as opposed to being CDRL and Level of Effort (LOE) oriented. Only those CDRLs and LOE activities that are critical or required prior to testing, IOC or ORD shall be shown. The inclusion of any CDRL or LOE activities shall be mutually agreed to by the contractor and the Government.

10.4 The Project Schedule shall contain status data sufficient to derive schedule variances.

10.4.1 These dates will be defined in the Project Schedule as the baseline schedule start date and the baseline schedule finish date. These dates shall only be adjusted through contractual direction and shall provide the original schedule dates for the activities and milestone events.

10.4.2 Completed activities shall be statused by recording actual start and completion dates.

10.4.3 In-progress activities shall be statused by recording actual start dates. In the event the activity started late in relation to the schedule baseline date, the days remaining to complete the activity shall be calculated from the actual start date with a new completion date recorded and identified as a “early finish’ date. Activity durations remaining shall also be assessed with their completion dates adjusted accordingly.

10.4.4 Imposed dates that directly affect the calculated dates in the schedule shall be used only on key contractual milestones, terminal activities, and other activities as appropriate, and shall be approved by the Government prior to being used in the Project Schedule.

a. Key contractual milestones in this instance shall be defined as activities defined in the contract.

b. Imposed dates in this instance shall be defined as any dates that are manually introduced into a schedule that override calculated dates. Imposed dates shall be kept to a minimum to avoid adverse effects on status date calculations, or other calculations required to identify the longest, or most critical path.

10.4.5 No more than 10 percent of the activities in the network shall be start or end activities. Start activities are defined as activities with no predecessor activity or event. End activities are defined as activities with no successor activity or event. Activity “A” - “B” is a graphic example of a start activity and activity “B” – “C” is a graphic example of an end activity.

APPENDIX 1.

SCHEDULE GUIDANCE

The following instructions shall serve as general contractual requirements for the preparation and maintenance of the contractor-provided Project Schedule. Listed in the following subparagraphs are general tenets that the Government believes must be followed in providing a workable and useful Project Schedule. Examples are provided for illustrative purposes only. The general tenets are as follows:

· The contractor should avoid excessive detail in developing the Project Schedule. Minute task details are not required in the Project Schedule product although the contractor should spend time, up-front to develop the activities and their interrelationships to accurately reflect tasks at the manageable level of detail. An example of excessive detail would be the inclusion of all CDRL activities in the Project Schedule. Only CDRLs that directly affect work tasks, such as test plans, should be included. Another example is equipment deliveries. The Government assumes that equipment deliveries are being tracked in production planning therefore; an activity such as “Equipment Staging” should be used in the Project Schedule rather than separate activities for each individual piece of equipment. In the event that all equipment does not arrive as scheduled, the completion of the activity would be moved out to coincide with the planned delivery of the last piece of equipment. A brief description of the problem shall be included in the appropriate section of the program status report.

· The Project Schedule should provide an accurate picture of the potential problems through the calculation of total program float. For example, if a problem exists, such as software development that will significantly impact the completion of a major activity, e.g., Initial Operational Capability (IOC), then the Project Schedule should reflect the problem well in advance of its occurrence. A brief description of the problem shall be included in the appropriate section of the program status report.

· If the Project Schedule fails to accurately forecast major problem areas, the activities or their interrelationships, or both, may not have been properly defined. Some activities, outside the contractor’s control, can impact contractor activities. These activities and their interrelationships, if crucial to program success, must be identified in the Project Schedule to provide a workable tool that can forecast potential problems.

DATA ITEM DESCRIPTION

IDENTIFICATION NO (S) – 000\5PRIVATE

PRIVATE

3.

DESCRIPTION/PURPOSE

3.1 The Statement of Work shall show the flow of work necessary to accomplish major program objectives and deliverables of the acquisition contract.

4.

APPROVAL DATE

DDC REQUIRED

7.

APPLICATION/INTERRELATIONSHIPO

8.

9.REFERENCES

10.1 GENERAL - The SOW shall describe the Offeror’s assumptions and constraints, and the programmatic requirements including deliverables, meetings and reviews, requirements management, standards compliance, quality assurance, configuration management, system interfaces, system components, test and evaluation, manuals, training, system installation, maintenance support, and security.

10.2 FORMAT - Contractor format is acceptable. The contractor shall deliver the SOW in paper copy and electronic format (e.g., Microsoft Office suite of products) on CD-ROM, or e-mail. The SOW shall be delivered without restrictive legends and software that would limit the TSA’s ability to copy, reproduce, or modify the report using the electronic version.

10.3 CONTENT - The Offeror shall develop the SOW addressing the items listed below, at minimum:

10.3.1 INTRODUCTION - This section shall be divided into the following subsections

10.3.1.1 Scope - Offeror shall provide a brief statement of what the statement of work covers e.g. design, manufacture, test, installation.

10.3.1.1 Background - Offeror shall provide background information on their development effort and the present state of their equipment.

10.3.1.2 Objectives - The Offeror shall state concisely the objective(s) this white paper addresses

10.3.1.3 Assumptions - Offeror shall describe the assumptions used in developing this SOW.

10.3.1.4 Constraints - Offeror shall describe constraints such as resources and design requirements.

10.3.2 APPLICABLE DOCUMENTS - Offeror shall identify by title, description, and version all documents referenced in this SOW.

10.3.3 REQUIREMENTS - Offeror shall describe in general terms the specific supplies and services that will be delivered, and describe what tasks need to be performed for each deliverable, and how they will be performed. This section shall be divied into the following subjections:

10.3.3.1 Program Management - Offeror shall describe what will be necessary to efficiently and effectively manage and execute all requirements, how the program will be controlled, and how data will be managed. This Program Management section shall also include:

· Activities planned,

· Timeframe for completion, and

· Resources required.

10.3.3.2 Work Breakdown Structure - Offeror shall provide a Work Breakdown Structure (WBS) and relate each WBS element to a Section number in this document. This section can reference the WBS (DID 0003).

10.3.3.3 Deliverables - Offeror shall identify all deliverables, including delivery dates. At a minimum, the following deliverables shall be included:

· Program Management Plan

· Compliance Matrix – Maintained and updated

· Project Schedule – Maintained and updated

· Master Test Plan

· Test Procedures and reports

· User Manual

· Training Materials

· Design review materials

· Technical data package for testing at TSA Systems Integration Facility (TSIF)

10.3.3.4 Meetings and Reviews - Offeror shall describe meetings and reviews conducted during the course of the program. At a minimum, required meetings shall be:

· Post award conference

· Monthly status meetings

· Preliminary design review

· Critical design review

· TSIF test readiness review

· Final testing review

10.3.3.5 Requirements Management - Offeror shall describe how the program requirements will be documented and how traceability of those requirements will be maintained.

10.3.3.6 Standards Compliance - Offeror shall define regulatory, safety, and other standards the SG/FSSS will meet after completion of the proposed work.

10.3.3.7 Quality Assurance - Offeror shall describe how the quality of all deliverables under this program will be controlled and assured.

10.3.3.8 Configuration Management - Offeror shall describe the process by which they will manage and control of changes to hardware, software, and data. At a minimum, the configuration management section shall account for a Physical Configuration Audit at the end of the period of performance.

10.3.3.9 Interfaces - Offeror shall describe all user and external interfaces for the equipment.

10.3.3.10 Major System Components -Offeror shall identify and describe deliverable major system components including their functional, electrical, and physical characteristic e.g. scanner, operator viewing station(s), printers, and network requirements.

10.3.3.11 Operational Hardening Process - Offeror shall describe the steps required to improve the operational aspects of their system in order to meet the requirements of the SOO.

10.3.3.12 Test and Evaluation (T&E) - Offeror shall describe the test and evaluation that will be performed at the factory through delivery, and testing efforts at the TSA Systems Integration Facility. Test plans, procedures and reports that will be provided shall also be identified.

10.3.3.13 Manuals - Offeror shall identify all deliverable manuals and data that will be provided.

10.3.3.14 Training - Offeror shall describe their plan for user training at the TSA Systems Integration Facility.

10.3.3.15 Installation - Offeror shall define all installation requirements to support installation of their equipment at the TSA Systems Integration Facility.

10.3.3.16 Maintenance Support - Offeror shall describe how they plan to provide preventative and corrective maintenance support at the TSA Systems Integration Facility.

10.3.3.17 Security - Offeror shall describe their process to safeguard security of documents developed and shall include the following:

Any documents containing Sensitive Security Information (SSI) as defined in 49 Code of Federal Regulations (CFR) Parts 15 and 1520 shall contain the following statement:

“WARNING: This record contains Sensitive Security Information that is controlled under 49 CFR Parts 15 and 1520. No part of this record may be disclosed to persons without a “need to know”, as defined in 49 CFR Parts 15 and 1520, except with the written permission of the Administrator of the Transportation Security Administration or the Secretary of Transportation. Unauthorized release may result in civil penalty or other action. For U.S. Government agencies, public disclosure is governed by 5 U.S.C. 552 and 49 CFR Parts 15 and 1520.”

PAGE