The poetry of Change Management

In my other life I'm a poet. Last night I was working in my studio and one of my studio-mates (who works in education) said I must get mixed responses from other writers when I tell them I work in IT. Let's face it, IT is saddled with clichés of geeky, pen-protector, idiot-savant, asperger types and tends to sound boring to non-IT people (partitioning servers, load balancing the Alteon and service oriented architecture doesn't ignite passion in everyone's cockles). This is a shame because most of the IT people I work with are smart, funny and engaging, and I would like to put to you that the successful provision of IT is the same as writing a successful poem: they both solve problems that, on the surface, involve plugging complex pieces of machinery (words vs. computers) into each other to build a system greater than the sum of its parts. For example this isn't very inspiring:

depends, so, wheel, glazed, rain, with, a, much, barrow, upon, beside, water, chickens, white, the, red.

But then William Carlos Williams turned it into this:

So much depends
upon

a red wheel
barrow

glazed with rain
water

beside the white
chickens.

Below the surface both poetry and IT involve emotions, philosophies, history and territories that need to be negotiated if you want to have a successful 'end product'. As Service Delivery Manager my job is about creating IT management processes that deliver products and services to our customers. One of the primary problems I believe befalls IT is the 'softer' or people-centric parts of these processes are rarely considered during their design. After that staff are 'stuck with it' and no process will be successful without their investment. So these are my suggestions on how to include people when creating a successful IT management process.

Use a Framework

Most IT shops will base their practice on an accepted IT framework. At the Library we have adopted ITIL (Information Technology Infrastructure Library) which is an IT framework developed by the UK Government (and then sold worldwide through certification programmes for what, I assume, is large profit). A framework is a 'conceptual structure' that helps you decide which processes you need and in what order. ITIL is just one of many frameworks so you need to find one that suits your organisation. But why do I need one? I hear you ask. By using a framework your organisation can benchmark its practice against other similar organisations and leverage off the work of other people. Less work, more gain, something to measure your gain against.

Geekily, I really like ITIL and I am a certified practitioner. ITIL has been adopted internationally, even recently finding a footing in America. It has been through a series of versions (currently v.3) during which it has been expanded and refined from a framework to more of a service lifecycle 'straw person'. It is sensible, able to be bundled for smaller organisations and a good starting point for the development of common IT terms. As a taster here are the high level processes involved in v.3:

  1. Service Strategy
  2. Service Design
  3. Service Transition
  4. Service Operation
  5. Continual Service Improvement (and then back to Service Strategy)

Build your processes to suit your organisation

My first task as Service Delivery Manager was to implement Change Management, a process by which changes to production or 'live' systems are put through an approval and risk assessment process, before being rolled into production. CM is part of 'Service Transition' and involves documentation and consultation with both the technical and development teams. It also involves a lot of documentation and monitoring on my part. I ask a lot of questions and bother a lot of overworked people. Gosh, am I popular.

As an organisation we are toddlers in regards to ITIL (which has twelve key processes, of which we currently do five in a lightweight but appropriate way). In my opinion Change Management is one of the most valuable because it quickly highlights both technical and communication (people and documentation) issues in your organisation. Change Management didn't exist before I started so it was up to me to make it work. But trying to fit a hexagonal peg into a triangular hole will just make for grief. To suit our organisation we rolled Change and Release together (they are different processes in ITIL) because, for our size it was sensible.

Tell people what is in it for them

This is really where the poetry is needed, or at least some sort of fiction. Changing the way an organisation works, especially when it means more work for staff, will never be popular. It is hard to get people to invest in "uptime" or "protecting our production systems". Let staff know what benefit they will get out of following the process.

Have a trial period and be responsive to feedback

This allows staff to give feedback at the end and will give them ownership of the process. Hours were spent in the office of our Lead Developer and Web Manager 'discussing' the finer details of the process. (The sticking point, in the end, was around agile development. ITIL as a framework doesn't recognise that somewhere between strategy, design and transition there will actually need to be some development. Having come from the digital development team this was very obvious to me from the start - although my ITIL tutor waved his hand dismissively and said "oh, that happens somewhere else" - so I had to make sure our CM process would support the agile development methodology desired by the developers.) Because of dialogue, I changed the process substantially based on feedback and it is much better for it. We now have a simple document, the Change Checklist, that allows for both large and small changes.

Be responsive but meet your goals

There is no point in pleasing everyone if the process doesn't meet its original goals. At some point you have to implement and know that you have done the best you can and I think we have done reasonably well.

So here is a poem about Change Management:

So much depends
upon

the green change
checklist

reviewed by the
Change Manager

beside the Enterprise
Architect.

By Sarah Jane Barnett

Sarah is a writer and reviewer, and managed change as a service manager at the Library.

Post a Comment

(will not be published) * indicates required field

Be the first to comment.