E - ITIOSS _TO2_QASP_SLAs.docx

ATTACHMENT E

IT Infrastructure Operations Support Services (ITIOSS)

Task Order 2

SharePoint Solution Development Services (SSDS) Quality Assurance Surveillance Plan (QASP) 7-1-19

Table of Contents

1. INTRODUCTION

This quality assurance surveillance plan (QASP) establishes procedures and guidelines ITIOD will use to ensure the Contractor achieves the required performance standards or service levels on the SharePoint task order. This QASP identifies performance objectives, defines the methodologies used to monitor and evaluate the Contractor’s performance, describes quality assurance documentation requirements, and describes the analysis of quality assurance monitoring results. The cornerstone of performance management is the ability to make decisions based on the analysis of performance data; this analysis yields information that indicates whether the contractor is achieving expected outcomes for the project.

a. Methodologies to Monitor Performance PBGC will monitor performance through stakeholder surveys, 100% review of monthly and quarterly deliverables (see Appendix B of SharePoint PWS), and through the receipt of unscheduled feedback. PBGC will collect all performance data for review by the Performance Review Board (PRB) on a monthly basis. Additionally, the PRB reviews all incidents in addition to the monthly Program Status Report (see Appendix B of SharePoint Task Order), and PBGC and the Contractor will jointly address issues or downward trends in customer satisfaction. PBGC will work with the Contractor to implement improvement initiatives that impact internal PBGC processes as well as to define improved processes, roles and forums for governing all service areas. In addition to surveys, each month, the COR will conduct a review of all contractor-generated deliverables and collect a log of negative feedback from PBGC end-users during performance. Note: the term “User” is inclusive of all end-users, customers, or events that cause an incident to be reported.

2. ROLES AND RESPONSIBILITIES

The Contracting Officer

The Contracting Officer (CO) is responsible for monitoring contract compliance, contract administration, and cost control and for resolving any differences between the observations documented by the Contracting Officer's Representative (COR) and the Contractor. The CO will designate one full-time COR as the government authority for performance management. The number of additional representatives serving as technical inspectors depends on the complexity of the services measured, as well as the contractor’s performance, and must be identified and designated by the COR.

The Contracting Officer’s Representative

The Contracting Officer’s Representative (COR) is designated in writing by the CO to act as his or her authorized representative to assist in administering a contract. COR limitations are contained in the written appointment letter. The COR is responsible for technical administration of the project and ensures proper government surveillance of the contractor’s performance. The COR is not empowered to make any contractual commitments or to authorize any contractual changes on the government’s behalf. Any changes that the contractor deems may affect contract price, terms, or conditions shall be referred to the CO for action. The COR will have the responsibility for completing QA monitoring forms used to document the inspection and valuation of the contractor’s work performance. Government surveillance may occur under the inspection of services clause for any service relating to the contract.

Contract Monitor

Contract Monitors are the representatives closest to technical work performed. Monitors are personnel who have responsibility for reviewing technical performance and/or interacting with the contractor on a regular basis. The responsibilities of the Contract Monitors are to:

· Provide detailed information monthly to the COR and the Award Fee Board Members in writing and or orally before the board on the contractor's performance

· May attend board meeting at the discretion of the AFEB chair

Performance Review Board (PRB)

· Refer to section 4.2 of the Award Fee Determination Plan for the roles and responsibilities of the PRB.

3. PERFORMANCE REQUIREMENTS SUMMARY TABLE

Service Level Agreements (SLAs) The SLAs represent the Government’s proposed performance measurement structure. Offerors are strongly encouraged to recommend changes to the SLA that improve PBGC’s ability to achieve its program and service objectives. During transition (see § 5.2 of SharePoint Task Order), the Contractor will finalize and formally adopt contract SLAs. As part of that process, PBGC and the Contractor will analyze SLAs to ensure that they are fair and reasonable for the ensuing transfer of control. Both parties must review changes, and upon acceptance, the changes will be reflected by modification of the contract by the end of the transition period and prior to the Contractor taking full control of services. During this period, SLAs will be tracked, monitored, adjusted, and reported against targets as part of the monthly review by the Performance Review Board and may be adjusted through bilateral agreement.

The Contractor shall be evaluated on the proposed and accepted SLAs that apply specifically to transition activities during the first two months of award.[footnoteRef:1] The Contractor will be evaluated in accordance with contract SLAs beginning the month 3 of the contract. The first performance period under which the Contractor will be evaluated under the contract SLAs with therefore be four months. After that the contractor will be evaluated on a quarterly basis. [1: See § 5.2 of Task Order 02 regarding requirements during transition and related provisions of the Award Fee Determination Plan. ]

Remedy Plan for Underperformance When failure to meet an AQL occurs two (2) or more consecutive months with the same metric, the Contractor shall propose a remedy plan. This plan shall be approved by the Government and executed by the Contractor to bring the latter’s performance up to AQLs as defined by the SLAs.

4. INCIDENT ESCALATION SYSTEM

PBGC uses a tiered incident escalation system (Tiers 1, 2, 3 and 4) to classify the level of knowledge, skill, and access privileges typically required of IT support to resolve an incident. All incidents are first addressed at the Tier 1 level (first-call resolution). In some circumstances, Tier 1 is insufficient to resolve an incident and will require escalation to a higher-level tier such as the SharePoint team for resolution.

Please Note: Tier 1 incident resolution and related Service Desk functions are not included in the scope of this task order. Under this task order, the Contractor is only responsible for tickets escalated to the SharePoint team for resolution.

Figure A – Tier-level Escalation Table

5. PRIORITIZING SHAREPOINT SUPPORT SERVICES BY IMPACT AND URGENCY

Incidents are prioritized in accordance with impact and urgency ratings assigned to the end-user’s incident upon contacting the Service Desk. Each incident is assigned a predefined triage level based on the Priority Levels, and priority level incidents are reported monthly to the Performance Review Board. Priority levels are determined based the determination of the impact of the incident on PBGC as well as the urgency as determined by the table below.

Using the number that results from the above matrix, the incidents are prioritized in accordance with the following Service Priority Levels. The incidents are also assigned a time-to-resolve as well as an acceptable quality level (AQL). PBGC measures the time-to-resolve from initial contact, response, and final resolution of an incident. Time-to-resolve may end when the user has been returned to a state of normal operation but has not responded to three documented contact attempts to ascertain the user’s full satisfaction. All instances of user non-response will be escalated to federal staff for resolution.

Figure B – Service Priority Levels

· An unplanned outage of a mission-essential production application or service (as documented by “COOP Essential” or “COOP Critical” within mAppIT, excluding desktop applications)

· A primary GFE desktop, laptop or mobile application or infrastructure outage impacting a VIP’s ability to perform work. Identification of VIP tickets shall rely upon the ‘requested for’ field in SM9.

· A desktop application outage impacting 50 or more users.

3 business hours.

AQL=85%

TQL=90%.

· A desktop application outage impacting 2-49 users or impacting a single user such that this user is completely unable to work in any capacity using IT systems because of the outage.

· A degradation in infrastructure or application performance or fault tolerance of a critical/essential production business application/service.

· A non-Production (CDE-T, CDE-I, ITC) service outage impacting many users and/or seriously imperiling a scheduled software release.

1 business day (12 business hours).

AQL=85%

TQL=93%

· A degradation in infrastructure or application performance or fault tolerance of a non-essential production business application/service. C) A non-Production (CDE-T, CDE-I, ITC) service/application outage impacting several users 2 business days (24 business hours).

AQL=85%

TQL=93%

· A non-Production (CDE-T, CDE-I, ITC) service/application outage impacting a single user

· A non-Production (CDE-T, CDE-I, ITC) service/application degradation.

4 business days (48 business hours).

AQL=85%

TQL=94%

Attachment A SharePoint Solution Development (SSD) SLA Timeliness Work Instruction Introduction The timeliness SLA is used to monitor the contractor’s timeliness in delivering SharePoint Solution Development (SSD) Requests. As an award fee performance metric, this Service Level Agreement (SLA) incentivizes timely service delivery of SharePoint Solution Development Requests.

Scope This SLA is a measure of timely work completion. The SLA is calculated using the percentage of assigned SSD tasks completed on time within the reporting period. Assigned tasks are given a weight based on the estimated hours for those tasks. Those weights are detailed in the Award Fee Determination Plan. The calculation of SSD timeliness percentage is equal to the sum of the completed on-time task weights divided by the sum of all the task weights; tasks that are completed after their due date but prior to the end of their associated sprint will be scored at 50% of their weight. Any tasks not completed in the sprint will be scored as zero. A new task may be created for the next sprint with an adjusted weight based on the estimated number of hours left to complete the task.

The Information Technology Infrastructure Operations Department (ITIOD) tracks and manages SSD delivery through three-week sprints. Each SharePoint development task is added and tracked in the SSD Sprint Planner task list in the SSD site collection in SharePoint.

In the SSD Sprint Planner task list, the Completion Date and Final Due Date are the two primary columns used to determine timeliness. Completion Date is set to the current date when the Task Status is set to "Ready for Federal Review". The Completion Date is cleared if the Federal Lead Review Status is set to “Rejected” during Federal SharePoint Lead review. The Federal Lead Review Status cannot be set to “Rejected” more than two weeks after the initial completion date. Final Due Date is the agreed due date for a task established prior to the sprint. Additional tasks may be added during the sprint with both contractor team lead and Federal SharePoint lead approval.

Acceptable and Target Quality Levels

· AQL = 70% - Not less than 70% for the SSD timeliness percentage during reporting period.

· TQL = 80% -- Not less than 80% for the SSD timeliness percentage during reporting period.

Reporting Summary results will be provided monthly in the Program Status Report. Quarterly results will be provided in the quarterly program performance self-assessment report.

Steps for Action SLA Scoring For all tasks that are assigned with a due date within the reporting period and are not SLA exempt, the following formula is used to calculate the SSD Timeliness Percentage:

Total ([On Time Task Hours]) + Total (([Late Tasks Completed Within the Target Sprint]) X .5) Total Task Hours Note: Late tasks outside of Sprint are not included in the numerator.

Exceptions

1. An individual task may be marked as an SLA exception in which case it is automatically excluded from the scoring.

2. A justification for the exception must be provided in the SSD Sprint Planner.

3. All SLA exceptions must be approved by a Federal SSD Lead or the ITIOD Department Director

Metric collection and scoring The metric is a single scored SLA. As this is a time-measuring SLA, it is essential to have undisputable evidence of the date each task is completed. Metrics will be collected from the SSD Sprint Planner task list.

For the purposes of SLA calculation and reporting, the supporting fields of the Sprint Planner records are as follows with key fields noted in bold:

Assigned To = The name of the developer assigned to the task.

Assignee Comments = The text field in which developers provide daily status updates.

Completion Date = The date the task was submitted for Federal SharePoint Lead review.

Exempt from SLA = Yes/No to indicate if the task is exempt from the SLA.

Exempt Reason = Justification provided for the SLA exemption request.

Federal Lead Review Status = Verification by Federal SharePoint Lead. The default option is “Not Reviewed”, and the lead will select “Accepted” or “Rejected.”

Final Due Date = The due date of the task.

Hours = The weight of a task based upon the estimated hours for completion.

Initial Due Date = The planned due date based on the initial LOE and actual start date.

Request ID = The ID of the request in the Solution Inventory list.

Solution Name = The name of the solution to which the task is related.

Sprint End Date = The end date of the sprint.

Sprint Iteration = The calendar year and sprint iteration number (ex. 2019-1).

Task Description = The full description of the task.

Team Lead Review = Verification by the contractor team lead (or designee) that the work has been completed. The default option is “Not Reviewed”, and the lead will select “Accepted” or “Rejected”.

Task Name = The name of the task.

Task Status = Indicates the current status of the task.

Attachment B SSDS Stakeholders Survey Questions The following survey will be sent to the SSDS Stakeholders via a SharePoint page link on a quarterly basis. The result will be used as one of the SLA metrics for evaluating contractor performance.

1. How would you rate the accuracy and quality of SharePoint Solution Development services (SSDS) provided in relation to the area of your responsibilities?

Unacceptable, Poor, Acceptable / Fair, Good, Or Excellent

1. The use of appropriate resources with regards to their ability to complete program tasks has been?

Unacceptable, Poor, Acceptable / Fair, Good, Or Excellent

1. The overall resolution of program issues, changes, or concerns with regards to their timeliness, satisfaction, and professionalism has been?

Unacceptable, Poor, Acceptable / Fair, Good, Or Excellent

1. Overall, how satisfied are you with the Contractor’s performance on this program?

Unacceptable, Poor, Acceptable / Fair, Good, Or Excellent

Provide any additional information about the responses indicated in questions 1 through 4 above.

image1.jpeg image2.png