SharePoint Problem & Change Management Procedures Governance – Consulting Best Practices Example
I.T. – SharePoint Problem and Change Management Procedures
The purpose of this example “document” from EPC Group 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.
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”, a 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 UserAccount Request
· Must be signed by the requestor, the requestor’s supervisor, and the Application Data Owner of the affected system
|Help Desk gives to Security / Disaster Recovery Coordinate or for approval, who then forwards to applicable support staff|
|GeneralSupport||· 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.
|PriorityOrder||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:
|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 reports on 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 work order.|
|IT Staff(Assignee)||Problems–by8:30 a.m. the
|Update the Status field from Initial to Open. Contact the request or to initiate action.|
|As needed||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 the Status 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 withManagement||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 Report and 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 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.
|Help Desk||Immediately||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 MatterExpert||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 incidents 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.
|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 number to 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 MatterExpert||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 for re-escalating 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.|
|UponResolution||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
|Escalation Step||To be taken if:|
|Contact Responsible Manager & Operations Supervisor||If resolution 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 SupportDirector||If resolution is estimated to require more than 3 hours, or if SME is unable to identify the problem or provide a time estimate for resolution within the first half hour|
|Contact IT Director||If resolution will require an extended time period, 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.