Thursday, September 20, 2012

SharePoint Problem & Change Management Procedures Governance - Consulting Best Practices Example

I.T. – SharePoint Problem and Change Management Procedures

I.      Introduction
The purpose of this document is to define the procedures used to manage SharePoint 2010 / 2013 support requests, assign resources to those requests,and implement solutions to those requests, as well as provide ongoing support to ensure reliability and availability of information systems.These procedures apply to all components of the organization’s information systems and should be understood and followed by all I.T. personnel.

II.     Terminology
I.T. has defined the following categories for support requests:
Problems:  Problems are failure-oriented– existing components of information systems are failing to provide results they were designed to provide, requiring problem analysis and resolution activities by I.T. personnel.  As a general rule, problems reported require immediate assessment of severity and impact, and may require immediate resolution.

Changes:  Changes are development-oriented– existing components of information systems need to be modified or upgraded, or new components need to be added, to provide results that existing components were not designed to provide, requiring business \ technical \ operational analysis and development activities by IT personnel.

General Support:  General Support issues are primarily education-oriented – they involve showing the user how to perform a particular function in a system.
Authorization:  Authorization issues are generally security-oriented – access to a particular system or function needs to be granted, modified, or removed.
-----------------------------------------------------------------------------------------------------------------
*Problems, Changes, General Support, and Authorization requests are collectively referred to as Incidents.*

Ongoing Support is defined as activities required of I.T. personnel to operate and maintain the various technical components of the organizations SharePoint environment.

General Roles and Responsibilities – SharePoint I.T. Change and Problem Management

The role of the Help Desk is to receive and record problem or change requests from the business staff, enter them into the Resolve tracking system, and assign the requests to support personnel or management for resolution.

Support personnel, including members of the Systems, Application Development, and Technical Support staffs are responsible for seeing the incident through to completion and maintaining the status text and other key information in the Resolve incident record.

Management is responsible for monitoring the level of support provided by the staff and seeing that incidents are prioritized with respect to their importance to the organization. (Daily review, weekly meetings)

III.     Resolve System (Name of Program will vary per the organization)

The "Resolve system", an change control or change management application (or internally developed solution), is the control mechanism used to enter, update, track, and report on problems and changes.  All incidents are to be logged into the "Resolve System" and is to be used to assign and maintain status information on those incidents.  Normally, incidents are entered into the "Resolve System" by Help Desk personnel in response to a request or problem reported by business unit personnel.  However, other I.T. staff will occasionally enter problem incidents directly when they discover an issue before it is noticed by business units.  Once in the “Resolve System", certain fields are expected to be maintained and updated on a periodic basis. 

* These processes and expectations are described in detail in following sections. *

IV.    Managing New "Resolve" SharePoint Incidents
         A. Entry and Assignment Incidents
All incident types are first routed to the Help Desk for entry into the“Resolve System” and assignment according to the following procedures:

Incident Type
Reporting Procedures
Assignment
Problem
·    May be reported by any staff member experiencing a problem
·    Does not need to be submitted by or pre-authorized by an Application Data Owner
Help Desk assigns via Subject Matter Expert (SME) list and notifies assignee
Change
·    Submitted in the form of an   Action Memo
·    Must be submitted by or pre-authorized by an Application Data Owner
Help Desk gives to manager responsible for affected component as denoted in the SME list; manager assigns to staff
Authorization
·    Submitted in the form of a User
Account Request
·    Must besigned by the requestor, the requestor’s supervisor, and the Application Data Owner of the affected system
Help Desk gives to Security / Disaster Recovery Coordinat or for approval, who then forwards to applicable support staff
General
Support
·    May be reported by any staff member
·    Does not need to be submitted by or pre-authorized by an Application Data Owner
Help Desk assigns via the SME list and notifies assignee

·    In rare cases, it may be necessary to first contact technical or application support personnel directly before calling the Help Desk.  In those cases, it is the joint responsibility of the reporting user and of the actual technical / application support personnel to ensure that the Help Desk is also informed of the support issue.

·    Once assigned, the assignee is the“owner” of the incident, responsible for initiating the action and involving the other resources necessary to resolve the incident.

·    Vendor Assignments– The vendor may be included as an assignee on Resolve records that require some action on the part of the vendor.  In the cases, the SME responsible for the issue should also be included as an assignee, representing the SME’s responsibility for “managing” the vendor on this issue.
 
B. Establish Initial Priority
The initial priority setting is set by the Help Desk using the table below and entered into the Priority (indicator – custom per organization) data element of the“Resolve System”record.   However, as the Help Desk often has limited information about the incident, management or the assignee will need to update the priority setting once additional information has been obtained.
 
Priority
Order

Priority Name

Priority Description
1
Highest – Problem
System failure, critical operations impact, no fallback available
2
Very High – Problem
System failure or major error, critical operational or user impact, usable with severe restriction
3
Highest– Project / Change
Urgent Need for new / modified functionality and / or data, no / poor methods currently available, audit issue
4
Very High– Project / Change
New / modified functionality and / or data needed, no / poor methods currently available
5
High– Problem
Program error but by pass or fallback available, not critical, usable with limited functionality
6
High– Project / Change
New / modified functionality and / or data needed
7
Medium– Problem
Minor program error, not critical, circumvention possible
8
Medium– Project / Change
New / modified functionality and / or data needed but not urgent
9
Low
Minor fix or change requested, not urgent
10
Very Low
Very minor fix or change requested, not urgent
 
* Authorization and General Support incidents are prioritized as Changes. *
 
C. Response Times
Problems are to be assessed for criticality by the I.T. staff on the day they are reported, and the reporting person will be contacted regarding the course of action to be taken.  Severe problems with critical production systems will be given top priority, and addressed according to Critical Problem Resolution Procedures later in this document.
 
V.     Managing Open "Resolve" (SharePoint) Incidents
Assignees and managers have responsibilities for managing "Resolve" (SharePoint) incidents:

Responsibility
Frequency
Activity
IT Management
Daily
Review new incidents entered the previous day, and ensure that they are categorized correctly, assigned to the right individual, prioritized appropriately, and receive special attention if necessary.
Weekly
Meet with staff members, either in a staff meeting or individually, to review all open incidents.
Monthly
Review statistical reportson Resolve incidents prepared by the Planning and Resource Manager.
Quarterly
Review of closed incidents, evaluating the number and types of incidents closed, performing trend analysis
As Needed
Adjust the Priority field, to reflect a combination of severity,  need, and workorder.
IT Staff
(Assignee)
Problems–by
8:30 a.m. the
following day
Other Incidents
–per
prioritization by
I.T. Mgmt.
Update the Status field from Initial to Open.  Contact the request or to initiate action.
Asneeded
Update the information in the Resolve record, particularly the Status and Status / Resolution Text fields, to reflect actions taken, decisions made, discussions with vendors or business units,etc.
IT Operations
Daily
Produce report of  new Resolve Incidents  from previous day
 
See Critical Problem Resolution Procedures for special treatment of critical problems.
 
VI.    Closing a Resolve Record
The assignee should close the Resolve record when all work is complete on the incident. This involves:
·    Changing theStatus field to Closed
·    Entering descriptive text of the action taken in the Resolution text field
·    Ensuring that all other fields within the Resolve record have an appropriate value
 
VII.   Production Turnover Process and the Update Meeting
A. Production Turnover Process
If the actions associated with a Resolve record will result in a change to any component (excluding security) within our production environment, then that change needs to be implemented through the Production Turnover Process:

Responsibility
Activity
IT Staff
Complete the appropriate turnover documentation (as detailed in the next section), including all appropriate signatures.
IT Staff with
Management
Review the turn over and related documentation and determine whether the change needs to be made on a regular (future scheduled event, immediate change not required, standard implementation on Thursday) or irregular (immediate change required to resolve a problem requiring immediate attention) basis.
IT Management
Retain the documentation for the next update meeting.
IT Management
Hold Update Meeting weekly to review all submitted turnover documentation for regular updates for implementation following the Update Meeting and irregular updates implemented since the last update meeting. Distribute turn over documentation to the manager of the group responsible for implementing the change in the production environment (usually Operations).
IT Operations
Issue the Update Letter from copies of the Implementation Turnover Reportand distributeto users as notification of changes to the SharePoint environment.
IT Staff
Implement changes in the production environment, sign the I.T. Implementation section of the Implementation Turnover Report and forward all turnover documentation to Operations for retention.
IT Operations
Image copies of all turnover documentation.
 
B. Production Turnover Documentation
There are three types of turnover documentation:
 
Implementation Turnover Report– The Implementation Turnover Report must be completed for each change to the production environment, and it contains all critical information about the planned change.  Instructions for completing this form are found in the document Implementation Turnover Procedures.This is required for all changes. For large, strategic, or high-risk projects, a draft of the Implementation Turnover Report, including a list of all components affected, is to be presented to the Technical Support Director at the Update Meeting the week before scheduled implementation.  This is to give the Technical Support Staff time to plan the implementation.

Validation Procedures– This includes documentation of how the change was tested, and may include a test script, screen prints, or a narrative description of the validation process.  This is required for all changes.

SDLC Checklist– This is a checklist covering the major actions associated with the SDLC.  This is required only for strategic projects or “high-risk” changes.
 
C.  User Sign-off
User sign-off is required on all Implementation Turnover Reports, signifying three critical aspects of a valid, controlled environment:
·    the user’s acceptance of the fix / change (via test results)
·    the users’ approval to implement the fix / change
·    the users’ awareness that the fix / change will be implemented

The Authorized User field on the Production Turnover Request must contain the signature of the appropriate Application Owner.  Note that if more than one owner is listed for a SharePoint application, each owner must approve. Turn over requests lacking these signatures will be denied.

VIII. Critical Problem Resolution Procedures

A. Business Hour Procedures
The following procedures should be used for critical problems.  A critical problem is one that would meet the criteria for a Highest Problem or Very High Problem priority rating in Resolve, as defined earlier.

Responsibility
Timeframe
Action
Help Desk
Immediately
Assign theproblem and notify the SME immediately via phone or face-to-face (e.g., using a method other than e-mail to ensure the SME is aware of the issue)
In the same manner, notify the supervisor of the SME and  the I.T. Director (or similar position within your organization)
Subject Matter
Expert
Immediately
Begin assessment of the problem; determine recent changes to the affected system.
30 minutes
If a solution is not determined, contact the vendor of the affected system and open a support ticket.
Every 30 minutes
Provide a brief status update to supervisor.
Upon resolution
Update the Resolve incident record with a clear description of the cause and resolution.
IT Management
Immediately
Determine if resources in addition to the assignee are needed to troubleshoot the problem.
Determine if Business Continuity Plan is to be initiated.
Determine if notification to internal or external customers is appropriate, and if so, coordinate with the Help Desk and Communications.
Ongoing
Monitor the efforts of the staff; provide appropriate information to senior management regarding the issue; continue to assess if there is a need to implement the Business Continuity Plan.
Upon resolution
Determine appropriate notification to internal and external customers.
Complete a Critical Problem Analysis document with input from staff involved in there solution of the problem.

Note:  Often a problem appears to be minor, but is determined to be a critical problem after research by the SME.  In such cases, it is the responsibility of the SME to notify his / her supervisor and the IT Director (or related role within the organization) as soon as the incidentis recognized to be a critical problem.

B. Non-Business Hour Procedures
The following are the procedures to be followed by Operations personnel and Subject Matter Experts for resolving critical non-Business Hours support for SharePoint.

Responsibility
Timeframe
Action
Operations
Immediately
Enter a Resolve problem record describing the problem.
Determine the Subject Matter Expert using the Subject Matter Expert document and considering the IT Vacation Calendar in Microsoft Outlook.
Contact the On-Call Support Provider using the home and / or cell phone numbers listed in the I.T. Staff contact folder in Outlook.  If contact is not made, leave a message on both the home answering machine and cell phone voicemail.  Then, immediately contact the Secondary SME or the Responsible Manager.
Upon contact with SME or Manager
Describe the problem and identify the Resolve problem numberto the SME or Responsible Manager.  Provide the text of any error messages as well as any other pertinent information
Until problem resolution
Work with the SME and / or Responsible Manager to resolve the problem.  This may involve executing commands on the affected system and conferencing in other support personnel, managers, or vendors.

B. Non-Business Hour Procedures (continued)
Subject Matter
Expert
Within the first 30 minutes
Research the problem and determine the impact and scope of the issue and decide if an immediate resolution is needed.
Provide Operations with an estimate of the time and resources needed to fix the problem. If necessary, perform appropriate escalation steps (C).
Assess the need for vendor support.  If necessary, contact the vendor of the affected system and open a support ticket.
Every 30 minutes until resolution
Provide a brief status update to Operations staff.
Reassess the need fo rescalating the problem, particularly if initial time estimates for resolving the problem prove to be insufficient.
Reassess the need for vendor support, if not already utilized.
Upon
Resolution
Communicate resolution to Operations, directing their efforts as necessary to copy files or promote programs, and communicating appropriate restart / rerun procedures.
If problem had been escalated to management, notify management of the resolution.
Update the Resolve record with details of the problem and its resolution.
IT Management
Upon initial escalation
Determine if additional resources are needed to troubleshoot the problem.  Determine if the Business Continuity Plan should be initiated.
Ongoing
Monitor the efforts of the staff and provide appropriate information to Senior Management regarding the issue.  Continue to assess if there is a need to implement the Business Continuity Plan.
Upon resolution
Complete a Critical Problem Analysis document with input from staff involved in there solution of the problem.
 
C. Non-Business Hour Escalation Steps

EscalationStep
To be taken if:
Contact Responsible Manager & Operations Supervisor
Ifresolution is estimated to require more than 2 hours, or if SME is unable to identify the problem or provide a time estimate for resolution within the first half hour
Contact Technical Support
Director
If resolution is estimated to require more than 3 hours, orif SME is unable to identify the problem or provide a time estimate for resolution within the first half hour
Contact IT Director
Ifresolution willrequirean extended timeperiod, resulting in a significant impact to next business day operations.
 
D. Non-Business Hour Support Standards
The Subject  Matter Expert has specific responsibilities related to non-business hour support, including:

·    Being available during peak processing time, which is normally 6:30 PM– Midnight, although processing problems may increase this window.

·    Responding to missed calls from Operations within one-half hour.

·    Taking ownership of the problem, meaning that once a SME is contacted for a specific problem, that person “owns” the problem and is responsible for getting the right people involved for resolution of the problem.

·    Determining whether the problem requires immediate or next-day resolution.
 
Immediate vs. Next Day Resolution
The SME may deem it appropriate to address minor problems the following morning. If major processes are affected (those that may impact the organization’s users or process critical information), the Systems Manager and Technical Support Director must be notified and approve of a next day resolution decision.

Extreme caution should be used in making this decision and accountability for the impact of the decision rests with the decision-maker. Thus, if in doubt, fix the issue that night.
 
Issues that must be addressed immediately include (but are not limited to):
·    System "down" issues and
·    Issues affecting information reported to customers the next day.
·    Issues affecting internal reporting critical to the operation of the organization.
 
Remote vs. On-Site Resolution
Until the situation reaches Escalation Step 2, the Subject Matter Expert has the option of addressing the issue remotely (via appropriate network configuration on home / personal PC) or on-site.  Once an incident requires Escalation Step 2, the Responsible Manager will determine whether the incident can be better resolved through on-site attention by the (SharePoint) SME.