SharePoint 2010: Cincinnati Bell’s Change Management Application

About the Company

Cincinnati Bell, Inc., is a leading provider of Home Phone, High Speed Internet, Wireless and Digital TV services to consumers and businesses in the Greater Cincinnati Area and its neighboring suburbs in Ohio, Kentucky and Indiana.

The Challenge

For years, Cincinnati Bell’s IT Change Management process consisted of posting messages of upcoming changes to a group message board. IT personnel weren’t able to view change events on a calendar or to sort them by execution status or priority. This made it difficult for IT Team members to avoid scheduling conflicts, for the organization to stay aware of upcoming changes, and for management to track failed change attempts. Changes were reviewed by a Technical Review Board (TRB) and a Change Advisory Board (CAB), but the process of reading through the unfiltered list of changes produced less-than-efficient meetings.

Cincinnati Bell needed both to improve the business process around change management and to develop a tool to help manage changes. There was no budget for an Enterprise Change Management tool, and heavy customizations were desired, so SharePoint was chosen as a good platform for the application.

The Change Management team had the following requirements:

  • Keep all Requests for Change (RFCs) in one list for easy searching, sorting and tracking
  • Provide a calendar that shows all changes, color-coded to distinguish RFCs by status: ready for approval, ready for execution, completed or cancelled
  • Allow changes to be entered in draft status and edited later, to help ease the lengthy process of filling out all the fields
  • Provide a custom form for each of several roles (TRB, CAB, executors and others) that allows them to update existing RFCs with information specific to their duties
  • Provide CAB and TRB views that sort and filter RFCs that are ready to be reviewed in each of their respective meetings
  • Provide additional reporting views that allow management to track emergency changes, cancelled RFCs, failed execution attempts and more

Additionally, CBTS had to work within the following limitations:

  • The Change Management System needed to be implemented in the Foundation version of SharePoint 2010
  • It needed to be created without customization, InfoPath forms or automated workflows

The Solution

I implemented CBTS’s cha.,nge management system in SharePoint 2010 foundation edition per requirements. All RFCs are entered into and maintained in one custom list. A calendar view on the list consolidates other views to provide color-coding by status.

In order to provide custom form fields for various roles without the benefit of InfoPath, I created custom content types for each stage of the RFC lifecycle: draft, submit, validate, pre-approve, TRB review, CAB review, execute, hold, cancel and others. Each content type inherits from the last, adding required fields pertaining to the role that would handle the RFC in each stage.

I then created 22 views to facilitate TRB and CAB reviews, execution of changes, management reporting and more. Strategic page designs and groups of links help teams step through the process and track changes.

Technologies used:

  • Custom list with custom fields
  • Calendar with color-coded overlays
  • 13 Custom content types with inheritance
  • 22 custom views

About the author