Serio Blog

Monday, 27 Aug 2007

This week, I’m going to look at how you go about creating your first Change Plan Template. Before that, it’s probably time for a recap.

I’ve been blogging about Change Management recently. The recent posts have covered subjects such as Change Management Definitions, Change Management Scope and Change Management Process, all in an effort to ‘set the scene’.

The Change Plan Template I mentioned above this the name we give to the whole process you enter into Serio – it defines the tasks, what is meant to happen when, standard times, exception handling – everything you would expect to be included in a standard Change. As always, for full information and documentation, please consult the HowTo guide which is distributed with Serio products – you’ll find an entire book there documenting the Change Management subsystem.

There seems to be a temptation to simply sit down in front of the Change Explorer in Serio and try to ‘create a template’. This is not the right approach! Before approaching the tool, you need to have a clear idea of what process you’ll be following, what will be involved, who is participating, what your reporting will be, and have some agreement with colleagues.

In reality then, you should have something written down before approaching the tool. This might take the form of a simple flowchart or a textual description. Whatever you decide upon, it will be something you can visualise before approaching the Change Template editor.

Working with Affected Teams

One of the big challenges facing a Change Manager is the fact that he or she might be changing the way that individuals and teams work both with themselves and with each other. The most obvious example of this is when there is no Change Management process in place at all, and so staff that have been able to entirely control whatever tasks they perform suddenly have a process ‘imposed’ on them, causing ill-feeling and conflict.

It’s usually advisable for the Change Manager to work with affected teams. My advice to customers is to avoid working with the team as a whole, but to select one ‘Champion’ or ‘representative’ to work with the Change Manager in developing a process, who can make decisions on behalf of their team (my experience has been that large groups are not good at decision making).

In summary, Change Managers have to be able to work effectively and communicate well with different groups, and handle situations calmly where people don’t see eye-to-eye. It’s not something you can do isolation (though I know some that have tried).

I’ll post later in the week about the key parts of a Change Plan Template.

Tuesday, 21 Aug 2007

This is a follow-on from last week’s post on the subject of Change Advisory Board (CAB, or sometimes Change Board for short) meetings. This post is going to be on the subject of the meetings themselves, and concentrate on some of the pitfalls and look at some ideas I’ve used.

Firstly, the meeting needs to have an effective chairman or chairwoman – ideally the Change Manager. Except to have to spend at least a few hours beforehand preparing, and be clear about how you wish to handle the meetings. If you are new to the role, ask colleagues to allow you to role-play before your first ‘actual’ meeting.


People will be more willing to attend CAB meetings if you develop a reputation for strict timekeeping early-on. Be punctual – if the meeting is for 10:00, book the room from 9:45 so you’ve got time to clear the laggers out who may still be there at 9:50, giving yourself time to be ready to start at 10:00.

Work out a timed agenda. For example, if you have 20 Changes to examine, and 60 minutes in which to do this, it means that each Change warrants 3 minutes. You can also use a grading system, where more complex Changes get 5 minutes, and more simple or straight-forwards were allocated 2 minutes.

My approach was to have variable length meetings, ranging from 1 to 2 hours. 2 hour meetings had a built-in break at the 1 hour interval. When invites were made to the meeting, I stated the duration (the actual duration being driven by the number of Changes under consideration). I also had a clock which I brought into the meeting and placed on the table in front of me.

My own feeling is that no meeting should go over 2 hours. If for some reason the work could not be concluded within two hours I’d adjourn for another day.


Some companies routinely minute Change Board meetings. I’ve never felt the need for this, but if you do want minutes make sure that someone is there whose sole responsibility it to take and distribute minutes – don’t assume that it’s the job of the Change Manager (something I have recently seen at a customer site). The Change Manager will have enough to do.

Recording Outcomes

If you are going to have any chance of sticking to your timetable, have simple outcomes to the consideration of Change: Accept, Reject, Defer. In each case you’ll want to record notes and comments from your colleagues (particularly in respect to scheduling). Deferment simply puts the Change into a ‘holding pattern’ for the next CAB meeting.

Some companies use a formal sign off document. I’ve tended to go for something less formal – giving each member a tick list, with a description of the Change, an Accept/Reject/Defer tick box and a small space in which to write comments.


It’s normal and healthy to have the membership of the CAB meeting alter during the meeting, as different members step in and out according to the Changes under consideration (which you would have streamed accordingly beforehand).

If people don’t get up to leave when they should, remind them with a gentle ‘thanks for coming, that’s all for you’. Smaller numbers, with relevant interest, will help you hold a successful meeting.

Before the Meeting

Send a summary of what is going to be discussed, and your forward schedule of Changes due to be actioned over the next month (or so). Don’t expect everyone to read it – some will pay great attention, others won’t look at it until the meeting starts. You can usually guess how it will be for different groups, and so is something you can factor into your time estimates.

Have spare print-outs ready for everyone.

Stick to the Agenda

Be ruthless in steering conversation away from this week’s hot issue to the items on the Agenda.

After the meeting

Send a concise summary of the outcomes reached, and estimate when the next meeting will be. 

Friday, 17 Aug 2007

What you save on the swings might be lost on the licensing roundabouts writes Tracey Caldwell

Hardware and software are getting divorced or at least having an open relationship if the excitement around virtual environments anything to go by. For believers, the benefits of virtual environments are anything but intangible. For the uninitiated, if there are any left, virtualisation allows computers to run multiple operating systems simultaneously in different partitions called virtual machines. A single server can replace several and software tasks can be moved around from one server to another.

The possibilities seem endless for IT teams: running different operating systems on one machine, making backup copies while trying out different scenarios and installing patches, backing up employee PCs. Support teams meanwhile are shuddering in horror at the flipside of unregulated and constantly shifting software environments causing havoc with hardware and networking set-ups.

Sceptics might also think that hard disk manufacturers must be loving the explosion of interest in virtual environments but the Ethernet savvy can even run an entire virtual SAN. Collect green points too for switching off the power to multiple real world servers and running multiple virtual servers on one hardware platform.

Virtualisation company VMWare is hot property at the moment as parent company EMC issued 10% of VMWare as shares on the New York Stock exchange on Tuesday. The shares were reported to have shot up in value 76% in one day. Intel and Cisco have already grabbed a slice of the action with six figure injections of cash into VMWare announced in July.

In this virtual world Macs can become PCs and VMWare launched the VMFusion virtualisation product for Apple Macs at the beginning of August against the market leading Parallels Desktop 3.0 for Mac product which was promptly put into beta. VMWare is not the only player in the virtual world of course, with SWsoft’s Virtuozzo, Microsoft Virtual Server and open source Xen generating much real world interest.

Every silver lining must have its cloud though and there have been rumblings, mainly around the idea that the costs saved on the swings are lost on the licensing roundabouts. Security is an issue too with some commentators pointing to improved security through virtualisation while others throw their hands up in dismay at the thought of securing multiple free ranging operating systems.

Computer Weekly’s Cliff Saran has highlighted licensing issues in his blog, pointing out that some companies like Oracle and IBM don't recognise software partitions in their licensing, meaning licences have to be bought for each virtual server.

The licensing issue also threatened to get in the way where companies are buying into hosted software as a service. VMWare has just ticked that box by publishing a licence model for hosting companies to offer services based on the company’s virtualisation software. It will charge a monthly fee, as an alternative to the model that forces hosted service providers to pay the same rate for virtual servers, regardless of how many are operating at any one time. 

Thursday, 16 Aug 2007

My post today is on the subject of the Change Advisory Board (CAB). For many involved in IT the name alone is enough to send people running to hide under their desks, conjuring up images of Sir Humphrey-type obfuscation and bureaucracy.

Of course, it can be exactly that – if you don’t plan it correctly, or have an effective chairman. Approached with a little planning and common sense most of the pitfalls can be avoided.

I’ll start by discussing it’s role, and then discussing if the work of the CAB should be on-line or in a meeting over tea. I'll post next week with some ideas for how to host the meeting.

In my earlier post, I described some of the things that might constitute a Change Management process. One of these involves the Change Advisory Board. The basic function of the CAB is to bring a business and user focus to IT Change by involving users in the approval, prioritisation and scheduling of IT change.

In Person or On-Line?

I’ll start by a trend I’ve noticed here amongst our customers here at Serio – using web collaboration to execute authorisations and rejections of Changes. For Serio Service Desk users, this means enabling the authorisation of Changes through the web. In this scenario, the CAB never actually meets. Instead, when Changes require authorisation the members of the CAB are emailed, they log-in and either authorise, reject or defer Changes.

The advantages are clear: if frees up time in people’s calendars, work can be undertaken at times that are flexible (as opposed to a meeting which is more rigid) and offers the potential for things to happen more quickly (because we aren’t always waiting for the next meeting).

Despite all this, I nearly always advise customers that I am working with the have old-fashioned, sit down, face to face meetings if at all possible. My reasons for this are that it encourages better inter-disciplinary and inter-departmental relationships, and it gives people a chance to air concerns off the record, or informally, that interaction through email or a system like SerioWeb does not. Also, if gives the Change Manager (who will normally chair the meeting) a chance to gauge mood and understanding (end users can sometimes be reluctant to say ‘I don’t understand this’).

Of course, you may also get free tea, coffee and cakes in a face to face meeting.

If your volumes dictate that On-Line is the only option, try streaming your Changes into something like ‘routine’ and ‘significant’. Allow routine Changes to be done on-line, whilst reserving the significant Changes for meetings.

As I said, I'll post next week about the meetings themselves.

Monday, 13 Aug 2007

This is another in my series of Change Management posts. The last one is here.

If you are trying to get your Change Management (CM) process ‘kick started’ you’ll probably be looking for help on getting started.

As always, if you are introducing a new ITSM process you’ll need a process owner – someone who has responsibility for the process itself, and its efficient running. This usually means a Change Manager. Having made your appointment, he or she will help to produce the basic steps in your CM process.

If you are sitting down to create a Change Management process for the first time, the best advice I can give you is to keep it simple. There seems to be something about flow charts that has an intoxicating effect on some people, to the extend that the basic Change Management process is a labyrinthine complex of twists, turns, loops and special cases. If this is what you’ve created I’d advise you to visit it again.

I’d expect to see some or all of the following

  • Initial analysis and filtering
  • Business case
  • Allocation of Priority and Initial Assessment
  • Creation of Impact Assessment, Back-out plans & Resource Estimates
  • Submission to Change Advisory Board (CAB) for authorisation, approval and comment. This is something I’m going to discuss in later posts.
  • Test Build or Implementation
  • Live Build or Implementation
  • Review
  • Update CMDB

Let’s take a look at some of these in more detail.

Creation of Impact Assessment, Back-out plans & Resource Estimates

This is a very valuable stage in any CM process. You simply examine the Change to see which services we offer to customers will be affected, or could be affected – in many cases you’ll be concerned with risk. The Back-Out plan is related to this – if things go horribly wrong, or at least don't behave as we expect, how can we roll-back or undo the Change quickly? It’s worth considering this early-on because it usually affects the things that technicians have to do prior to the Change.

In some organisations, I’ve seen these things produced during the CAB meeting. My personal preference is for as much as is possible to be produced prior to the CAB meeting for the simple reason it makes the meetings easier to chair, quicker, and less subject to diversions. You’ll certainly need this information during the CAB meeting however.

Business case

For Changes that are simply to make business improvement, you need a summary of the improvement you hope to make, along with any cost savings. If the Change is a response to one or more Incidents or Problems, you need information on the business effect (and ideally costs) of these.

Test Build

Some organisations (though by no means a majority) maintain Test Infrastructure – usually grouped together in a Test Server Room. This is where a copy, or mirror image, of live infrastructure and systems are kept – for the sole purpose of testing Changes before promotion to live systems. Although this is off my main subject, both enterprise level and desktop Changes can be handled in this way.

If you don’t have such a facility, it might still be possible (and is usually something worth doing) to perform testing on a platform specially created for the Change. In some organisations, depending on the nature of the Change, this takes the form of User Acceptance Testing.

Friday, 10 Aug 2007

The ingenuity of the home programmer is baffling writes Duncan Davidson.

Last night, I met up with a couple of friends. After talking for a while, I pulled on a flame thrower and went looking for trouble. Within a couple of minutes I’d incinerated a bunch of guys sat in a jeep, and moved on somewhere else with my ‘crew’ in tow, fanned-out in a line army style.

In case you aren’t quite with me, I was playing an online computer game – and all of my victims will live to fight another day (or until tonight anyway). The game in question (PC Halo, very popular with Serio staffers) is one that allows you to work with other players as a team, talk to them, and devise plans and strategies together. Although the media image is of the solitary gamer, modern games allow communication and interaction between real people in a way scarcely imaginable 10 years ago. My crew includes a leading Veterinary researcher, a Serio colleague, a toolshop owner, a computer programmer (me) and a Danish construction worker.

As we moved off to engage the enemy across a barren landscape, we were all picked off by single shots to the head from great distance – something that requires great skill to do.

Closer inspection revealed that our assailant was using what is called an aimbot – an aiming robot – that can be used with devastating results. Removing any elements of skill and spoiling the experience for the legitimate gamer, aimbots infect online gaming, defying efforts by companies such as Valve and others to stamp them out.

Unusually, the source code for the Halo aimbot is available online, although I’ll provide no link to it. Examining this code has taught me never to underestimate the skills of the teenage code bodger - the ingenuity shown is simply baffling.

The aimbot’s author had de-compiled the Halo game executable. I’ll explain what this means. Programmers like me use programming languages like C, C# and Delphi to write programs. These languages are human readable, use words like ‘if…’, ‘for..’ and so on. These statements (which run into many thousands of pages) are then transformed into machine code, which the computer executes. This stuff runs into millions of pages of numbers, and is unreadable to humans… or so I though.

The aimbot author had managed to work out where the game’s authors stored the position of each player. Think about that for a second. With millions of bytes, millions of numbers, he had somehow discovered the array in memory that contained all of the player details. What’s more, for each player, he had discovered what the player data meant – so he knew what direction you were facing, what your speed was…and he know how to access this from another process under Windows – no mean feat.

Computer games like Halo suffer from ‘lag’ caused by network latency – where you ‘see’ something is where it was a fraction of a second ago. To counter this, the aimbot has a system that looks at each player’s network performance and direction of travel and automatically adjusts the aim accordingly – with the impressive results I described at the start of this post.

The author of this software was, apparently, spurred by a comment from the game authors Bungie (now owned by Microsoft) that an ‘auto aiming cheat was impossible’. As I know I’m going to get hammered again tonight by this device, I wish he’d kept his mouth shut.

Wednesday, 08 Aug 2007

This is a follow-up to Monday’s post about Change Management.


First of all, I’m going to discuss the typical scope of Change Management (CM) – the types of things that might be subject to a formal Change Management process. This might include Configuration Items such as:

  • Computer hardware, such as server and desktops
  • Operating systems and other server software such as database servers
  • Routers, bridges, hubs and other types of network infrastructure
  • Documentation, both internal documentation (how to restart your CRM system for example) and end-user documentation (such as user guides and training materials)
  • Application software

Recall I mentioned in the previous post that Configuration Management and Change Management are linked? Each supports the other, but there is also a relationship in content as well. If asked what types of thing should be put into the CMDB, I usually reply ‘Items that should be subject to Change Management’. It works the other way as well – ‘All of the Items in the CMDB should be subject to CM’.

There is one other useful concept of scope – production and development. Things that are in development are, of necessity, not subject to the same control as Items that are in production (and therefore have users). If you consider these kind of development Items are subject to project Change Management -–in effect, subject you your project management disciplines before going into production.

Cost/Benefits Justifications

It can be difficult to produce objective cost and benefits analysis for Change Management (no different really from many other ITSM disciplines). The reasons are obvious – it’s impossible to quantify the value of improvements you might identify in the future, or the costs of Incidents you’ll avoid. One thing you can be sure of is you’ll pick-up additional costs as you develop a CM process, create a Change Manager role, create a Change Advisory Board (CAB), and so on.

If you are asked to justify costs, here’s an approach you can take.

First of all, set some benchmarks for the costs of introducing Change Management – in much the same way you’d cost any other project. Estimate the number of hours that will be spent, assign typical hourly costs, apply any capital expenditure, and produce a cost estimate for establishing Change Management over something like a 2 month period. I’d limit myself to the costs of getting to the point where we have a CM process for the simple reason that those costs are more easily identifiable, and that the ‘running’ costs are likely to be moderate.

Next, examine your Incident records for Incidents that have been caused by Changes that have been executed incorrectly in some way – something I’m aware that might be somewhat easier to write about and describe than it is to do. Ideally you’ll have been flagging these at the point of resolution for some time, so the ‘set’ of Incidents you’ll work with is easy to come to.

For these Incidents, estimate a very rough cost. You can do this by using downtime as a guide, and looking at one of my previous posts about the costs of unavailability.

What you can then do is compare the costs of the problem with the costs of the cure. I’ve seen someone try to quantify (in monetary terms) the value of future improvements but have never supported this approach as you may as well use a random number generator – it’s not objective in any way.

I’ll continue these posts later - either this week or next.

Monday, 06 Aug 2007

This is going to be the first in a series of posts about Change Management. I’m going to be writing for those that currently have either no Change Management process, or those that do but feel they could do things better. I’ll also be branching off from time to time to look at different aspects of the Serio tool.

Changes come about as ‘outputs’ from Incident Management or Problem Management – or quite often simply because we want to make improvements in our IT infrastructure to better serve the business.

Purpose of Change Management

The purpose of Change Management is:

  • to minimise the impact of Incidents upon the business that might occur through Change implementation
  • to have a standard, effective, repeatable way of assessing and managing the implementation of Changes to IT services and infrastructure
  • to seek business benefit and improvement

Your Change process will (most likely) have some of or all of the following:

  • an assessment of risk
  • an impact assessment
  • communication with business stakeholders and/or user communities
  • assessment of resource requirements
  • cost and benefit analysis
  • business opportunity assessment

Change Management and Configuration Management

I’ve blogged a lot about Configuration Management and the Configuration Management Data Base CMDB (search the blog for CMDB and you’ll find them). The two processes are linked. It’s something that I’ll probably come back to in more detail in later posts but if you consider for a moment something like an impact assessment, you need to ask yourself how you can do that without the level of detail and documentation that a CMDB provides. For instance, without a CMDB you may simply need to ask someone (usually a tech guru) about impact – but where does your tech guru get his information?

So, if you are thinking about implementing a Change Management process, you might also find you need to consider a Configuration Management process as well.

Prime Movers for a Change Management Process

My experience with customers has tended to show that the main driver for more formal procedures is a feeling that Changes cause too many Incidents – in other words, Changes are not planned carefully enough, tested enough, and are implemented too quickly.

It is a shame that this is a key driver because it makes it is easy to overlook Change as a vehicle for delivering business benefits, something I usually try to advise customers to ‘build-in’ to their process by having specific (usually small) focus groups that have as part of their remit to be outward looking and to be agents of innovation.

My next post will look at what should be covered by Change Management, and cost benefits/justification.

Friday, 03 Aug 2007

Are you comfortable with the idea you can play the music you’ve paid for on iTunes only on your iPod? Surely it’s time to put consumers first argues Mark James.

Digital rights management (DRM) is a big issue right now. Content creators have a natural desire to protect their intellectual property and consumers want easy access to music, video, and other online content.

The most popular portable media player is the Apple iPod, by far the most successful digital music device to date. Although an iPod can play ordinary MP3 files, its success is closely linked to iTunes’ ease of use. iTunes is a closed system built around an online store with (mostly) DRM-protected tracks using a system called FairPlay that is only compatible with the iTunes player or with an iPod.

Another option is to use a device that carries the PlaysForSure logo. These devices use a different DRM scheme - Windows Media - this time backed by Microsoft and its partners. Somewhat bizarrely, Microsoft has also launched its own Zune player using another version of Windows Media DRM - one that's incompatible with PlaysForSure.

There is a third way to access digital media - users can download or otherwise obtain DRM-free tracks and play them on any player that supports their chosen file format. To many, that sounds chaotic. Letting people download content without the protection of DRM! Surely piracy will rule and the copyright holders will lose revenue.

But will they? Home taping has been commonplace for years but there was always a quality issue. Once the development of digital music technologies allowed perfect copies to be made at home the record companies hid behind non-standard copy prevention schemes (culminating in the Sony rootkit fiasco) and DRM-protected online music. Now video content creators are following suit, with the BBC and Channel 4 both releasing DRM-protected content that will only play on some Windows PCs. At least the BBC does eventually plan to release a system that is compatible with Windows Vista and Macintosh computers but for now, the iPlayer and 4 on Demand are for Windows XP users only.

It needn’t be this way as incompatible DRM schemes restrict consumer choice and are totally unnecessary. Independent artists have already proved the model can work by releasing tracks without DRM. And after the Apple CEO, Steve Jobs, published his Thoughts on Music article in February 2006, EMI made its catalogue available, DRM-free, via iTunes, for a 25% premium.

I suspect that the rest of the major record companies are waiting to see what happens to EMI's sales and whether there is a rise in piracy of EMI tracks; which in my opinion is unlikely. The record companies want to see a return to the 1990s boom in CD sales but that was an artificial phenomenon as music lovers re-purchased their favourite analogue (LP) records in a digital (Compact Disc) format. The way to increase music sales now is to remove the barriers online content purchase.

  • The first of these is cost. Most people seem happy to pay under a pound for a track but expect album prices to be lower (matching the CDs that can be bought in supermarkets and elsewhere for around £9). Interestingly though, there is anecdotal evidence that if the price of a download was reduced and set at around $0.25 (instead of the current $0.99), then people would actually download more songs and the record companies would make more money.
  • Another barrier to sales is ease of use and portability. If I buy a CD (still the benchmark for music sales today), then I only buy it once - regardless of the brand of player that I use. Similarly, if I buy digital music or video from one store - why should I have to buy it again if I change to another system?

One of the reasons that iTunes is so popular is that it's very easy to use - the purchase process is streamlined and the synchronisation is seamless. It also locks consumers into one platform and restricts choice. Microsoft's DRM schemes do the same. And obtaining pirated content on the Internet requires a level of technical knowledge not possessed by many.

If an open standard for DRM could be created, compatible with both FairPlay and Windows Media (PlaysForSure and Zune), it would allow content owners to retain control over their intellectual property without restricting consumer choice. 

Tuesday, 31 Jul 2007

There’s an interesting post over at the Item Community forum at the moment. Contributor ITILNeutral explains how ITIL is being introduced at his company:

…A sizeable number of staff will lose their jobs (there is very little assimilation, everyone of us has to be re-interviewed for our jobs which we are totally not qualified for as far as ITIL is concerned)… ...As an example the few colleagues whose jobs are deemed already to be ITIL compatible have been assimulated but they have taken up to a £5,000 a year pay cut each...

Pretty surprising stuff. It’s unusual for management to take such drastic steps for the sake (if nothing else) of simple expediency. Management actions such as this cause uncertainty, and uncertainty is a catalyst for any organisation’s brightest and best to leave for other employment – something that can have quite devastating effects in the short and medium terms to services delivered to customers.

Although I’ve not experienced such a ‘wrecking’ approach from management I have seen something similar in my career when a former employer (and I job I enjoyed very much) ran into financial difficulties. Within 3 months the most 5 most experienced and able staff had left, rather than waiting to be ‘downsized’. My recollection is that the business suffered further as a result.

On the whole, based on what ITILNeutral has written, I’d regard the actions of managers there as plain barmy. However, it would be interesting to see what the state of IT services in the company were like, and to see if this response was some kind of backlash from a frustrated and angry business/user community. Over the years I’ve seen some pretty poor IT helpdesk/service desk operations where staff can’t be bothered to pick up the phone, cherry pick Incidents so that those that are ‘difficult’ or involve awkward customers are never attended to, and return very poor service for the investment their companies have made.

In companies like these achieving any kind of organisation change is difficult – no amount of ITIL training or role play or simulation will help. My response to this in the past has been to look carefully at team leaders – to recruit or appoint the right people, and to use them as the catalysts for change, so that rather than make cultural and service delivery changes to a team of 30, we are working with teams of something like 5 or 6. In effect, breaking the problem down into more manageable pieces and tackling resistance of apathy on the level of the team.

Generally I’ve not found it necessary to be anywhere near as confrontational.

My first ever boss told me that being a manager in IT was 'like training cats'. With that in mind, and because there seems to be a degree of irrationality in the new manager in this organisation, everyone concerned has my sympathy.