ATTACHMENT_8_-_BASIC_IDIQ_SERVICE_OUTPUT_SPECIFICATIONS.docx
DOCX document 401 KB Posted
- Solicitation number
- FA2517-15-R-7001
About this file
ATTACHMENT 8 - BASIC IDIQ SERVICE OUTPUT SPECIFICATIONS
View the file
Other files
Show 40 more
Latest 50 of 70 listed here. See the rest on GovTribe.
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
FA2517-15-R-7001
ATTACHMENT 8 – BASIC IDIQ SERVICE OUTPUT SPECIFICATIONS, Amendment 0003
PROCESS MODELS
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
5.10
| PROCESS MODELS |
| ONCE, 30 DAYS AFTER CONTRACT START |
Provide process models for all contracted processes.
items TO be addressed
| Process Owner |
| Identify the Process Owner. |
| Process Objectives |
| State the Process Objectives. |
| Process Documentation |
| Provide Process Documentation. |
| Process Feedback |
| Identify the mechanism for Process Feedback. |
| Process Activities |
| List the documented Process Activities |
| Process Metrics |
| Identify the metrics related to the process. |
| Process Roles |
| Identify all roles associated with the process. |
| Process Procedures |
| Provide all documented procedures for the process. |
| Process Work Instructions |
| Provide all documented Work Instructions. |
| Process Improvements |
| Identify any process shortfalls and Process Improvement recommendations. |
| Process Resources |
| Identify the resources required to facilitate the process. |
| Process Capabilities |
| List the process capabilities. |
Distribution GUIDELINES
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience |
| Deliver report to the respective government Process Owner. |
MONTHLY SERVICE DESK REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.1
| SERVICE DESK |
| MONTHLY |
Provide report that details the Service Desk Function’s effectiveness as the single interface with the customer/user.
Items to be Addressed
| KPI’s & CSF’s |
| Contractor shall report all performance pertaining to this process using the Operational Metrics (OMs), Key Performance Indicators (KPIs) and Critical Success Factors (CSFs) identified in the PWS per this process. |
| Walk-In Customers |
| Provide the total number of walk-in customers for the rating period. |
| Web Customers |
| Provide a total number of customers utilized the Service Desk web submission capability for the reporting period. |
| Customer Satisfaction |
| Provide customer satisfaction survey results based on 1-5 overall rating. Discuss to five surveys rated at 2 or less. |
Distribution Guidelines
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver report to the Government Service Desk Function Owner. |
MONTHLY INCIDENT MANAGEMENT REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.1
| INCIDENT MANAGMENT |
| MONTHLY |
The monthly Incident Management report provides a summary of the key activities related to Incident Management that occur during the reporting period. The report provides ITSM leaders the information to evaluate the effectiveness of Incident Management processes, relationships, and interactions.
Monthly
| KPI’s & CSF’s |
| Contractor shall report all performance pertaining to this process using the Operational Metrics (OMs), Key Performance Indicators (KPIs) and Critical Success Factors (CSFs) identified in the PWS per this process. |
| Average Time to Resolve Incidents |
| A calculated average time to resolve incidents, by priority and Service (in hours). |
| Number/Type of Top Incidents |
| A compiled list of top incidents for the month; recommendation or plan to minimize or eliminate for next month. List will be separated by category. |
| Type of Incident |
| A compiled list of incidents involving customer impact (network outages, pushes); recommendation, or plan to minimize or eliminate for next month. |
List of incidents reports, by channel (telephone, email, walk up, web submit, arm grab).
| Types of Incident Trends |
| A compiled list of Incident Trends for the month. List categorized by expected and unexpected. |
| Number of Incidents traced to Change |
| A compiled list of any incidents which occurred as a result of Change (As determined by Problem Management) for the month. |
| Service Desk Escalation Rate |
| The number of incidents escalated to tier 2 or tier 3 maintenance for resolution. Also provide the number of incidents that required support from 3rd party vendors. |
| Number Of Incidents Resulting In Service Requests |
| The number of Service Requests generated as a result of an incident. |
| Number of Security Incidents |
| A compiled list of resolved security incidents for the month handled by the Service Desk. Report of approximate labor hours required to resolve, systems affected, and other cost metrics. |
Distribution GUIDELINES
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. The report should conclude with recommendations. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver report to the Government Incident Management Process Owner. |
MONTHLY SLA/OLA BREACH REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.1
| INCIDENT MANAGEMENT |
| MONTHLY |
The monthly SLA/OLA Breach report will provide meaningful and concise information about past and current SLA/OLA breaches.
ITEMS TO BE ADDRESSED
| Number/Type of SLA/OLA Breaches |
| A compiled list of top breaches for the month; provide recommendations or plans to minimize or eliminate for next month. Report should be differentiated by internal and external service providers. |
| Types of SLA/OLA Breach Trends |
| A compiled list of Breach Trends for the month. |
| Type of Breach |
| A compiled list of any breaches that occurred as a result of Incidents, scheduled changes or Request for Change for the month. |
| Customer/Services Affected |
| A list of services and or customers affected by the breach. |
| Third Party Service Providers |
| Identify any trends or concerns involving services monitored but not provided by this contract. |
Distribution GUIDELINES
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. The report should conclude with recommendations. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver report to the Government Incident Management Process Owner. |
MAJOR INCIDENT REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.1
| INCIDENT MANAGMENT |
| AS NEEDED |
The Major Incident Report provides a summary of activities related to Major Incident Management that occur during the reporting period. The report provides ITSM leaders the information to evaluate the effectiveness of Incident Management processes, relationships, and interactions. Notification and status reporting (COMSPOT reporting) to the N-NC/J63 TNCC meets the requirements of CTO 10-01.Major Incidents are defined as Incidents involving the degradation or loss of critical services, Incidents impacting 10 or more network users, and the degradation or loss of service to Priority 1A and Priority 1 personnel.
Items to be Addressed
| Major Incident |
| Identify the Major Incident by Name and Incident Number. |
| Timeframe |
| Incident start and end time. |
| Service(s) Impacted |
| Identify the services impacted by the Major Incident. |
| Users Impacted |
| Identify users by location that are impacted by the Major Incident |
| COMSPOT Reporting |
| Provide log of COMSPOT notifications to the CWOC. Initial notification within 1 hour of the incident; hourly reporting thereafter. Report COMSPOT notifications directly to the NOC, attach the notification log in this section. |
| Closure Reporting |
| Provide an initial assessment of the root cause, final impact assessment, timehacks of milestones, corrective and future preventative actions. |
| EXSUM |
| Provide and executive summary of the Major Incident. |
Distribution GUIDELINES
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver report to the Government Incident Management Process Owner. |
MONTHLY REQUEST FULFILLMENT REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.1
| REQUEST FULFILLMENT |
| MONTHLY |
The monthly Request Fulfillment report provides a summary of the key activities related to Request Fulfillment that occur during the reporting period. The report provides ITSM leaders the information to evaluate the effectiveness of Request Fulfillment processes, relationships, and interactions.
items TO be addressed
| KPI’s & CSF’s |
| Contractor shall report all performance pertaining to this process using the Operational Metrics (OMs), Key Performance Indicators (KPIs) and Critical Success Factors (CSFs) identified in the PWS per this process. |
| Sources of Requests |
| Number and percent of requests by organization |
| Time Characteristics |
| Average time to fulfill requests by priority |
| Standard Request Fulfillment Models |
| List all Standard Request Fulfillment models |
| Non-Standard Request Processing |
| Number and percentage of requests received that were identified as Non-Standard |
distribution guidelines
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience |
| Deliver report to the Government Request Fulfillment Management Process Owner. |
MONTHLY ACCESS MANAGEMENT REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.1
| ACCESS MANAGEMENT |
| MONTHLY |
Access Management reports provide meaningful and concise information about current state of Access Management, significant changes, and insight into threats and potential vulnerabilities. Deliver the report to the Government Access Manager
ITEMS TO BE ADDRESSED
| KPI’s & CSF’s |
| Contractor shall report all performance pertaining to this process using the Operational Metrics (OMs), Key Performance Indicators (KPIs) and Critical Success Factors (CSFs) identified in the PWS per this process. |
| Inactive/Disabled Accounts |
| Provide a list of accounts, with name and date that were disabled due to inactivity. Additionally, list all accounts that were inactive beyond 30 days but were not disabled due to qualifying circumstances (i.e. Waivered Guard/Reservist, TDY, etc.) for all three networks. (NIPRNET, SIPRNET, and NEN) NIPENET list will be maintained on the NIPRNET Portal with limited access. SIPRNET and NEN lists will be maintained on the SIPRNET Portal with limited access. |
| DD2875 – System Authorization Access Request (SAAR) |
| Provide the number of DD2875s processed during the month in the format below: |
1. Network Access Request (NAR)
2. Elevated Network Access Request (ENAR)
3. Modified Network Access Request (MNAR)
4. Deprovisioned Network Access Request (DNAR)
| Service Accounts |
| Provide a listing of all service accounts, by network, explaining their purpose and all delegated and denied rights. Explain how passwords are controlled and the frequency with which they are changed. List users who create and have knowledge of the passwords. Enumerate all service accounts created or modified during the reporting period. Report approved additions/changes/deletions of service accounts for the reporting period. |
| Elevated Rights Accounts |
| Provide a complete list of all privileged/elevated accounts broken down into network, group, and role/privilege. Identify which DODI 8570.01-M (or its replacement) requirements are met for each account holder. Identify the number of privileged/elevated accounts using PIV’s, userid and password, and Alt Tokens. |
| Remote Access |
| Provide a list of services and systems with remote access including management systems. |
| Password Compliance |
| Summarize the results of password audits and password violations. This includes all accounts such as user accounts that have a waiver on file, administrator accounts that are not able to user the PIV token, etc… |
| Portal External Users |
| Maintain and report an accurate summary of the number of external users with Joint Task Force Trusted Information Exchange (JIFTIE) accounts. |
| Physical Access |
| Provide physical access control lists for each data center, communications closet and areas where information systems are housed. Provide reason for access, date access granted, areas granted, alarm access, combination access, and dates combination changed. |
| Unauthorized Network Access Report |
| Provide a summary of any unauthorized elevation of rights or improper access to systems and network infrastructure for the reporting period. |
Distribution GUIDELINES
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. Include links to files that are referenced in the report such as list of basic, privileged/elevated user accounts, service accounts, remote access lists, all classified annexes, etc… |
| Classification |
| Unclassified. Prepare as FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver report to the Government Access Management Process Owner. |
UNAUTHORIZED ACCESS AND RIGHTS ESCALATION REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.1
| ACCESS MANAGEMENT |
| AS NEEDED |
The Unauthorized Access and Rights Escalation report provides a summary of unauthorized elevation of rights or improper access during the reporting period. Provide the report within 6 hours of the incident.
ITEMS TO BE ADDRESSED
| Unauthorized Access Report |
| Provide details on any unauthorized access or elevation of rights to systems and network infrastructure. |
Distribution GUIDELINES
| Format |
| Written report with appropriate charts, diagrams, and tables. The main body of the report should be prepared for JCSC Commander, Security Manager, and Access Manager. Conclude with recommendations as necessary. |
| Classification |
| Unclassified. Prepare as FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver report to the Government Access Management Process Owner. |
QUARTERLY ACCESS MANAGEMENT REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.1
| ACCESS MANAGEMENT |
| QUARTERLY |
Provide access management information for user accounts, infrastructure devices, and physical locations to the Access Management process owner.
items To be addressed
| Compliant User Accounts |
| Provide access to complete list of user accounts. Report number of compliant and noncompliant users by division based on quarterly training requirements. Provide access to lists. |
| Privileged/Elevated User Accounts |
| Review monthly lists of all privileged users to ensure a continuing need for the capability and access. Report any Privileged/Elevated user account that has not maintained DoDI 8570.01-M certification compliance. |
Reference: USCYBERCOM TASKORD 14-0185.
| Infrastructure Access Control Lists (ACLs) |
| Provide Access Control Lists for N-NC network infrastructure. |
| ACL Modifications |
| Detail all modifications to the Access Control Lists for the reporting period. |
| Physical Access |
| Summarize changes to physical access control lists for each data center, comm closet and areas where information systems are housed. Provide reason for access, date access granted, areas granted, alarm access, combination access, and dates combination changed. Provide subsequent updates as prompted by reorganization, personnel departures and arrivals, new assignments, disciplinary actions, request additional areas, access removal, etc. Report any physical access concerns to facilities, racks, or equipment. |
DistrIBution guidelines
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. Conclude with recommendations. |
| Classification |
| Unclassified. Prepare as FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience |
| Deliver report to the Government Access Management Process Owner. |
MONTHLY PROBLEM MANAGEMENT REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.1
| PROBLEM MANAGEMENT |
| MONTHLY |
Problem management comprises all activities needed to diagnose the underlying root cause of incidents and to find a solution for these problems. It also ensures that the solution is implemented using the correct change management and release management processes. The goal of Problem Management is to minimize the adverse business impact of incidents that are caused by errors within the IT infrastructure, and to prevent recurrence of incidents related to these errors.
Items to be Addressed
| KPI’s & CSF’s |
| Contractor shall report all performance pertaining to this process using the Operational Metrics (OMs), Key Performance Indicators (KPIs) and Critical Success Factors (CSFs) identified in the PWS per this process. |
| Assess Problem Workflow and Trends |
| Enumerate problems currently moving through the Problem Management Process, include: |
· Problems without an identified root cause
· Problems with an approved workaround
| Report Number of Major Incidents |
| A compiled list of Major Incidents including customer impact (network outages, pushes); recommendation, or plan to minimize or eliminate for next month. |
| Assess Trends |
| Provide a 12 month trend of: |
· Average time to root cause, by priority
· Average Problem resolution time
Distribution Guidelines
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver report to the Government Problem Management Process Owner. |
MONTHLY KNOWN ERROR DATABASE REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.1
| PROBLEM MANAGEMENT |
| MONTHLY |
Provide the Problem Management process owner with a monthly report detailing Known Error Database activity.
Items to be Addressed
| Known Error Database (KEDB) |
| Provide a detailed list of additions, deletions, or modifications to the Known Error Database (KEDB) for the reporting period. |
Distribution Guidelines
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. The report should conclude with recommendations. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver report to the Government Problem Management Process Owner. |
ROOT CAUSE ANALYSIS REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.1
| PROBLEM MANAGEMENT |
| AS NEEDED |
Provide a description of the root cause of each Major Incident or resolved Problem.
Items to be Addressed
| Provide Problem Summary |
| Provide a summary of the problem(s) describe the service(s) and service level(s) impacted. |
| Service(s) Impacted |
| Identify the Service(s) impacted by the problem. |
| Service Level(s) Impacted |
| Identify the Service Level(s) impacted by the problem. |
| Summarize Analysis Results |
| Provide a summary of the analysis results. |
| Provide Known-Errors |
| Provide a brief description of the information revealed by the root cause analysis. |
Distribution Guidelines
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. The report should conclude with recommendations. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver report to the Government Problem Management Process Owner. |
DAILY OPERATIONS BRIEF INPUT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.1
| SERVICE OPERATIONS |
| DAILY |
The Daily Operations Brief Input provides Network Operations Center situational reporting (SITREP) of N-NC IT Services IAW CTO 10-01. The information provided will be incorporated into the N-NC/J63 Cyberspace Warning & Operations Center (CWOC)Daily Operations Briefing.
Items to be Addressed
| COMSTAT Reporting |
| Provide N-NC/J63 CWOC with the status of N-NC IT Services applying the following status methodology: |
Green = Fully Mission Capable, Yellow = Partially Mission Capable, Red= Not Mission Capable
| Status Summary |
| Provide a brief summary of the condition of less than Fully Mission Capable Services. |
| Users Impacted |
| Identify users by location that are impacted by the service degradation or outage. |
Distribution GUIDELINES
| Format |
| Submit input in N-NC/J63 (NOC) format. Presentation template provide by N-NC/J63. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| The report will be delivered to the N-NC/J63 CWOC NLT 0800 each morning. |
MONTHLY EVENT MANAGEMENT REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.1
| EVENT MANAGEMENT |
| MONTHLY |
Provide monthly Event Analysis Report the government Event Management process owner.
Items to be Addressed
| KPI’s & CSF’s |
| Contractor shall report all performance pertaining to this process using the Operational Metrics (OMs), Key Performance Indicators (KPIs) and Critical Success Factors (CSFs) identified in the PWS per this process. |
| Events Per Service |
| Number of each type (Alert, Exception – do not include Informative events) of monitored event per service. |
| Performance Related Events |
| Number of monitored events by Service indicating potential performance issues: |
· Capacity – Total Number of Capacity Events
· List the top five Capacity Events (overall, across all Services)
· Availability – Total Number of Availability Events
· List the top five Availability Events (overall, across all Services)
· Access – Total Number of Access Events
· List the top five Access Events (overall, across all Services)
| Security Related Events |
| Number of security monitored events: |
· Security – Total Number of Security Events
· List the top five Security Events (overall, across all Services)
| Events by Type |
| Number of monitored Events by service type: |
· Critical Services
· Mission Essential Services
· Mission Enhancing Services
| Known Errors or Problems |
| Identify all events caused by existing problems or known errors |
Distribution Guidelines
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver report to the Government Event Management Process Owner. |
EVENT MONITORING PLAN
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.1
| EVENT MANAGEMENT |
| SEMI-ANNUAL |
Event Monitoring of the NORAD and USNORTHCOM Networks is essential to the successful delivery of IT Services and Cyber Operations. Establish and maintain sound service delivery by enabling the proactive detection, analysis, and response to potential service interruptions and/or network threats through the implementation of an effective Event Monitoring Plan. Produce a single plan containing the Event Monitoring posture for each service in the Service Catalog. The plan should detail the accurate and timely delivery of Event Management output supporting the Network Operations Center (NOC) and the Cyber Space & Operations Center (CWOC).The Contractor is responsible for monitoring each service and service level in the N-NC Service Catalog that identifies a Key Performance Parameter (KPP). The Contractor shall monitor using an automated network management capability/tool for each service and associated service packages and report all KPPs on a monthly measurement basis. The Contractor will be assessed on the KPPs and if the monthly measurement is within the KPP Objective and Threshold. If the KPP for any service or service package is below the KPP threshold the contractor will provide a corrective action for each below KPP threshold; to include KPP trending, identification of possible root-cause service degradation, required service improvements, and analysis for meeting KPP thresholds.
Items to be Addressed
| Network |
| Indicate which network(s) the event monitoring capability covers |
| Service |
| Identify the Service(s) and Service Package(s) being monitored. Events will at a minimum include all the KPPs associated with Availability, Capacity, and IT Service Continuity for each service and service package. |
| Monitoring |
| Identify the application, tool suite, capability, or feature that is providing the monitoring. Identify the monitoring thresholds that are being used that will validate KPPs threshold are being monitored and triggered as events. |
| Key Performance Parameter Threshold |
| Report the monthly for each service and service package. The Contractor will be assess on monthly measurements to determine if services and service packages are within the KPP objective and threshold levels. KPP performance and trending above the objective will be rated above Satisfactory in relation to contractor performance. |
| Exception Threshold |
| Provide the exception threshold criteria for each event to which a KPP threshold cannot be meet and the potential service improvement required. |
| Delivery Method |
| Identify the delivery method for the event notification (e.g., Email, Console/Display Alert, Portal, etc.) |
Distribution Guidelines
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver plan to the Government Event Management Process Owner |
MONTHLY SERVICE PORTFOLIO MANAGEMENT REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.3
| SERVICE PORTFOLIO MANAGEMENT |
| MONTHLY |
The monthly Service Portfolio Management (SPM) report provides a summary of the key activities related to SPM that occurred during the reporting period. The report provides information to evaluate the effectiveness of SPM processes, relationships, and interactions. Service portfolio describes the services of a provider in terms of value to NORAD and USNORTHCOM’s mission. It articulates mission needs and the service provider’s response to those needs and assures that the services provided are measurable with regard to mission accomplishment. The goal is to establish and enforce the method for governing investments in IT Service Management. The report provides ITSM leaders the information to evaluate the effectiveness of Service Portfolio Management processes, relationships, and interactions.
items to be addresseD
| KPI’s & CSF’s |
| Contractor shall report all performance pertaining to this process using the Operational Metrics (OMs), Key Performance Indicators (KPIs) and Critical Success Factors (CSFs) identified in the PWS per this process. |
| Service Requests (SR) On Hold Summary |
| Below are summaries of the validated SRs currently on hold in the pipeline going through the “Front End” process. Directorate Priority and Anticipated Acquisition Avenue will be annotated where available. Throughput totals are based on the incoming and outgoing requests where a positive (+) equals a great number of requests coming off of hold then going on hold in the process and a negative (-) equal a greater number of requests going on hold than coming off hold in the process. |
"Mission Case REcommendation - ON HOLD" (Validated)
| SRID |
| Creation Date |
| Directorate |
| Directorate Priority |
| Working Title |
| Anticipated Acquisition Avenue |
| Status |
"mission case recommendation - ON HOLD" (Concerns, issues, focus areas)
Total On Hold:
Current Monthly Throughput:
CY Throughput:
| Mission Case Recommendation (MCR) Summary |
| Below is a summary of the MCRs in the Pipeline currently being worked through the “C4IP” process. Anticipated Acquisition Avenue will be annotated where available. Throughput totals are based on the incoming and outgoing requests where a positive (+) equals a great number of requests coming off of hold then going on hold in the process and a negative (-) equal a greater number of requests going on hold than coming off hold in the process. |
"MISSION CASE RECOMMENDATION development”
| SRID |
| Creation Date |
| Anticipated Acquisition Avenue |
| Directorate |
| Working Title |
| Status |
"MISSION CASE RECOMMENDATION - ON HOLD" (Concerns, issues, focus areas)
Total MCR In Work:
Monthly MCR Started:
Monthly MCR Completed:
# of MCR transferred to RFC:
Monthly Cancelled:
Current Monthly Throughput:
CY Throughput:
| Corporate Justification, Prioritization, and Approval Summary |
| Below is a summary of MCRs currently submitted for C4IP scoring, validation and approval through both the C4IP Workgroup and the C4IP Group. Anticipated Acquisition Avenue will be annotated where available. Throughput totals are based on the incoming and outgoing requests where a positive (+) equals a great number of requests coming off of hold then going on hold in the process and a negative (-) equal a greater number of requests going on hold than coming off hold in the process. |
"Corporate justification, prioritization and approval” (c4ip working group, c4ip corporate group)
| SRID |
| Creation Date |
| Anticipated Acquisition Avenue |
| Directorate |
| Working Title |
| Status |
"Corporate justification, prioritization and approval” (concerns, issues, focus areas)
# MCR Submitted to C4IP WG:
MCR Scorecard (Low, Avg, High):
# MCR Validated:
# of MCR Not Validated:
CY Throughput:
# MCR Submitted to C4IP G (if applicable):
#MCR Approved:
#MCR Disapproved:
| Service Package (SD) Development Summary |
| Below is a summary of SPs in the Pipeline currently being worked. Anticipated Acquisition Avenue will be annotated where available. Throughput totals are based on the incoming and outgoing requests where a positive (+) equals a great number of requests coming off of hold then going on hold in the process and a negative (-) equal a greater number of requests going on hold than coming off hold in the process. |
"service package development” (preliminary costs, schedule and technical development)
| SRID |
| C4IP Priority |
| Anticipated Acquisition Avenue |
| Directorate |
| Working Title |
| Status |
" service package development” (concerns, issues, focus areas)
Monthly SP Started:
Monthly SP Completed:
Monthly SP Cancelled:
Monthly Throughput:
CY Throughput:
| Service Packages On Hold Summary |
| Below is a summary of SPs in the Pipeline currently on hold. Anticipated Acquisition Avenue will be annotated where available. Throughput totals are based on the incoming and outgoing requests where a positive (+) equals a great number of requests coming off of hold then going on hold in the process and a negative (-) equal a greater number of requests going on hold than coming off hold in the process. |
"service packages on hold”
| SRID |
| C4IP Priority |
| Anticipated Acquisition Avenue |
| Directorate |
| Working Title |
| Status |
"service packages on hold” (concerns, issues, focus areas)
Total On-Hold:
Current Monthly Throughput:
CY Throughput:
| Awaiting Charter Summary |
| Below is a summary of those completed SPs awaiting Charter through the C4IP Group and C4IP Corporate Board. The initiatives will remain on this summary until the C4IP board meets bi-annually. Anticipated Acquisition Avenue will be annotated where available. Throughput totals are based on the incoming and outgoing requests where a positive (+) equals a great number of requests coming off of hold then going on hold in the process and a negative (-) equal a greater number of requests going on hold than coming off hold in the process. |
"awaiting charter” (c4i Corporate group, c4i corporate board)
| SRID |
| C4IP Priority |
| Anticipated Acquisition Avenue |
| Directorate |
| Working Title |
| Status |
"awaiting charter” (concerns, issues, focus areas)
# SP Submitted to C4IP G:
# SP Approved:
# SP Disapproved:
CY Throughput:
# SP Submitted to C4IP Board (if applicable):
# SP Chartered:
# SP Not Chartered:
| Chartered Summary |
| Below is a summary of those initiatives that have been chartered by the C4IP Corporate Board. Throughput totals are based on the incoming and outgoing requests where a positive (+) equals a great number of requests coming off of hold then going on hold in the process and a negative (-) equal a greater number of requests going on hold than coming off hold in the process. |
"chartered” (funded and board approved)
| SRID |
| Creation Date |
| Charter Date |
| Acquisition Avenue |
| Working Title |
| Directorate |
| Status |
"chartered” (concerns, issues, focus areas)
# SP Chartered:
# SP Chartered Funded:
# SP Chartered Unfunded:
CY Throughput of Chartered Services:
| Service Lifecycle Retirement Summary |
| Below is a summary of those services chartered for Lifecycle Retirement. Anticipated Acquisition Avenue will be annotated where available. |
"Service Lifecycle retirement” (approved by c4ip board for retirement)
| SRID |
| Creation Date |
| Charter Date |
| Acquisition Avenue |
| Working Title |
| Directorate |
| Status |
" Service Lifecycle retirement” (concerns, issues, focus areas)
CY Total of Lifecycle Retirements:
DISTRIBUTION GUIDELINES
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience |
| Deliver report to the Government Service Portfolio Management Process Owner. |
MISSION CASE
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.3
| SERVICE PORTFOLIO MANAGEMENT |
| AS NEEDED |
Develop and deliver Business (Mission) Case(s) for each new service, major change to a service. The goal of the Business (Mission) Case is to identify and validate the required Utility.
| References |
| ITIL Service Strategy |
GAO/AIMD-10.1.13 Assessing Risks and Returns: A Guide for Evaluating Federal Agencies’ IT Investment Decision-making DoDD 8115.01 Information Technology Portfolio Management items to be addressed
| Customer Stakeholders |
| List organizations/people involved in requesting, defining, and funding the service. |
· Directorate-level sponsor
· Customer Representative(s)
· Business Relationship Manager (BRM)
· Demand Manager
| Strategic Alignment |
| 30 Point Scale – Key: Red = 1, Amber = 5, Green = 10 (Rating other than Red requires explanation and justification) |
· Business Model (RAG)
· Level of Interest (RAG)
· Business Process Redesign (RAG)
| Mission Effectiveness |
| 20 Point Scale – Key: Red = 1, Amber = 5, Green = 10 (Rating other than Red requires explanation and justification) |
· Improve Internal Program Services (RAG)
· Improve Service to the Public (RAG)
| Organizational Impact |
| 15 Point Scale – Key: Red = 1, Amber = 3, Green = 5 (Rating other than Red requires explanation and justification) |
· Personnel and Training (RAG)
· Scope of Beneficiaries/Cross-Functional (RAG)
· Quality of Work Life (RAG)
| Risk |
| 25 Point Scale – Key: Red = 1, Amber = 3, Green = 5 (Rating other than Red requires explanation and justification) |
· Schedule Risk (RAG)
· Cost Sensitivity (RAG)
· Technical Risk (RAG)
· Organizational Risk (RAG)
· Risk of Not Doing It (RAG) distribution guidelines
| Format |
| Written report with appropriate charts, diagrams, and tables. This Business (Mission) Case should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. |
Reports should be automated to the maximum extent possible and integrated into the ITSM Support Service at every opportunity.
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver report to the Government Service Portfolio Management Process Owner. |
SERVICE PACKAGE
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.3
| SERVICE PORTFOLIO MANAGEMENT |
| AS NEEDED |
Develop and deliver Service Package(s) for each new service, major change to a service or removal of a service or changes to the Service Package itself. The goal of the Service Package is to document the various levels of Utility and Warranty in Differentiated Offerings.
| References |
| ITIL Service Strategy |
Project Management Book of Knowledge GAO/AIMD-10.1.13 Assessing Risks and Returns: A Guide for Evaluating Federal Agencies’ IT Investment Decision-making DoDD 8115.01 Information Technology Portfolio Management
The following items should be addressed
| Package Name |
| Name of service package(s). |
| Service Owner |
| Responsible for service provisioning, service performance, and service improvement. |
| Customer Stakeholders |
| List organizations/people involved in requesting, defining, and funding the service. |
· Directorate-level sponsor(s)
· Customer Representative(s)
· Business Relationship Manager (BRM)
· Service Level Manager
· Financial Manager
| Business (Mission) Case |
| Include approved Business (Mission) Case. |
| Benefit/Cost Ratio |
| Measures the value of the system in dollar terms. This ratio is developed using the standard benefit-cost guidance. The higher the benefit/cost ratio, the better the score |
25 Point Scale:
· Ratio of <1 = 0 points
· Ratio of 1 = 1 point
· Ratio of 1.5 to 1.75 = 5 points
· Ratio of 1.76 to 1.99 = 10 points
· Ratio of 2.0 to 2.99 = 15 points
· Ratio of 3.0 to 3.99 = 20 points
· Ratio of > 4.0 = 25 points
| Estimated Service Implementation Cost |
| Cost to implement Service |
· Labor
· Materiel
· Hardware
· Software
· Licenses
· Maintenance
· Warranty
| Estimated Service Sustainment Cost |
| Cost to implement Service |
· Labor
· Materiel
· Hardware
· Software
· Licenses
· Maintenance
· Warranty
| Service Level Requirements |
| Non-technical requirements from the customer perspective, at a minimum: |
· Capacity/Performance
· Availability
· Security
· IT Service Continuity
· Incident Management
| Differentiated Offerings |
| Identify: |
· Core Service Package (CSP)
· Service Level Packages (SLPs)
| Service Acceptance Criteria – High Level |
| Include, at a minimum, high-level Non-Functional and Functional Requirements |
| Estimated Schedule |
| Notional dates and timeframes associated with this Service Package. |
distribution guidelines
| Format |
| Written report with appropriate charts, diagrams, and tables. This Service Package should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. |
Reports should be automated to the maximum extent possible and integrated into the ITSM Support Service at every opportunity.
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver package to the Government Service Portfolio Management Process Owner. |
NON STANDARD REQUEST ANALYSIS REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.3
| SERVICE PORTFOLIO MANAGEMENT |
| UPON DETERMINATION OF NON STANDARD REQUEST |
The Non Standard Request Analysis Report is used to determine the disposition of a non-standard service request. The N2ITSM Contractor will provides a recommendation to the Government for each non-standard service request.
The following items should be addressed
| Service Request ID |
| Service Request ID, customer submittal date, report submittal date, |
| Request Information |
| Identify requesting User and C4I Customer Representative by name and directorate |
| Request Description |
| This report ensures that the contractor (and subsequently the government) fully understands the nature of the requirement, or problem. This implies a minimum level of validation, analysis and interaction with the user/customer. If necessary, the contractor will update the problem description inside the service request. |
Since submitted non-standard Service Requests are validated by the Customer Representative, the intent is to have a very clear understanding of what the user/customer is requesting in the Service Request. Probing questions that clarify what, when, where, why, how, ability to fund, supporting strategic documentation (IPIL, DRRS, JMETL, etc…) will allow leadership to make educated decision in a short amount of time.
| N-NC Service Catalog & Service Asset Analysis |
| Is the request a service or service asset that is in the N-NC Service Catalog or Service Asset Catalogs? |
Based on the analysis performed, can this request be supported by existing services, or not? (answer should always be no, since a capability is being asked for not specific “brands”) Do similar services exist that provide any level of requirement needed?
Can this request be handle via any other A) level process? (IA/DAA, Circuit Activation, Service Owner (service improvement process or service standardization process) Item that may have been omitted in contract? (Service not in Service Catalog or existing service in the Service Catalog with no sustainment piece)
| Cost Indicators |
| Select One for Implementation: |
>$100K <$100K & >$25K <$25K No Cost ($0)
Select One for Sustainment:
>$100K <$100K & >$25K <$25K No Cost ($0)
| Level-Of Effort |
| Significant effort is required to perform this action (>90 days) |
Some effort is involved; however, it is not very technical in nature (>10 days and <90 days)
Little to no effort is required for this action (<10days)
Request Disposition Recommendation
* Can/Should a standard change be created for this type of request? Yes No* Can/Should a normal change be created for this type of request? Yes No
* Does not count toward the 35 per month Non Standard Request Analysis capacity, since it should have been diverted prior to develop a standard request.
Justification:
Recommend if this request can be delivered with a Normal Change or Needs to be submitted to the Government for C4 Integration Process.
Select One:
Normal Change (RFC) C4IP (Corporate Investment (Project>90 days and Costs>$100K and not lifecycle replacement) Non-Standard Process Model Other: _____________________
DISTRIBUTION GUIDELINES
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. The report should conclude with recommendations to improve the Availability Management Process. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver report to the Government Service Portfolio Management Process Owner. |
QUARTERLY ARCHITECTURE PRODUCTS AND UPDATES
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.2
| IT ENTERPRISE ARCHITECTURE |
| QUARTERLY |
Provide Enterprise Architecture artifacts data as a minimum required to support the following DoD Architecture Framework (DoDAF).
items to be addressed
| Quarterly |
| Architecture Diagrams (SvcV-1, SvcV-2, SvcV-6, SvcV-10) |
| Quarterly |
| Service View Products & Updates (SvcV-3, SvcV-4, SvcV-7, SvcV-8, SvcV-9) |
| Quarterly |
| System View Updates (SV-1, SV-2, SvcV-1, SvcV-3a) |
| Projects |
| Systems View Updates (SV-1, SV-2, Svc-3a) |
DistrIBution guidelines
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. |
| Classification |
| Unclassified. Prepare as FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience |
| Deliver report to the Government IT Enterprise Architecture Contracting Officer’s Representative (COR). |
SERVICE DESIGN PACKAGE
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.3
| DESIGN COORDINATION |
| AS NEEDED |
Develop and deliver Service Design Package(s) for each new service, major change to a service or removal of a service or changes to the Service Design Package itself.
| References |
| ITIL Service Strategy |
ITIL Service Design ITIL Service Transition Project Management Book of Knowledge (PMBOK) items To be addressed
| Package Name |
| Name of service design package(s). |
| Service Owner |
| Responsible for service provisioning, service performance, and service improvement. |
| Service Package |
| Include approved Service Package. |
| Service Design and Topology |
| Statement of Requirements (SoR) |
· Entry Criteria
· Exit Criteria
Diagrams:
· Network Topology
· Activity Diagrams
· Sequence Diagrams
· Entity Relationship Diagrams
Service Asset Listing
· New Acquisitions
· Re-provisioned H/W & S/W
| Project Management |
| · Milestones |
· Work Breakdown Structure (WBS)
· Schedule
· Gantt Chart
· PERT Chart
| Risk Analysis |
| · Vulnerabilities |
· Threats
· Probability
· Mitigation
| Capacity Plan |
| · Capacity/Performance Incident Response |
· Event Monitoring, Alerts, and Thresholds
| Availability Plan |
| · Availability Incident Response |
· Event Monitoring, Alerts, and Thresholds
| Security Plan |
| · Security Policy |
· Security Incident Response
· Event Monitoring, Alerts, and Thresholds
| IT Service Continuity Plan |
| · Testing Procedures |
· Test Schedule
· Event Monitoring, Alerts, and Thresholds
| Test Plans |
| Overall plan for testing design and criteria. |
| Financial Management Plan |
| Implementation Costs |
· Build and Test Costs
· Deployment and Test Costs
· Training Costs
· Government training/certification
· End-user/Executive Overview
· Contractor (GOTS only) Annual Sustainment Costs (including labor)
· Warranties
· Software Assurance
· H/W Technical Refresh
· Maintenance
· Specialty/Low Density Skill Sets distribution guidelines
| Format |
| Written report with appropriate charts, diagrams, and tables. This Service Design Package should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. |
Reports should be automated to the maximum extent possible and integrated into the ITSM Support Service at every opportunity.
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience/Forum |
| Deliver package to the Government Design Coordination Process Owner |
MONTHLY SERVICE LEVEL MANAGEMENT REPORT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.2
| SERVICE LEVEL MANAGEMENT |
| MONTHLY |
Service Level Management monthly report should include details of the service levels achieved in relation to the target contained within the SLAs. This report should contain detail of all aspects of the service and its delivery, including current and historical performance, breaches and weaknesses, major events, changes planned, current and predicted workloads, customer feedback and improvement plan and activities.
items to be addressed
| KPI’s & CSF’s |
| Contractor shall report all performance pertaining to this process using the Operational Metrics (OMs), Key Performance Indicators (KPIs) and Critical Success Factors (CSFs) identified in the PWS per this process. |
| Customer satisfaction score/rating by service |
| Provide Customer Satisfaction level information by including, at a minimum, the following information in the monthly Service Level Management Report: |
· Number of User/Customer surveys sent
· Number of User/Customer surveys responded to
· Average User/Customer survey score (total and by question category)
· Average queue time waiting for Incident response
| Number of SLAs/OLAs in renegotiation |
| Provide, by name, SLAs/OLAs that are in renegotiation due to changing service level requirements. |
| Number of SLAs requiring changes |
| Indicate, by name, renegotiated SLAs/OLAs with newly agreed upon terms and the associated Request For Change number. |
| Number of SLA issues logged |
| Number of monitored Services/ SLAs, where weak-spots and counter-measures are reported. |
| List of SLA Targets missed |
| List SLA performance targets missed. |
Distribution GUIDELINES
| Format |
| Written report with appropriate charts, diagrams, and tables. This report should contain an executive summary written in non-technical language. The main body of the report should be prepared for IT Service Managers with sufficient technical rigor to enable solid technical analysis. |
| Classification |
| Unclassified. Unless impractical, the report should be prepared FOR OFFICIAL USE ONLY, with classified annexes as required. |
| Audience |
| Deliver report to the Government Service Level Management Process Owner. |
SERVICE LEVEL AGREEMENT
| N2ITSM PWS SECTION |
| SUBTASK |
| OUTPUT # |
| PROCESS/FUNCTION |
| FREQUENCY |
2.2
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .