C2SES_III_Sec_M_Draft.docx

EVALUATION PROCESS

M1.0. BASIS FOR AWARD

The Government contemplates award of a single award IDIQ contract resulting from this solicitation. Utilizing a Risk, Past Performance, Price Tradeoff with technical acceptance (Pass/Fail) Source Selection Process, the evaluation will be conducted in accordance with the, Federal Acquisition Regulation (FAR) 15.3, Department of Defense Federal Acquisition Regulation Supplement (DFARS) 215.3, DoD Source Selection Procedures effective 1 July 2011, Air Force Federal Acquisition regulation supplement (AFFARS) 5315, Mandatory Procedure (MP) 5315.3, AFICA MP, and this solicitation. Award will be made to the offeror who is deemed responsible in accordance with Federal Acquisition Regulation (FAR) Part 9 (including, if appropriate under L6.4.3, a plan that effectively mitigates any OCI), conforms to the solicitation requirements (such as terms and conditions, representations and certifications), meets all technical requirements, and presents the best value to the Government, with a tradeoff possible between Technical Risk, Past Performance and Price. Technical Risk and Past Performance are equal of importance. When combined, Technical Risk and Past Performance are more important than Cost/Price. Failure to comply with the terms and conditions of the solicitation may result in the offeror being considered unawardable. Any exceptions to the solicitation’s terms and conditions must be fully explained and justified. The Government reserves the right not to award a contract, depending on the quality of proposal(s) submitted and the availability of funds.

M.1.1. AWARD WITHOUT DISCUSSIONS

The Government reserves the right to award without discussions IAW FAR 52.215-1. Therefore, offerors are advised to submit proposals that are fully and clearly acceptable without additional information. If award will be made without conducting discussions, offerors may only be given the opportunity to clarify certain aspects of proposals (e.g., the relevance of an offeror’s past performance information and adverse past performance information to which the offeror has not previously had an opportunity to respond) or to resolve minor or clerical errors. Adverse past performance includes past performance information that supports a less than satisfactory rating on any evaluation element or any unfavorable comments received from sources without a formal rating system.

M1.2. COMPETITIVE RANGE/DISCUSSIONS

The Government reserves the right to open and conduct discussions if it deems them to be necessary. Discussions will be held only with those offerors determined to be in the competitive range. The Contracting Officer may establish a competitive range comprised of the most highly rated proposals based on the rating of each offeror’s price proposal against the evaluation criteria. The competitive range may be further reduced for purposes of efficiency pursuant to FAR 15.306(c)(2). If the Government elects to open discussions, it has sole discretion as to whether an offeror is in the competitive range, and may include proposals rated “Unacceptable” under the Technical factor, “High” under Technical Risk, and/or “No Confidence” under the Past Performance factor. Offerors whose proposals are not included in the competitive range will be notified as soon as practicable.

Discussions will include issuance of evaluation notices. An offeror initially included in the competitive range may be eliminated from consideration for award during discussions. At the conclusion of discussions, each offeror still within the competitive range shall be given an opportunity to submit a Final Proposal Revision (FPR). The offeror’s responses to Evaluation Notices (ENs) and the Final Proposal Revision (FPR) will be considered in making the source selection decision. Only offerors deemed “Acceptable” in all Technical subfactors and a “Low” or “Moderate” risk rating for all technical subfactors are eligible for award.

M1.3. AWARD

To arrive at a source selection decision, the Government will evaluate all factors, subfactors (described below), and proposed price. While the Government will strive for maximum objectivity, the source selection process, by its nature, is subjective. The Government may award to a higher priced offeror, where the decision is consistent with the evaluation factors and the Source Selection Authority (SSA) reasonably determines that the lower technical risk and/or higher past performance rating of the higher priced offeror outweighs the price difference. The Government may also award to a lower priced offeror where the decision is consistent with the evaluation factors.

M2.0. EVALUATION FACTORS AND SUBFACTORS

The Government will evaluate proposals based upon the following factors:

Factor 1: Technical Capability and Technical Risk – Technical is broken down into the following subfactors:

SUBFACTOR 1 - Software Engineering Services SUBFACTOR 2 - System Engineering SUBFACTOR 3 - Program Management SUBFACTOR 4 - Small Business Participation Commitment Document (SBPCD) Factor 2: Past Performance Factor 3: Cost/Price

The Technical Capability Factor will be evaluated on an acceptable/unacceptable basis according to the criteria described in section M3.1 and Table 1.0. Technical Risk will be evaluated using a separate risk rating Table 2.0. Within the Past Performance factor, recent and relevant performance will be assessed and quality of the performance will also be evaluated for an overall confidence assessment rating in Table 3.0. Price will be evaluated as follows: For the CPIF Task Order 0001, the Government will evaluate for fair and reasonableness, cost realism, and unbalanced pricing. For the future FFP Task Orders, the government will evaluate the fully burdened labor categories for fair and reasonableness. Proposals with any unacceptable ratings for any of the subfactors are not eligible for award.

M3.0. EVALUATION PROCEDURES FOR EACH FACTOR

M3.1. Factor 1: Technical Capability and Technical Risk Evaluation Procedures. The Government technical evaluation team shall evaluate the offerors’ technical proposals on an acceptable/unacceptable basis by assigning ratings of “Acceptable” or “Unacceptable,” respectively. A separate risk rating (Low, Moderate, or High) will be assigned to each technical subfactor based on the assessment of technical risk, which is manifested by the identification of weakness(es), considers potential for disruption of schedule, increased costs, degradation of performance, the need for increased Government oversight, or the likelihood of unsuccessful contract performance.

M3.1.1. Technical: The offeror’s proposal shall address each of the subfactors below. Detailed instructions are included in the proposal preparation instructions in Section L of this solicitation. During evaluation of each proposal, the Government will assign each subfactor a rating as shown in Table 1. A rating of “Unacceptable” in one or more technical subfactors will constitute an overall rating of “Unacceptable” for the technical evaluation. Offerors must pass all of the thresholds listed under each subfactor to receive an “Acceptable” rating for that subfactor.

M3.1.2. Technical Approach: The Technical evaluation will use the ratings and descriptions outlined in Table 1 below:

TABLE 1.0 – TECHNICAL RATINGS

M3.1.3 Technical Risk: Technical Risk will be given a separate rating. The risk associated with each technical factor shall be evaluated. The technical risk assessment will focus on the risks associated with each offeror's proposed approach, which includes but is not limited to, the labor hours and categories in the cost/price model. Assessment will be made at the Technical sub-factor/element level and includes potential for disruption of schedule, increased cost, degradation of performance, the need for increased Government oversight, and the likelihood of unsuccessful contract performance. Evaluators will judge each proposal's probability of success and the impact of failure. For any identified risk, the evaluation will address the offeror's plan for mitigating the risk, and why their approach is or is not manageable. If a combination of significant weaknesses leads to unacceptably high proposal risk, this will be considered a deficiency. For each technical subfactor, the Government will assign a technical risk rating shown in Table 2 below.

TABLE 2.0 – TECHNICAL RISK RATINGS

M3.1.4. The proposals shall be evaluated against the following subfactors:

M3.1.4.1. SUBFACTOR 1 - Software Engineering Services The proposal demonstrates the offeror's ability to provide sufficient processes, procedures, approaches, and staffing to support each of the C2SES III requirements. The Government shall evaluate the proposals on methodology to:

M3.1.4.1.1. The offeror’s software engineering processes ensure Government requirements are met to include what software lifecycle processes will be followed to maintain software supporting the USSTRATCOM mission sets defined and the ability/flexibility to support agile/rapid development, short duration release cycles, and creation of applicable web services.

Standard: The subfactor will be deemed technically acceptable if the offeror clearly demonstrates a lifecycle process that identifies requirements, design, coding, test, and implementation/integration impacts that could compromise USSTRATCOM’s ability to meet Government requirements. The proposal should include how the offeror’s software life cycle management approach aligns with the Government SEMP, emphasizing reviews, documentation, and deliverables. This includes the ability/flexibility to support agile/rapid development, short duration release cycles, and applicable web services. The offeror’s processes will demonstrate the capability to manage multiple releases which are integral to each other. The offer’s processes will demonstrate developing applications using an n-tier architecture, while utilizing x86 standard hardware and system software (UML and Object Oriented Design). Demonstrate legacy language design and programming (i.e. ADA, Fortran and C++)

M3.1.4.1.2. The offeror’s integration strategy to identify COTS, GOTS, and platform impacts to the system and associated software architectures; ensure successful implementation of software quality (requirements decomposition, minimize implementation errors and produce no implementation failures). The offeror’s approach to identify the technical impacts and risks with the design, coding, test, security adherence, and implementation/integration to the defined enterprise architecture. Describe the tools and techniques that will be used to coordinate all internal and external activities and dependencies to support early identification of issues in the Government defined environments.

Standard: The subfactor will be deemed technically acceptable if the proposal clearly conveys an understanding of the system, software, targeted environments, and the impacts and external dependencies and relationships required to identify external COTS, GOTS, and platform impacts. This includes processes to identify technical impacts and risks, coordination of activities and dependencies to support successful implementation that minimize errors and no failures.

M3.1.4.1.3. The offeror’s processes ensure the operational readiness of the tasked systems. The proposal includes specific mechanisms to ensure the quality, early identification of errors to minimize defects and ensure operational availability of software delivered. The offeror’s approach for on-call responses ensures no degradation in operational readiness.

Standard: The subfactor will be deemed technically acceptable if the processes clearly demonstrate an industry standard system lifecycle processes and test processes that enable early detection and identification of errors, minimize defects over the lifecycle and ensure the operational availability and support of the software to the Government. Offeror will also demonstrate the process ensures no lapse in security, COTS, or GOTS products affect system operational readiness. The implementation of the demonstrated processes has to ensure operational readiness of the tasked systems.

M3.1.4.1.4. The offeror’s processes accurately document and track changes during the release cycles and ensure proper documentation of modifications between major releases and ensure no information or documentation is lost, updates are only required when necessary.

Standard: The subfactor will be deemed technically acceptable if the proposal clearly demonstrates how the offeror’s processes trace changes, provides appropriate in-sight and status throughout the lifecycle process; including documentation updates. The processes identify interface points and alignment with Government defined processes and tools.

M3.1.4.2. SUBFACTOR 2 - System Engineering The proposal demonstrates the offeror's ability to provide sufficient processes, procedures, approaches, and staffing to support each of the C2SES III requirements. The Government shall evaluate the proposals on methodology to:

M3.1.4.2.1. The offeror’s systems engineering processes techniques, and tools implement rigorous system engineering processes, software tools, techniques, and services/languages/libraries/code across the software life cycle common among the C2SES III systems/applications to ensure Government requirements are met. The proposal should include how the offeror’s management approach to the software lifecycle process aligns with the Government SEMP, emphasizing reviews, documentation, and deliverables.

Standard: The subfactor will be deemed technically acceptable if the offeror clearly demonstrates standard system engineering and management processes, tools, and techniques that align with the Government process for all C2SES III systems/applications identified and ensure that Government requirements are met.

M3.1.4.2.2. The offeror’s requirements processes trace requirements between Government System-Level requirements and the program software requirements. The offeror’s proposal includes processes to control and manage the software requirements baseline, tools and techniques employed, tracking stakeholder requests and deficiency reports. Descriptions of Government touch-points, accessibility/availability of tools and information, and mechanisms to ensure alignment and traceability to Government system requirements is clearly outlined.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates implementation of a requirements process to document, control, manage, and ensure traceability between Government system requirements and software requirements. Outline how the requirements processes align with program management, software and system engineering processes.

M3.1.4.2.3. The offeror’s systems engineering processes ensure software quality and contribute to/enhance the delivery of defect-free software. The offeror’s procedures employed during the software lifecycle process mitigate risk and contribute to optimal/efficient design solutions.

Standard: The subfactor will be deemed technically acceptable if the offeror’s software quality process supports all phases of the software lifecycle, identifies, mitigates and manages risk, minimizes software defects, and contributes to a more optimal/efficient design.

M3.1.4.2.4. The offeror’s approach describes the processes and techniques used to proactively plan and prepare for upgrades or changes to the operational environment, changes/upgrades to interfacing systems, and major requirements. The offeror’s proposal includes how system analyses and trade studies will be conducted to arrive at optimal design solutions.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates a system engineering process that proactively addresses the design, coding, test, and implementation/integration for upgrades or changes to the enterprise architecture which could impact the Government’s ability to meet mission requirements. It should include a process to conduct system analyses and trade studies to support optimal design and technical solutions.

M3.1.4.2.5. The offeror’s approach to identify the communication impacts from external programs to the design, coding, test, and implementation/integration to the defined enterprise architecture. The specific processes and techniques that will be used to proactively plan and prepare for upgrades or changes to the operational environment, changes/upgrades to interfacing systems, and major requirements identified by C2 functional managers. It should include a description of how system analyses and trade studies will be conducted to arrive at optimal design solutions, and drive cost efficiencies to reduce life-cycle costs.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates a software requirements traceability process during the design and testing phase. The offeror’s process must identify the communication impacts from external programs to the design, coding, test, and implementation/integration impacts to the enterprise architecture which could compromise the Government’s ability to meet Government requirements. The proposal includes a process that demonstrates a system analyses and trade studies process to support optimal design solutions, and deliver system information security documentation to ensure accreditation prior to implementation. The demonstrated processes have to ensure Government requirements will be met. The proposal clearly conveys an understanding of the system, software, targeted environments, and the impacts and external dependencies and relationships required to identify communication systems and platform impacts.

M3.1.4.2.6. The offeror’s requirements processes ensure tracking between Government System-Level requirements related to communication devices and the program software requirements. The offeror’s proposal includes how the offeror will control and manage the software baseline for communication interfaces, what tools and techniques will be employed, and how change requests related to communication devices will be tracked and managed. Descriptions of government touch-points, accessibility/availability of tools and information by the Government, and mechanisms to ensure alignment and traceability to system requirements is clearly outlined.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates implementation of a requirements process to document, control, manage, and ensure traceability between external system Interface Control Documents, Government system requirements and software requirements. The offeror’s proposal includes how the requirements processes align with program management processes, software and system engineering processes.

M3.1.4.2.7 The offeror ensures that software baselines are properly managed and controlled. Describe the configuration management (CM) processes and tools for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design, and operational information throughout its lifecycle.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates the application of DoD/industry standard processes to ensure complete control of baselines. Contractor CM procedures must include government integration/touch points that align with J864 C2 Mission Portfolio Configuration Management Plan processes. The offerror’s CM procedures must also include the ability/flexibility to support agile/rapid development, short duration release cycles, and applicable web services. The offeror’s processes will demonstrate the capability to manage multiple releases which are integral to each other.

M3.1.4.2.8. The offeror’s configuration management processes ensure all risks are identified and risk mitigation plans are actively implemented for moderate and high risks. Provide a description of the offeror’s risk management processes, including how risks will be identified, tracked, and mitigated. The offeror’s proposal includes a description of how the offerror will engage the Government in this process.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates a risk management process which includes risk identification and analysis of all risks. Planning, implementation, and monitoring of mitigation efforts must be accomplished for all risks identified as moderate or high.

M3.1.4.2.9. The offeror’s quality control processes minimize implementation errors and produce no integration failures. The offeror’s proposal includes a description of the overall approach, procedures, metric collection, and continuous process improvement methodologies to ensure software quality for delivered systems/applications.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates implementation of a quality assurance process to include procedures, metric collection, continuous improvement methodologies to include testing and document management which will minimize deliverable errors and ensure on time deliveries. QA procedures must include reporting methods to ensure that the Government maintains visibility into software quality information metrics and issues.

M3.1.4.2.10. The offeror’s quality assurance, security engineering, system administration, and database/database administration processes ensure all risks are identified to include those identified as low and those identified as moderate and high risks have risk mitigation plans which are actively used.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates a risk management process which includes risk identification and analysis of all risks. Planning, implementation, and monitoring of mitigation efforts must be accomplished for all risks identified as moderate or high.

M3.1.4.2.11. The offeror’s quality assurance processes ensure all key milestones and key milestone due dates are met. Describe how the offerror’s quality assurance processes will ensure/contribute to the timely delivery of all documentation and software for C2SES systems.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates implementation of a program management process that includes quality assurance and control tools and techniques to ensure on time accomplishment of key milestones requirements.

M3.1.4.2.12. The offeror’s security engineering processes minimize security findings and ensure on-time deliveries. Describe security engineering processes and/or mechanisms that ensure that security/information assurance is addressed throughout the software life cycle. Provide a description of the offeror’s security management approach and how it aligns with the Government SEMP, emphasizing reviews, documentation, and deliverables.

The offeror’s proposal includes a description of how these processes will be used to identify, resolve, or mitigate security vulnerabilities early in the process.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates security processes, tools and techniques across the software lifecycle that resolve or mitigate security findings.

M3.1.4.2.13. The offeror’s ensure contractor personnel have appropriate professional certifications and have sufficient number of personnel with required security clearances at the beginning of full performance.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates a process to identify billets which require professional certifications, to include DoD 8570 Certification, and ensure they are filled with qualified personnel. The offeror’s process must also identify minimum numbers of personnel required to meet contract requirements at start of full performance. The demonstrated processes shall ensure sufficient numbers of properly certified and cleared contractor personnel are employed at the beginning of full performance.

M3.1.4.2.14. The offeror’s system administration processes minimize impact to software and test activities and ensure on-time deliveries of software. The offeror’s system administration processes will demonstrate the capability to manage multiple simultaneous releases which are integral amongst each other.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates implementation of a process to document, control, manage, and sustain the software support and test environments to ensure alignment between Government system requirements and software requirements. This includes the ability/flexibility to support agile/rapid development, short duration release cycles, and applicable web services. The offeror demonstrated the ability to meet schedule variance requirements when multiple simultaneous efforts, some of which were integral with each other, were required. The offeror’s processes will demonstrate the capability to manage multiple releases which are integral to each other and ensure implementation errors are minimized and no implementation failures will occur.

M3.1.4.2.15. The offeror’s system administration processes identify what metrics will be used to measure system performance across all environments, including trend analysis.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrated processes included use of metrics to measure system performance, kept customer informed of performance status and timely notification of issues. In addition, metrics were presented using trends.

M3.1.4.2.16. The offeror’s database support processes minimize impact to software and test activities and ensure on-time deliveries of software. The offeror’s database support processes will demonstrate the capability to manage multiple simultaneous releases which are integral amongst each other.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates implementation of a database support process to document, control, manage, and ensure alignment between Government system requirements and software requirements. This includes the ability/flexibility to support agile/rapid development, short duration release cycles, and applicable web services. The offeror demonstrated the ability to meet schedule variance requirements when multiple simultaneous efforts, some of which were integral with each other, were required. The offeror’s database support processes will demonstrate the capability to manage multiple releases which are integral to each other and ensure implementation errors are minimized and no implementation failures will occur

M3.1.4.2.17. The offeror’s database and data administration processes identify metrics used to tune and measure database performance including trend analysis.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrated processes includes use of metrics to measure database performance and keep customers informed of performance status and timely notification of issues. In addition, metrics were presented using trends.

M3.1.4.2.18. The offeror’s test processes ensure that Government requirements are satisfied and the delivery of defects to the operational environment are minimized. The offeror describes the overall test and verification methodology/approach for all phases and how test processes support/align with the C2 Test Process Description document. The offeror’s proposal includes a description of tools and methods to ensure integration with existing capabilities/infrastructure and also demonstrate performance requirements are met or in the absence of a stated performance requirement, performance is not significantly degraded as a result of software maintenance activities.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates an industry standard test process to support all C2SES III system/applications and align with Government guidance. The demonstrated processes have to ensure proper integration, performance, and ensure implementation errors are minimized and no implementation failures will occur.

M3.1.4.2.19. The offeror’s test processes ensure that regression testing is satisfied. The offeror describes the regression testing methodology and approach for all software releases, and how regression test processes support/align with the C2 Test Process Description document.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates a process that incorporates the system engineering and software processes to identify regression testing required to support all C2SES III system/applications and align with Government Guidance. The demonstrated processes shall ensure implementation errors are minimized and no implementation failures will occur.

M3.1.4.2.20. The offeror’s test processes accurately capture and track identified issues during the test cycle to ensure problem resolution and proper documentation before software release. The offeror’s proposal includes what approach and process will be used to ensure tracking of issue and resolution with documentation updates.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates implementation of a defect review process to ensure problems are properly documented, managed, tracked through completion, and it aligns with the C2 Test Process Description document.

M3.1.4.2.21. The offeror’s test processes ensure all key test activities and deliverables align with the software and system engineering processes are delivered IAW established milestones.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates implementation of a test process that aligns with the system and software engineering processes and ensures on time accomplishment of key testing milestones.

M3.1.4.3. SUBFACTOR 3 - Program Management The proposal demonstrates the offeror's ability to provide sufficient processes, procedures, approaches, and staffing to support each of the C2SES III requirements. The Government shall evaluate the proposals on methodology to:

M3.1.4.3.1. The offeror’s program management approach shall recruit, hire, retain, and replace trained and qualified personnel with appropriate security clearances (e.g., Secret, Top Secret) to support mission requirements through life of the contract. The offeror includes a listing of key personnel (i.e., those filling key positions) and qualification summaries, as they relate to the proposed positions and provides a resume (required ONLY for key personnel, not all personnel). The qualification summary shall not exceed one page per person. Reference H-32, Key Contractor Personnel for additional details.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates a process that identifies mission essential billets (reference DFARS 252.237-7023) and ensures they are continually filled for the life of the contract with qualified personnel. The offeror’s process shall demonstrate ability for flexible staffing to accommodate manpower requirements for emergencies/contingencies, special projects, and personnel losses. The demonstrated processes ensures sufficient numbers of personnel are available to meet mission requirements. The offeror should also identify billets which require professional certifications, to include DoD 8570 Certification, and ensure they are filled with qualified personnel. The offeror’s approach should also identify minimum numbers of personnel required to meet contract requirements at start of full performance. The demonstrated approach ensures sufficient numbers of properly certified and cleared contractor personnel are employed at the beginning of full performance.

M3.1.4.3.2. The offeror will recruit, hire, retain, and replace trained and qualified personnel with appropriate security clearances (e.g., Secret, Top Secret) to support mission requirements through the life of the contract. The offeror describes what approach will be used to recruit, train, and retain personnel to accommodate varying staffing requirements over the life of the contract, including long-term, ongoing tasks, special efforts of lesser duration, and rapid replacement/addition of personnel in the event of emergencies/contingencies.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates a process that ensures billets are continually filled for the life of the contract with qualified personnel. The offeror’s process shall demonstrate ability for flexible staffing to accommodate manpower requirements for emergencies/contingencies, special projects, and personnel losses. The demonstrated processes ensures sufficient numbers of personnel are available to meet mission requirements. The offeror should also identify billets which require professional certifications, to include DoD 8570 Certification, and ensure they are filled with qualified personnel. The offeror’s approach should also identify minimum numbers of personnel required to meet contract requirements at start of full performance. The demonstrated approach ensures sufficient numbers of properly certified and cleared contractor personnel are employed at the beginning of full performance.

M3.1.4.3.3. The offeror will lead, manage, and control C2SES III efforts to include understanding of the C2 systems and missions, plus the agencies they support, as well as their systems/subsystems and capabilities, in order to assess, enhance, maintain, and sustain USSTRATCOM C2 systems. The offeror’s proposal includes how the contractor will support Government lead groups to include IPTs, management boards, and working groups identified by the Government.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates a program management plan to manage and control all facets required to support the C2SES III efforts and clearly conveys a management understanding of the system, software, targeted environments, the impacts, external dependencies, and relationships required to identify external COTS, GOTS, and platform impacts. The offeror’s proposal includes how any contractor identified board or process will support Government lead groups to include IPTs, management boards, and working groups identified by the Government. The proposal includes how the contractor will institute and maintain a process to ensure problems, issues, and action items are discussed with the Government, tracked through resolution, and provide timely status reporting.

M3.1.4.3.4. The offeror will provide unscheduled Technical Support. The offeror’s proposal includes how the offeror shall provide uninterrupted 24/7 support during a labor strike, surges, natural disasters, disruptive world events, terrorist attacks, government shutdowns and/or other emergencies.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates processes to ensure first responders are available with the required training and qualifications to meet the response times, and that personnel are available for 24/7 coverage to support mission requirements.

M3.1.4.3.5. The offeror will provide management of facilities, equipment, and material provided by the Government, at no additional cost to the Government.

Standard: The subfactor will be deemed technically acceptable if offeror demonstrates an understanding of the Government provided facilities, equipment, and materials, and identifies the process and methods for management of the Government provided facilities, equipment, and material.

M3.1.4.3.6. The offeror’s program management/systems management processes manage cumulative to date priorities and minimize schedule variances. The offeror’s proposal includes what approach will be used to keep the Government informed of priorities, schedule, performance status, notified timely of issues with contract performance, metrics to measure contract and system performance to include trend analysis, and provide the Government access to the metrics history for the contract. The offeror’s processes demonstrate the capability to manage multiple simultaneous task orders which are integral to each other.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates a system to track priorities and schedule indices to the contract budgets to effectively manage resources to meet requirements and avoid schedule slips. The offeror’s process demonstrates a method to keep the Government informed of cost, schedule, and performance metrics. The offeror demonstrates a process to inform the Government of issues forecasted to affect future cost, schedule, performance factors. The offeror’s processes demonstrate the capability to manage multiple simultaneous efforts which are integral to each other. The demonstrated processes ensures cumulative to date cost and schedule variances are minimized.

M3.1.4.3.7. The offeror provides an organizational structure that demonstrates effective lines of authority, communication, functional relationships, roles and responsibilities to include integration of teaming partners and subcontractors, and reach back capabilities to ensure successful mission accomplishment.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates an effective management approach for proactively meeting C2SES III requirements, being responsive to Government requests and resolving problems, and demonstrates an effective approach to manage teaming partners and/or subcontractor relationships. The offeror identifies key leaders to include Program Manager (PM), Deputy Program Manager and Facility Security Officer (FSO), etc.

M3.1.4.3.8. The offeror will ensure uninterrupted support and with no degradation of service for C2SES III requirements, implement a phase-in process that is comprehensive and realistic for assumption of full responsibility, and identifies transition risks and measures to mitigate them.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates an understanding of C2SES III mission requirements and provides a plan to ensure the offeror assumes responsibility from the incumbent with no degradation to service. The offeror demonstrates a plan to phase in support from the incumbent which ensures assumption of full responsibility of all support by start of full performance, identifies transition risks, and management procedures to mitigate transition risk prior and during the transition period.

M3.1.4.3.9. The offeror will execute a comprehensive approach for ramping up and obtaining/retaining personnel with the appropriate mix of qualifications/skill sets, IT certifications, and personnel security clearances from award to start of full performance. The offeror possesses, or acquire prior to award, a Facility Security Clearance equal to the highest billet clearance requirement.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates a comprehensive approach to ramping up during the transition period to assume full performance during the allotted time period. The approach must demonstrate the time phasing required for such tasks as systems engineering, program and system management, and sustainment. The offeror must demonstrate a comprehensive approach to the timing of key personnel arrival and the roles they will play to ensure a successful transition. The offeror will also demonstrate a plan to obtain the proper security clearances for personnel as they assume responsibility for positions, requiring security clearances, during the transition period. In addition the offeror must demonstrate a plan to identify billets which require professional certifications, to include DoD 8570 Certification, and ensure they are filled with qualified personnel upon assuming responsibility for the identified billets. Finally, the offeror must possess, or acquire prior to award, a Facility Security Clearance equal to the highest billet clearance requirement. The demonstrated transition approach has to ensure qualified (to include meeting certification and security clearance requirements) personnel are brought on to meet transition requirements and the offeror has the proper Facility Security Clearance (or can acquire prior to award).

M3.1.4.3.10. The offeror demonstrates an understanding of the activities and resources required to successfully transition personnel and workload requirements for continuity of mission support.

Standard: The subfactor will be deemed technically acceptable if the offeror demonstrates an understanding of the contract workload and resource requirements for the transition period.

M3.1.4.3.11. The offeror will aggressively mitigate transition risks and implement measures to ensure a successful transition. The offeror’s transition risk mitigation approach will identify resources required to support the transition, support early identification of transition risks, and show a logical set of steps within the resources identified to diminish realized risks that would prevent being fully capable to perform all contract requirements by contract full performance date.

Standard: The subfactor will be deemed technically acceptable if the offeror’s transition risk mitigation approach is a logical set of steps within the resources provided by the Government that is sufficient to diminish realized risks that would prevent being fully capable to perform all contract requirements by contract full performance date.

M3.1.4.4. SUBFACTOR 4 – Small Business Participation Commitment Document (SBPCD)

M3.1.4.4.1 The offeror specifically identified small business firms in the proposal and provided detailed explanations/documentation supporting the proposed small business participation.

M3.1.4.4.2 The offeror provided varifiable letters of commitment or agreements from small businesses included in their SBPCD.

M3.1.4.4.3 The offeror demonstrated its ability to assist, promote and utilize small business (SB), small disadvantaged business (SDB), women-owned small business (WOSB), Historically Underutilized Business Zone (HUBZone) small business, veteran-owned small business (VOSB) and/or service-disabled veteran-owned small business (SDVOSB).

M3.1.4.4.4 The offeror demonstrated how the offeror will maximize SB opportunities and use SB in meaningful work (e.g. mission critical, technology innovation) throughout the program.

M3.2. Factor 2: Past Performance Evaluation Procedures.

M3.2.1. Description of factor: The offeror's proposal shall address past performance in related contracts as it applies to the Technical subfactors in this section. The Past Performance Team will conduct a past performance review of each offeror and then make an overall assessment of the Government's confidence that the offeror will successfully perform this contract. In evaluating past performance, information may be obtained through the Past Performance Information Retrieval System (PPIRs), similar systems of other Government departments and agencies, questionnaires tailored to the circumstances of this acquisition, Defense Contract Management Agency (DCMA) channels, interviews with program managers and contracting officers and other sources known to the Government, including commercial sources. Offerors are to note that, in conducting this assessment, the Government reserves the right to use both data provided by each offeror and data obtained from other sources. Evaluation will also include the offeror’s compliance with and achievement in meeting subcontracting plan goals. Moreover, while the Government may review the offeror’s most recent and relevant past performance references, the Government will not evaluate more than five offeror provided references and three from each major subcontractor or teaming partner. The Government will evaluate the offeror’s performance record as indicated in Section L4. The Government will consider the relevancy and recency of the past performance, source of the past performance information (and may consider their grading history/specific program background context), context of the data, general trends in offeror’s performance, and the size and complexity of the past performance relative to this acquisition’s requirements. (NOTE: The The Government reserves the right to use both data provided by the Offeror as well as data the Government develops and obtains through other sources through past performance evaluation research. The Government also reserves the right to contact Contracting Officers and subcontractors from previous contracts.)

M3.2.2. Factor Assessment: The Government will evaluate past performance through an integrated analysis of those strengths and weaknesses the Government identifies in the offeror’s recent and relevant contract performance. The other aspect of the past performance evaluation is to determine how well the contractor performed on the contracts (i.e. quality of their prior performance). The Government will place more weight and consideration on more relevant past performance information when determining the overall confidence assessment. However, offerors with the same confidence rating will be treated equally. The rating for the past performance factor is the Government’s assessment of acceptability, based upon the Government’s evaluation of the offeror’s performance record, that the offeror will successfully perform the requirements of this acquisition as proposed. For the purposes of the Past Performance evaluation, the term “offeror” includes the prime offeror and/or team members and major subcontractors performing 10% or more of the effort. A single confidence assessment of the offeror’s past performance (which includes, if applicable, the extent of its subcontractors’ and teaming partners’ involvement) will be made. The Government is not bound by the offeror’s interpretation of relevance.

M3.2.2.1. Recency: In determining recency, the Government will only consider contracts with performance ending on or after 1 Oct 2013. Additionally, performance of less than one year from the date of the C2SES III past performance volume submission date will not be considered due to limited performance history of these efforts.

M3.2.2.2. Relevancy: The Government will perform an independent analysis in determining the relevancy of a contract based on the data provided and/or obtained. The determination of relevancy is contingent on an assessment of the scope, magnitude, and complexity of the efforts performed on the contract being reviewed to those of the C2SES III requirements. The assessment of relevancy focuses on criteria relevant to the C2SES III technical subfactors and will be given a relevancy rating at the subfactor level with an overall relevancy rating also assigned for each contract.

M3.2.2.2.1. In order to be considered Relevant, the effort involved must have been essentially the same scope and magnitude and complexities that is being proposed to perform the C2SES III requirement. Relevance of an effort where the offeror participated under a joint venture arrangement will be determined based on the dollar value of relevant work performed by the offeror. If a third party or customer cannot discern what work the offeror performed, this effort will not be considered relevant. The Government may consider the offeror’s (including subcontractors) past performance in aggregate, rather than on an effort (contract) by effort basis. This takes into consideration joint ventures or teaming arrangements in which the proposing partners participated, either with each other or with other entities, in performing work similar to that which they are proposing to perform for the current effort. For example, the offeror is a joint venture where there are four partners that share equally in the proposed effort. They established the joint venture for this requirement so past performance information is not available on the joint venture but is available on each of the partners. Past performance on each of the partners of the joint venture may be only somewhat relevant because work, although the same, is not of similar size or dollar value of the current requirement. However, when the partners’ past performance is viewed in the aggregate, the past performance information may more accurately reflect a higher rating. The offeror shall identify the specific contracts submitted as an aggregate for evaluation purposes in the Contractor’s Past Performance Information Document.

As a result of an integrated analysis of the offeror’s past efforts, each contract submitted for past performance purposes will receive Past Performance Relevancy Ratings, as defined in the Table 3.0 below.

TABLE 3.0 – PAST PERFORMANCE RELEVANCY RATINGS