1. MSP_Requirements_Night Owl FINAL_Rev.docx

Managed Service Provider Performance Work Statement- Draft

Table of Contents

Context

The Program office is seeking a Managed Service Provider to provide operations & sustainment functions. The customer requires tightly integrated production, operations, and scaling support to enable the “at-scale” platform operations required of a Major Weapon System.

Simultaneously, where new discovery, experimentation, rapid feedback, and the realm of high uncertainty exists, support from a lean, contextually-aware team is required to drive the creation of new capabilities with the CSP team.

Parties Vendors

1. Managed Service Provider (MSP): delivers services, such as network, application, infrastructure, and security via ongoing and regular support and active administration on customers’ premises or in a third-party data center.[footnoteRef:2] [2: Definition of Managed Service Provider (MSP) - Gartner Information Technology Glossary]

2. Cloud Service Provider (CSP): is a third-party company that provides scalable computing resources that businesses can access on demand over a network, including cloud-based compute, storage, platform, and application services.[footnoteRef:3] [3: What is a Cloud Service Provider? | Google Cloud]

Customers

1. Workload developer: Contractor or government developer and capability provider that consumes MSP provided *aaS network and infrastructure to provide capabilities to the workload end-users.

2. Workload operator: Contractor or government operator that manages and ensures that mission workloads are running inside the managed infrastructure.

3. Workload end-user: Government user that leverages the workload to support their operational mission.

4. Supported organization: Organization containing the end-users that utilize the workloads in order to meet their organization objectives.

5. Program Office: Organization managing the contract with the MSP, collecting requirements, and managing the delivery of capabilities from the MSP to support organizations.

6. Cloud Service Customer (CSC): Primary stakeholder consuming or using a provided cloud service. NOTE: Near-term this is the Program Office with workload end-users and supported organizations at each operating location.

Responsibilities

1. Supported organizations will provide timely notification of critical events, dates, etc. to help the MSP manage operations and sustainment, and provide them appropriate opportunity to meet SLAs during these periods.

2. The MSP will act as the primary provider and integrator of all services identified. For subcontracting opportunities, the outsourcing will be coordinated with the program office and supported organization(s) to ensure security compliance for all companies involved.

3. The MSP will communicate with the Program Office, Supported Organizations, and end-users if there are scheduled (requirements for prior notice of scheduled events defined later) or unscheduled outages to provided services due to MSP activity or external disruptions.

4. The MSP will leverage an automated infrastructure deployment pipeline, like that depicted in Figure 1, for all managed and provided services. This pipeline will leverage automation as much as feasible. This pipeline shall be used to ensure that configurations are maintained and provide a test/integration point before pushing services to a production environment.

Figure 1: Infrastructure Deployment Pipeline[footnoteRef:4] [4: Patterns - Continuous Delivery]

Service Level Agreements (SLAs) and Service Level Objectives (SLOs) This section defines a general approach to measuring and calculating an SLA or SLO. The expected SLA/SLO performance will be specified per service in their individual definitions in Section 2.

For each service, the MSP shall make available the running metrics via self-service report to the CSC.

Availability[footnoteRef:5] [5: Closely based on ISO 19086 Cloud service availability example]

For each infrastructure service offered as a service, an uptime condition in the form of XX.yy% of time in a defined period (i.e. daily, weekly, monthly) will be defined.

Unavailability is defined as:

a) The service provides no response to the service consumer.

b) The service returns an error to a valid request during consecutive one-minute intervals.

c) The service fails to deliver an average response time of one second or less as measured by the CSC.

Scheduled maintenance is maintenance coordinated with CSC at least ten business days in advance, and that does not exceed one hour in any seven-day period.

Unavailability due to scheduled maintenance is excluded from the above conditions and does not contribute towards unavailability calculations.

Reliability

· Time to Service Recovery

· Mean Time to Service Recovery

· Maximum Time to Service Recovery

· Number of Service Failures Performance/Capacity

· Service Maximum Response Time

· Service Mean Response Time

· Service Response Time Variance

· Service Connection Limits

· Service Resource Limits

· Throughput (Requests/Transactions) Limits

· Bandwidth (Data Rate) Limits Security As part of the security process, the MSP in collaboration with Program Office will implement an Information Security Continuous Monitoring (ISCM) program (i.e. follow NIST Special Publication 800-137). As part of the establishment of the ISCM, the MSP will establish security metrics that will be monitored and reported to the CSCs at the frequency determined in the ISCM program establishment process.

Support

· Support Hours: Hours of operation for basic support plan

· Service Incident Support Hours: hours during which CSCs may obtain support specifically for service incidents.

· Service Incident Notification Time: time interval in which the CSP will provide a notification of a service incident to specified contacts at the CSC when provided for in the support plan.

· Maximum First Support Response Time: maximum time between a customer reporting an incident and the MSP’s initial response to the report.

· Maximum Incident Resolution Time: Maximum time for resolving an incident.

Requested Managed Services Summary of Requested Services The Program Office is requesting an MSP to deliver an integrated set of cloud and edge services to ensure that the weapon system information system requirements are met and are available when and where needed. In particular, the following services are requested at three operation locations, a West Coast/California location, a mid-west location (identify the geographic location selected), and a Washington/Capitol Region location (assuming two hundred (200) users per location and scaling to three hundred fifty (350) users per location on year 3): networks and infrastructure, help desk and support, security and compliance, monitoring, business intelligence, DevOps platform and process, and overall program management of the requested services. These services should be delivered in a manner that is responsive to the needs of the CSCs.

Networks and Infrastructure Primary Customer: Workload, Supported Organization Definition of Requested Services Initial Infrastructure Requirements:

· Support the installation by CSP, configuration, operations, and sustainment of Azure Stack Hub (ASH) at Program Office-defined locations. This includes, but is not limited to:

· Support site surveys – coordination between Program Office, CSP, local facilities managers, and ensuring appropriate access to site.

· Support site pre-deployment prep – coordination with facilities on any required changes, visit requests, and any other requirements pertaining to deployment ASH, supporting network connections, etc.

· Provide verification and validation of ASH install, and other CSP provided services.

· Additional configuration, operations, and sustainment of provided ASH outside scope of enterprise services required for supporting operational workloads.

· Providing additional services outside scope of Azure Stack Hub and enterprise offering. For example:

· Identity services through Active Directory in a federated fashion across ASH installations.

· Security services to include, but not limited to, WSUS, ACAS (i.e. Tenable.sc), YUM repo, ESS (or equivalent), and SIEM ( i.e. Splunk Enterprise). These shall be exposed to the various workload developer and operator and available in a self-service manner.

· Support the installation, configuration, operations, and sustainment of campus area network in support of deployed ASH, hyperscale connectivity, and operational workloads. This includes, but is not limited to:

· The design and architecture of the campus area network for new sites.

· The purchase of the hardware for new campus area networks.

· The installation and configuration of switching infrastructure to provide connectivity from different campus locations back to the ASH.

· The design and architecture for user workstation deployments based on government facilities and personnel plans to be provided.

· The purchase of user workstation hardware (e.g. thin client, KVM, monitors, mouse, keyboard). This includes expansion of capability at existing sites or new sites.

· The installation, configuration, and management of user workstations for CSCs back to the ASH and configured to access specific workloads. This includes expansion of capability at existing sites or new sites.

· Providing network connectivity support for CSC peripheral devices to the ASH and specified workloads.

· Support the installation, configuration, operations, and sustainment of any additional equipment required to support the enterprise-wide area network connecting an ASH to other locations and networks. Including:

· Purchase, installation, and configuration of any additional hardware to connect the WAN point of presence to the local ASH. This is anything not provided by local site communications team or the CSP.

· Monitor and facilitate changes to:

· ASH to ASH inter-site connectivity

· ASH to external networks (e.g. SIPR, or existing customer network)

· ASH to cloud connectivity

· Provide MSP services portal supporting requests to increase, change, move, or otherwise modify infrastructure and network deployments/configurations in support of changes to requirements of the Supported Organization and Program Office.

· Provide disaster recovery services for all associated services and equipment above that do not have disaster recovery provided by the CSP.

· Expectations of MSP The MSP will work in close and continuing contact with the CSP to tailor and field full capabilities enabling IT system life-cycle management for edge and hyperscale infrastructure and network as a service in support of the overall program. The MSP will consume and operate in the CSP environment, the program office is not looking for “value added” capability but rather a talented teammate to collaborate with the CSP. This support includes the workload operations, backend services and the associated campus and wide area networking infrastructure at multiple locations meeting the local supported organization requirements for compute, storage, security, and communications (internal and external).

In addition to providing the core services, it is expected that the MSP will develop/deliver a disaster recovery plan, and associated service leveraging CSP offering. This shall include plans for replication, failover, reconstitution, diverse network paths, etc.

Key Results

1. Documented purchase and deployment plan and instrumented results showing the actual deployment timelines for the networking and compute services described above.

2. Documented test plan and associated results, demonstrating functioning of required capabilities and connectivity.

3. For every service provided, the configurations are as automated as feasible. Changes are version controlled and managed through a change management process, demonstrated through repeated deployment on MSP provided test infrastructure.

4. System for requesting changes and tracking service change requests from inception to completion. The cycle times for change requests are made clearly visible as requests are resolved.

5. Self-service capability for all services unless otherwise approved by the Program Office.

6. Digital workflow for end-user terminals, campus and WAN network modifications.

7. Digital designs (maps) of the campus area infrastructure at a building and desk level for each deployed site such that configuration management can be executed in a digital model.

8. Perform continuous assessment and reporting of system security posture.

9. Support cybersecurity assessment and testing performed by third-party organization(s). The government intends to continue to collaborate with an existing third-party vendor.

10. Delivery and maintenance of edge network ATO.

Deliverables

1. Real-time service health page for each supported organization and site that at minimum includes:

1. Operational status of *aaS

2. Local campus network status

3. WAN status

4. Scheduled MSP events

5. Current performance (e.g. # of active users, load, latency)

6. Log of recent events

7. The governments preference is to work with the 559th SWEG (ThunderCamp) and to adapt and expand the existing solutions in government IL5, IL6, and IL6+ cloud spaces.

2. In addition to on-demand real time dashboards, the MSP will provide monthly reporting on SLA and SLO performance

3. Monthly report, including roll-ups from the dashboard and performance relative to the Key Performance Indicators and SLAs identified in other sections or additional contract documentation.

4. Ticketing and/or workflow management system for all services not self-service with appropriate monitoring for reporting on blocked issues, responsiveness, and resolution time

5. Operations and cyber manuals for the day-to-day operation and maintenance of the environment Metrics Proposed SLAs and SLOs to be calculated and evaluated on a weekly or monthly basis depending on the specific SLA/SLO. The following are initial SLAs to be measured.

For all metrics, refer to section 1.3 for general guidance and the associated appendix for how to calculate a given metric. It is assumed that there will be scheduled maintenance that will not count against availability metrics, if coordinated and falls within the agreed upon service window.

Network Metrics

Campus LAN

WAN

Disaster Recovery

DRaaS

Replication

Failover

Maintenance Downtime

Help Desk/ Support Primary Customer(s): Workload*, Supported Organization Definition of Requested Services The MSP shall provide on-site and online/remote support for deployment and troubleshooting of MSP deployed infrastructure and services, and facilitate escalation to any CSP provided infrastructure and services. Additionally, the MSP shall provide online/remote support for cloud provided services and a path to escalation for all troubleshooting or outages. These services include, at a minimum:

· On-site support: Provide local time zone 9-5 on-site support during normal working hours for the supported site with the ability to work outside of core hours as necessary (infrastructure down-times, installations, etc.). To the maximum extent practicable, this capability shall be delegated to local USG IT support through appropriate training.

· Phone support: Escalation for phone requests to occur within 24 hours with escalation through IT support tiers (e.g. Tier 1 – initial response and troubleshooting, Tier 2 – major incident, etc.) during normal support hours, or during specific on-call situations.

· Email support: Expected initial response within 24 hours of initial email submission during normal support hours, or during specific on-call situations. This timeline does not include an automated response, and requires the response from a support team member.

· Tiered support: Overall support will be divided into different areas of responsibility. The areas related to this contract are Application Support, Operations Platform Support, Environment Support, and Monitoring Support. Develop a tiered support matrix for review and approval by CSC. Tiered support matrix shall consider severity of outages. Upon approval from the CSC, MSP provider shall meet approved tiered timelines.

· Tier 1. Application Support – Administrators and/or “super-users” of the application being deployed to the operations environment. The responsibility for this support falls on the mission application owner. From an application user/operator perspective, this would be the support team first contacted for issues.

· Tier 2. Operations Platform Support – Technical support personnel responsible for the cloud platform that applications are deployed to for Operations (both Test and Production). If the Application Support team identifies an issue, they believe must be solved by the Operations Platform Support team (or higher tier), they will contact the development team.

· Tier 3. Environment Support – Technical support personnel responsible for the overall set of cloud environments and data transfer solutions connecting them. If the Operations Platform Support team believes there is an issue with the overall environment, they will contact the DevOps team for resolution.

· Cross-Tier [enables all other tiers]. Monitoring Support – Security Information and Event Management (SIEM) of OEM and/or custom-created machine-data to support the teams monitoring the health, performance, quality, and security of their platforms. Ensure the right SIEM application and supporting hardware is integrated into the solution (e.g. NOT tacking it on later). This toolset will monitor the Application, Operations Platforms, and DevOps environments (as well as itself to support the Cyber requirements of “Auditing the Auditors”). Each team will contribute machine-data (logging, alerts, reports) to the overall pool of monitoring products. Cybersecurity requirements will dictate logging retention requirements (typically 1 year). Each Monitoring product (i.e. dashboard, alert, report) will work identically across all accessible environments (i.e. Dev, Test, QA, PROD) except where necessary/logical. Provide engineering support to integrate the Crucible DevSecOps environment, supported customer DevSecOps environment, hardware in the loop laboratories, Crucible Production, edge operational environments, edge operational customer workloads supporting customer into a single coherent continuous integration/continuous deployment platform environment.

· Preplanned Events: Upon minimum of 10 days notice from CSC, MSP shall ensure full environment capability during all CSC preplanned events (ex. test schedules, etc.).

Expectations of MSP Provide the help desk and support infrastructure, services, and personnel required to be responsive to end-users of the managed networks, infrastructure, and security services. Develop tiered environment response timelines based on severity of outages with the demonstrated ability to meet environment restoration targets.

This includes the ability to provide self-service capability where appropriate (e.g. account resets, service provisioning), change requests (e.g. new services, users, changes), and troubleshooting requests (e.g. outages or performance issues).

Key Results

· Monitoring service showing SLA performance for services per supported organization and associated site (ex. Ticket production and velocity, security classification and triage time, etc.)

· Developed and approved tiered response timelines based on severity of outage with demonstrated ability to meet restoration targets.

· Maintenance of environment during all CSC communicated preplanned activities.

· Demonstration of responsiveness to customer needs through weekly and monthly reporting.

· Discoverable help desk information for CSCs.

· Self-service for automatable help desk functions, like password reset.

· Accessible documentation for common issues and troubleshooting.

· Assistance with any data spillage/recovery requirements as dictated by authorized CSC security personnel. The JOINT SPECIAL ACCESS PROGRAM (SAP) IMPLEMENTATION GUIDE (JSIG) Errata Sheet for the JSIG, 8 October 2018 integrated, outlines controls that must be followed for these requirements. Classified data is spilled either onto an unclassified information system or to an information system with a lower [or different] level of classification [or access]. [CNSSI 4009] Also referred to as data exfiltration – the unauthorized transfer of data from a system.

Deliverables

1. Definition of SLAs for each provide service, refined per supported organization and associated site.

2. Documented outage report, root cause and resolution for all severe events within 3 calendar days of restoration

3. Documented SLA performance, in Section 2.3.5, for every supported organization and associated site.

4. Landing page for discovery of help desk and support information to include:

a. Contact information

b. Known outages or issues

c. Ticketing system

5. Notification system for outages (planned or unplanned) or service impairments (planned or unplanned).

a. Within the provided service environment on customer networks Metrics

Help Desk Responsiveness

Self Service Capabilities

Security/Compliance Primary Customer(s): Workload*, Supported Organization, Program Office Definition of Requested Services A secure network requires constant monitoring, updating, and informed architectural decisions. The program office is seeking security operations center services, and associated support to meet DoD cybersecurity compliance requirements. This includes by not limited to personnel to fulfill roles and responsibilities of Information System Security Manager, and Information System Security Engineers to maintain the systems compliance with DoD regulations.

Expectations of MSP The MSP will ensure that the managed infrastructure and networks are secured and maintain compliance with all defined DoD regulations in JSIG, 8 October 2018 which is based on NIST SP 800-53, Rev 4 and CNSSI 1253, March 2014, or as determined by the authorizing official responsible for the program. The MSP will provide security monitoring, auditing, patching, and documentation to meet said regulations. The MSP is responsible for ensuring that the system maintains mission workload capability while satisfying compliance, risk, and security requirements. This includes all appropriate documentation, monitoring, auditing, and reporting required to maintain a continuous authorization to operate (cATO). cATO requirements include Continuous Monitoring (CONMON), Active Cyber Defense, Secure Software Supply chain, and other areas identified by the authorizing official. The governments preference is to work with the 559th SWEG (ThunderCamp) and to adapt and expand the existing solutions in government IL5, IL6, and IL6+ cloud spaces.

This service is focused on the networks and infrastructure provided by the MSP. It is expected that the MSP will also offer a subset of these security services to the workloads that will be running on the infrastructure and across the networks. These offerings will be documented in a service catalog, available through a self-service mechanism to workload developers and operators.

It is required that a tiered service model will be provided, and that capabilities will be managed from a security operation center capable of supporting the program requirements and having appropriate coordination mechanisms with each.

Key Results

1. Demonstrated identification, triaging, and resolution of issues.

2. Maintained continuous ATO in accordance with the Authorizing Official

3. Notification and escalation path for identified incidents in coordination with supported organizations and associated sites.

4. Internal MSP change control board that coordinates with the Program Office change control board as necessary (Reference Section 2.4.5).

5. Internal MSP security review board that coordinates with the Program Office security control board as necessary.

Deliverables

1. Rules of Engagement for response to security events that may impact workloads using or operating within managed services.

2. Service Level Agreement in accordance with DoD regulations and concurred upon by each supported organization.

3. Regular auditing/reporting of security posture as required by DoD regulations.

4. Dashboard showing current security posture to include, but not limited to:

1. Service availability

2. Service security status

3. Current or recent incidents Metrics

Monitoring

SIEM

Compliance

Data Aggregation across services

Data Retention

Monitoring Definition of Requested Services The Program Office is seeking monitoring services for all provided services and the ability to extend monitoring to the supported workloads. The monitoring service should be able to identify outages, performance issues, misconfigurations, and support appropriate alerting and escalation. These services should be available to the supported organizations, workload, and the program office. For supported organizations and workload related users, the monitoring should support their troubleshooting and triaging processes. The program office is seeking monitoring to ensure visibility to SLA fulfilment, system compliance, demand signals from supported organizations, and early indicators for future service investment. These network and security operations monitoring services should extend what is provided by the CSP NOC and SOC to cover the additional capabilities managed by the MSP. In addition, the MSP is expected to configure and adjust any monitoring to focus on ensuring mission execution.

Expectations of MSP The MSP is expected to build and implement the required infrastructure and tooling to support the monitoring identified above. It is expected this will be the same set of tools that the MSP uses to ensure they are delivering quality services. The monitoring system shall support monitoring at all security levels identified previously. When the monitoring is specific to a workload, the MSP shall provide ways to ensure that the data coming into the monitoring system is either sanitized or the monitoring system is at the appropriate protection level.

Key Results

1. Any supported site or workload related user can view monitoring data for the services provided by the MSP, including NOC/SOC.

2. The Program Office can at any time get overall health and status of the managed services and their associated performance for each supported organization and associated sites.

3. Monitoring infrastructure is real-time and supports business decisions by Program Office or supported organizations.

Deliverables

1. Accredited monitoring infrastructure and services

2. SLA for the monitoring service

3. API reference for the monitoring service to enable workloads to leverage monitoring data and make informed decisions.

4. Associated dashboards accessible to users and the Program Office.

Metrics Service

Monitoring Service

Availability at Edge

Data Aggregation across services

Data Retention

Environment Deployment and Management Primary Customer: Program Office, Supported Organization Definition of Requested Services The Program Office requires deployment and management services for cloud environments that support development, testing, integration, and production activities for the program. These cloud enclaves are separated based on functional attributes, such as classification or DevOps pipeline stage. Deployment and management of cloud environments includes but is not limited to generating repeatable Infrastructure as Code (IaC) for base environment deployments and Configuration as Code (CaC) for configuring environments for connection to peripherals, other cloud environments, etc. and implementing services such as RBAC security groups. Some of these environments may already exist, and some will need to be built. All environments are expected to change over time, and the MSP shall support modifications, and maturation of the environments to support evolving program needs.

Expectations of MSP The MSP is responsible for providing the program office with a repeatable framework for rapid deployment of new cloud environments. The MSP shall consume environment requirements from the program office and collaborate with the CSP to ensure deployment can seamlessly integrate with provided architecture. The MSP shall provide feedback and weekly updates to the government regarding new deployment status as well as any technical or security blockers. Once deployment is complete, the MSP is expected to integrate all provided services within scope to new environments.

Key Results

1. Programmatic tracking of environment deployment and management

2. Providing consistent feedback to the CSP and Program Office on technical or security blockers for the deployment and operation of these environments

3. Deploy all MSP services previously defined within new environments

4. Generate a repeatable automated framework for new environments within the CSP provided cloud infrastructure

5. Provide on-boarding services to the new environments for workload developers, operators, and CSCs Deliverables

1. Weekly status updates on new deployments

2. Service dashboard integration with new environments

3. IaC and CaC products for environment deployment and configuration Metrics The metrics are focused on measuring the speed to deployment and speed to configuration for new environments. This will be measured for each provided service.

Environment Deployment Speed

Environment Configuration Speed

Business Intelligence/Data Analytics Primary Customer: Program Office, Supported Organization(s) Definition of Requested Services To help the Program Office deliver the best services possible to the customer base, the MSP will implement and use a business intelligence and insight platform. At a minimum, this platform should help the Program Office or CSCs identify opportunities for increasing capacity/services, optimizing metered service spend, and areas for service improvements. This platform shall monitor SLAs and SLOs for the managed services. The governments preference is to work with the 559th SWEG (ThunderCamp) and to adapt and expand the existing solutions in government IL5, IL6, and IL6+ cloud spaces.

Expectations of MSP Install and configure a business intelligence tool sufficient to monitor performance of all SLAs and SLOs.

Install and configure a business intelligence tool that monitors metered service spend and make recommendation for CSC optimization of services.

Monitoring and reporting to help the organization understand areas for improvement and future investment.

Key Results

1. Live dashboards covering SLAs and key performance indicators around all other requested services (e.g. infrastructure, networking, security, help desk, monitoring)

2. Monitor metered service spending and notifying the CSC when 80% of awarded funds are expended and an estimated date of funds depletion. Provider shall ensure CSC consumption does not exceed the contract funded levels.

3. Trend analysis for each provided service

4. Warnings and notifications when a service is violating or nearing violation of an SLA/KPI

5. Health, Status, and utilization information for each service Deliverables

1. Monthly reports on the agreed upon performance for each provided service (i.e. reporting on SLA/SLO satisfaction for each month).

2. Notification of metered service spending limits and estimated depletion dates.

3. Provide CSC continuous access to all Live dashboards.

Metrics

BI Services

Dashboards

DevOps Implementation Process Definition of Requested Services The Program Office is seeking to build a learning based organizational model leveraging generative feedback loops to accelerate the delivery of customer identified value to the Program Office and external customers.

Expectations of MSP The MSP is expected to provide a DevOps coach who has a unifying responsible across the entire MSP organization to work with the Program Office to document, communicate, and clarify the customer value stream and return on investment.

Key Results

1. Program level value streams and correlated critical metrics visible to all members of the Program Office, MSP, and supporting teams.

2. The MSP team be able to clearly communicate, document, and demonstrate the capability development workflow showing the traceability of requirements down to specific implementation and delivery of those requirements at an atomic unit of customer-realized value.

3. The MSP team will execute monitoring of all requirements, process, and implementation inside of the Program Office environment.

Deliverables

1. Accredited monitoring infrastructure and services

2. Appropriately cleared personnel that are able to support the infrastructure and respond to issues.

3. SLA for the monitoring service

4. API reference for the monitoring service to enable workloads to leverage monitoring data and make informed decisions

5. Associated dashboards accessible to users and the Program Office Metrics The DevOps metrics are focused on measuring the organization maturity and will evaluate over time if the MSP is performing DevOps at a high level. This will be measured for each provided service.

Service Deployment Frequency

Lead Time for Changes

Change Failure Rate

Time to Restore Services

Program Management Primary Customer: Program Office, Supported Organization, MSP, CSP Definition of Requested Services MSP shall identify a singular point of contact responsible for interfacing with the CSC and Program Office, ensuring all services are performed in accordance with the contract, and attending/interfacing with the System Integrator, CSP and Ether delivery teams to ensure maximum convergence and usability of all CSP and Ether capabilities. The MSP shall manage day-to-day implementation of services and document tasks, work in progress and completion of tasks via online program management tools (JIRA, Confluence, etc). The MSP shall work concurrently with the CSC and partner organizations to adapt to dynamic system requirements and ensure MSP services are supported.

Expectations of MSP The MSP will provide a customer accessible requirements traceability matrix and process, including documentation in JIRA, Confluence, Bitbucket, Artifactory. The MSP will maintain total ownership of development execution, reporting, and management of work in process. In addition, monitoring should portray MSP-provided metered service environment spend management.

Attend weekly CSP and Ether meetings for MSP awareness purposes and provide regular feedback to all execution teams.

Conduct weekly meetings with the CSC Program Office teams on MSP service implementation and performance Key Results

1. Live dashboards correlating the mapping of requirements to the development of the smallest measurable units of work.

2. Trend analysis for each work stream

3. Management of work in progress and iterative delivery of complete capabilities

4. Participation with CSP, Ether and System Integrator (as needed) execution meetings and make recommendations to the CSC to ensure convergence of all lines of effort Deliverables

1. Live dashboards, updated on every commit of code or planned change to the system, showing the progress of the program.

2. Weekly meeting updates and charts.

References Amazon Web Services. (2023, 06 27). AWS Service LEvel Agreements (SLAs). Retrieved from AWS: https://aws.amazon.com/legal/service-level-agreements Microsoft. (2023, 06 27). Azure SLA Docs. Retrieved from Azure SLA Docs: https://www.microsoft.com/licensing/docs/view/Service-Level-Agreements-SLA-for-Online-Services?lang=1&year=2023 image1.png