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

By Errin O'Connor posted 09-20-2012 06:15


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 ageneral 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



·    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


·    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


·    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



·    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 Name


Priority Description


Highest – Problem

System failure, critical operations impact, no fallback available


Very High – Problem

System failure or major error, critical operational or user impact, usable with severe restriction


Highest– Project / Change

Urgent Need for new / modified functionality and / or data, no / poor methods currently available, audit issue


Very High– Project / Change

New / modified functionality and / or data needed, no / poor methods currently available


High– Problem

Program error but by pass or fallback available, not critical, usable with limited functionality


High– Project / Change

New / modified functionality and / or data needed


Medium– Problem

Minor program error, not critical, circumvention possible


Medium– Project / Change

New / modified functionality and / or data needed but not urgent



Minor fix or change requested, not urgent


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:




IT Management


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.


Meet with staff members, either in a staff meeting or individually, to review all open incidents.


Review statistical reportson Resolve incidents prepared by the Planning and Resource Manager.


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



8:30 a.m. the

following day

Other Incidents


prioritization by

I.T. Mgmt.

Update the Status field from Initial to Open.  Contact the request or to initiate action.


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


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:



IT Staff

Complete the appropriate turnover documentation (as detailed in the next section), including all appropriate signatures.

IT Staff with


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 distribute to 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 theTechnical 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 acceptanceof 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.




Help Desk


Assign the problem 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



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


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.


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.






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


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.



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.


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


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


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.

#Collaboration #SharePointProblemManagement #SharePoint #SharePointHelpDesk #SharePointChangeManagement #SharePointHelpTicket #SharePointConsulting