Collecting and Organizing Information about Services

Signpost -- Where to?I’ve recently started a small service management program for my department. Because it’s a one-man effort for now, I’m mostly focusing on collecting information to organize in a service portfolio. My goal is to collect enough data about our services so I can write get some common descriptions written, approved, and filed.

Like most early-stage efforts of this sort, I’m not yet using a service management tool to categorize the information. As I’ve started conducting research about service management programs at various universities, it’s struck me how common it is for departments to continue using spreadsheets to capture and organize service data. I suppose it’s faster to update an Excel file than to work in a database.

My first set of considerations with developing a service portfolio was figuring out a basic organizational structure. As is the case with most IT services, certain services and tools can be grouped together in a logical fashion. For the moment, I’m using fairly broad categories and focusing on customer-facing services. It made sense to handle those first because they describe customer value more readily and can be defined more quickly. They’re also easy to refine later in the process.

At first, I adopted a very simple numbering scheme and documentation format for service descriptions.

  • Title: Svc-001
  • Name: Technology Enhanced Classrooms
  • Description Details: [one or two paragraph broad description, followed by a series of bullet points outlining specifics]

The format was pretty basic and didn’t address change management needs. It didn’t take long before I realized the inherent flaws in this scheme. I revised it just a bit.

  • Title: Svc-01-001
  • Name: Technology Enhanced Classrooms
  • Description Details: [one or two paragraph broad description, followed by a slightly longer series of bullet points outlining specifics]
  • Changelog: [running list of bullets with dates and change details]

This format has its flaws as well, and I intend to revise the scheme further. As I’ve started using these descriptions on a frequent basis, I’ve realized a good service portfolio entry needs at least:

  • service name,
  • a logical numbering scheme for organization,
  • organizational unit that owns the service (ideally just one that’s actually RACI accountable),
  • owner of the service,
  • service description,
  • hours of operation,
  • regularly scheduled maintenance window(s),
  • underpinning services,
  • services underpinned by this service,
  • and some form of version control for the service portfolio entry (possibly integrated with the numbering scheme).

Most full-featured service management programs will collect far more information and make sure services are linked together in a meaningful way. As I mentioned above, using spreadsheets to manage a service portfolio can be difficult because of the inability to contextualize services. If one service fails, how can you tell what other services are impacted if you can’t readily tell what services are linked to it?

As I develop this project more, I intend to explore using Microsoft SharePoint as a means to link all of this data together.