Verbatim header image 2

Change, Configuration Management and Release – a holistic approach

July 7th, 2009 · No Comments

21 delegates from large organisations attended a workshop on Change, Configuration Management and Release – a holistic approach on the 1st July at Warwick Racecourse.

Key points

  • You can’t do release management if you don’t have change management

  • A change is a deviation from the current position
  • A release is a collection of components to achieve a change objective, e.g.
  • A single desktop with all its hardware, software and documentation
  • A complete payroll package
  • Use KPIs to help demonstrate the value of change management
  • E.g. emergency changes

  • Use financial data to demonstrate the value of release management
  • E.g. real cost savings made by using a release strategy

  • Export change processes for non-IT use in the business
    Cite a catastrophic event (e.g. something similar to Y2K) to (help) justify configuration management
  • There are no benefits for standalone configuration management – it is an enabler.
  • Use “naming and shaming” to help keep CMDB items accurate
  • Include decommissioning as part of release and change management
  • What are you going to do with those soon to be redundant servers?
  • When candidates are approved for a future release, raise a change record. Support this with the rule/process that developers can cut no code without a change number.
  • Use coded and searchable fields as much as possible in change records. Free text is much more difficult to search and report on.
  • Have two levels of notified parties in the change process. A change approver must explicitly approve or reject a change. A change reviewer (or some other title for a non-approver) can comment or object (even reject), but if she or he takes no action or makes no comment, the change can go ahead.
  • Keep KPIs on change approvers and change reviewers – and take action where people don’t perform the role.
  • Don’t hold configuration data in more than one place unless you really have to.
  • No one size fits all – e.g. delegates had a variety of philosophical approaches to the need for a change record for a server reboot. Business communication is the key.
  • Standard and minor are not the same.
  • Get suppliers to use your change system and CMDB – contractually.
  • Discovery tools WILL impact the network.

Tags: Applications · Applications · Architecture & Strategy · Infrastructure · Operations & Service Management · Programme & Project Management · Technologies

0 responses so far ↓

  • There are no comments yet...Kick things off by filling out the form below.

Leave a Comment