Dave Howard from Toyota Financial Services gave this talk on release management.
At the moment, I can't find my notes.  The main thing I remember is that they have created a release process for any new environment.  For each environment needed for a project (e.g. dev, test, and prod), you have to go through a process of architecture design creation and review, specification creation and review, and finally the actual build.

Predecessors/Before You Begin

Release and deployment management is very closely related to change management, and arguably a successor to a good change management program.  Please make sure you understand change management before diving into release management.

Today Jack Probst presented to the itSMF Higher Education Special Interest Group (SIG). The presentation is to be posted on the SIG web site. The CMDB and the service catalog are very closely related. The CMDB starts with services anyways, and the service catalog is the list of services. Potential service catalog categories:

• Application Based Services (e.g. Customer Support Services)
• Hosting Services (e.g. Data Center services)
• Desktop Services (e.g. mobile devices)
• Shared Services (e.g. data LAN)
• IT Professional Services (e.g. Service Management, Procurement)

Cross-posted to http://www.educause.edu/blog/borwick/SummaryRibbonsintheSkyACustome/173072.

Julie Leary and Amy Martin from Towson University gave this presentation, "Ribbons in the Sky: A Customer-Focused Approach to Implementing Change."

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.

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.

As I mentioned last fall, we manage our continual service improvement program quarter by quarter: each quarter we select certain critical projects, and then as we have time we "pick up" other work and add it to our list.

Separate but related to this concept of quarterly improvement "releases," we have also created a "semi-annual governing document review." Twice a year we get several relevant staff members together to review our "governing documents"--our policies, standards, and procedures. We don't make major changes, but we make sure that everything makes sense together, uses the latest template, etc.

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.