Jim and I will be giving our second EDUCAUSE Southeast Regional Conference presentation tomorrow, on Creating a Change Advisory Board. Our presentation materials are posted on EDUCAUSE and are also below.

Two more CAB-related documents are now available at the bottom of the change management page.

We just posted two additional templates on the site:

• Technology Evaluation Form, posted under Service Portfolio Management. We use this form to evaluate a technology request to determine high-level risks.
• Service Acceptance Criteria, posted under Change Management. We use this template as a checklist to go through before any significant service modification goes live.

Our change management procedure was created out of audit concerns. We wanted to ensure that changes to productions were properly approved and documented. Many Universities adopt change management for the same reason--to satisfy audit requirements.

Like many organizations, we have been trying to understand how project management and (service) change management interact. There are a few confusing components:

• Project management texts sometimes use the term "change management" when referring to "project scope change management" aka controlling the scope of a project.
• Projects need governance. Change management also facilitates governance decisions.
• Very early on, it can be hard to determine if something is a project or not.
• Projects have products or deliverables, and these deliverables often follow a change management process.

Three presentations submitted by Wake Forest University IS staff have been selected for the 2009 EDUCAUSE SE Conference in Atlanta, GA on June 1-3:

“Sustainable Governance: Transforming IT from an oral to a written culture” will be presented by John Borwick and Jim Love discussing the value of establishing a formalized management process for departmental governing documents.

Below are notes from today's itSMF USA Higher Education SIG round table conversation.

Predecessors/Before You Begin

Change categorization is an important component of change management. This page assumes an understanding of the overall "change lifecycle" as defined in ITIL's change management process.

Change categorization

One of the activities in ITIL v2's "Change Management" process is "Change categorization" (section 8.5.4 of Service Support). This v2 activity is a component of ITIL v3's "Assess and evaluate change" activity (Service Transition section 4.2.6.4).

Categorization allows changes to be processed differently. For example, one type of change might need to be reviewed by the CIO, and another type might just need a local authority (such as a manager) to approve the change. Categorization can also ensure appropriate data, needed for subsequent activities and/or reporting, has been added to a request for change (RFC).

The "change management lifecycle" is the high-level activities followed in the change management process. It seems like, in practice, there are two definitions for a change's lifecycle: either just the hand-off to production, or the entire gamut from idea through implementation or closure. We here at Wake Forest University are transitioning from the former to the latter, as we refine our change management procedure.

I just added links to a few EDUCAUSE presentations on ITIL and change management, and also linked to a few Universities' service catalogs.