How to assess Changes

One of the things that I wish was covered in more detail during the ITIL intermediate training is how to properly impact assess Changes. Change Managers are the guardians of the production environment so making sure that all changes are properly assessed and sanity checked is a key part of service delivery. Asses too low and high risk rangers go through unchallenged, assess too high and you block up the process by examining every change no matter how small as if they could kill your organisation.

Here are the things that I look for when assessing a Change:

The Basics:

Title Does it highlight the affected services so that it’s easy to identify in any reports?
Description Is it clear and does it make sense? Sounds basic I know but let’s make it easier for the other people assessing and authorising the Change.
Benefits Why are we doing the Change? Remember, this isn’t just about technology, what about business and financial benefits?
Risk What are the risks in carrying out this Change? Has a risk matrix been used to give it a tangible risk score or is it a case of “reboot that critical server in the middle of the day? Be grand”. Imagine explaining to senior management what went wrong if the Change implodes – have you looked at risk mitigation? Using a formal risk categorisation matrix is key here.  Don’t just assume technicians know what makes a change low risk.  One of the key complaints from the business is that IT does not understand their pain. Creating a change assessment risk matrix IN A REPEATABLE FORMAT should be your first priority as a Change Manager.  If you can’t assess the risk of a change in the same way each time, learning from any mistakes, then you’re not doing Change Management. Period.


Scheduling Does the proposed timing work with the approved Changes already on the Change Schedule (CS)? Has the Change been clash checked so there are no potential conflicts over services or resources?
Implementation windows Look at the proposed start and end times. Are they sensible (i.e. not rebooting a business critical server at 9 o’clock on Monday morning)? Does the implementation window leave time for anything going wrong or needing to roll back the Change?
Special considerations Are there any special circumstances that need to be considered? I used to work for Virgin Media; we had Change restrictions and freezes on our TV platforms during key times like the Olympics or World Cup to protect our customer’s experience. If you don’t know when your business critical times are then ask! The business will thank you for it.

The Technical Details:

Service Affected Have all affected services been identified? What about supporting services? Has someone checked the CMS to ensure all dependencies have been accounted for? Have we referenced the Service Catalogue so that business approvers know what they’re authorising?
Technical Teams Affected Who will support the Change throughout testing and implementation? Will additional support be needed? What about outside support from external suppliers? Has someone checked the contract to ensure any additional costs have been approved?
User Base Affected Check and check again. The last thing you want to do is deploy a Change to the wrong area of the business.
Environments Covered What do you mean what environments are we covering? Surely the only environment we need to worry out is our production environment right? Let me share the story of my worst day at work, ever. A long time ago and pre-kids, I worked for a large investment bank in London. A so called routine code change to one of the most business critical systems (the market data feed to our trade floors) took longer than expected so instead of updating both the production and DR environments, only the production environment was updated. The implementation team planned on updating the DR environment but got distracted with other operational priorities (i.e. doing the bidding of whichever senior manager shouted the loudest). Fast forward to 6 weeks later, a crisis hits the trading floor, the call is made to invoke DR but we couldn’t because our market data services were out of sync. Cue a hugely stressful 2 hours where the whole IT organisation and its mum desperately scrambled to find a fix and an estimated cost to the business of over $8 million. Moral of the story? If you have a DR environment; keep it in sync with production.
Licencing Are there any licensing implications? Don’t forget, changes in the number of people accessing a system, number of CPUs, or (especially) the way in which people work (moving from dev to prod) have huge impacts on licences.


Pre Implementation Testing How do we make sure the Change will go as planned? Has the Change been properly tested in an appropriate environment? Has the testing been signed off and have all quality requirements been met?
Post Implementation Verification OK; the Change has gone in, how do we make sure everything is as it should be? Is there any smoke testing we can carry out? This is particularly important in transactional services; I once saw a Change that went in, everything looked grand but when customers tried to log in the next day, they couldn’t make any changes in their online banking session. I’ll spare you the details of the very shouty senior management feedback; let’s just say fun was most definitely not had that day. If at all possible; test that everything is working; the last thing you need is a total inability to support usual processes following a Change.


Implementation Plan Does it make sense and does everyone involved know what they are meant to be doing and when.  If other teams are involved are they aware and do we have contact details for them? Are there any dodgy areas where we might need check point calls? Do we need additional support in place such as additional on call / shift resource on duty senior manager to mitigate risk? The plan doesn’t have to be fancy; if you need some inspiration I can share some template implementation plans in our members / subscribers area.
Back Out Plan What happens if something goes wrong during the Change? Do we fix on fail or roll back? Are the Change implementers empowered to make a decision or is escalation needed? In that case; are senior management aware of the Change and will a designated manager / decision maker be available? Can the Change be backed out in the agreed implementation window or do we need more time? If it looks like restoration work will cause the Change to overrun; warn the business sooner rather than later so that they can put any mitigation plans / workarounds in place.


What Early Life Support Is Planned? What early Life support is planned? Are floorwalkers needed? Are extra team members needed that day to cope with any questions? Have we got defined exit criteria in place?
Is The Service Desk Aware? Has someone made the Service Desk aware? Have they been given any training if needed? I know it sounds basic but only a couple of months ago; I had to sit down and explain to an engineer why it was a good idea to let the Service Desk know before any Changes went live. Let’s face it; if something goes wrong the Service Desk are going to be at the sharp end of things. And speaking as an ex Service Desk manager (a very long time ago when they were still called Help Desks) there is nothing worse than having to deal with customers suffering from the fallout of a Change that you know nothing about.
Communication Has the Change been comm’ed out properly? Do we have nice templates so Change notification have a consistent look and feel?
SLAs If the business are pushing for a Change to be fast tracked with minimum testing can you ask them to formally acknowledge the risk by relaxing any SLA?

The above list isn’t exhaustive but it’s a sensible starting point. There’s lots of guidance out there; ITIL has the 7 R’s of Change Management and COBIT has advice on governance. What do you look for when assessing Changes? Let me know in the comments!

Image Credit

University of Westminster: From First Call Resolution to Revenue

15222132819_08a97144ec_zFirst call resolution (FCR) measures the proportion of issues that can be addressed during the first call. In theory, the more issues are addressed immediately without the customer having to call back or wait for service – the happier they should be.

For the University of Westminster, healthy first call resolution means happier students, which means better ratings in University leader boards, which has a direct relationship with incoming revenue.


IT Support as Competitive Advantage

Students wishing to complete their studies in the UK’s capital have plenty of choice – with over forty Universities situated in and around the London area.

China is also busy building it’s own Universities to attract students from the Asia-Pac region – previously a good source of supply for London, plus reports from The Telegraph suggest that the higher education system is becoming a “buyers’ market for applicants” with students getting record numbers of offers from universities. It seems that supply may be exceeding demand.

“Competition is tougher than ever. We have pressure to increase league table scores with no extra budget,” said Lee Rose, Associate Director of Information and Communication Technology at University of Westminster.

Lee was hosting a press event with representatives from Bomgar and was keen to demonstrate the University of Westminster’s progress with the remote administration appliance.


The Student User Experience

Unlike campus-based institutions, the University of Westminster is dispersed geographically across the West of London with 2,300 staff and over 20,000 students.

“We’re not a Campus,” continued Lee; “Our students expect to come into our institution, to start at a particular time and leave at a particular time. If that doesn’t happen, for whatever reason, if affects their experience. In contrast, students that attend a campus based University can find something else on campus to do during their downtime.”

Fee structures and trends in mobile and Internet technology have been a significant challenge for the University. Lee said, “The moment the fees went up the expectations went up too. The real challenge is mobile; students are turning up with 3-5 devices each. Mobile access has really hit us hard, we’ve had to ramp up significantly with mobile and we’ve had BYOD issues to wrangle with too. We’ve moved from a technology-based business (shiny, shiny) to a user experience led business. Parents and students, especially those from abroad, refer to Times and Guardian league tables which take into consideration several areas such as Entry Grades, Student to Staff Ratio and Student Satisfaction Scores with the latter able to be effected by any bad experiences the student may encounter during their University life – including experience with IT systems and services.”.


Doing More with Less

The University has increasing demands and competition but IT teams find it difficult to ask for extra staff “Efficiency and how you are working become very important. Tools like Bomgar can enhance the experiences of students and allow our existing staff to work more productively” said Lee. Interacting with students online and addressing their concerns immediately means a lot less pounding the corridors of University.

Lee stated their implementation of Bomgar was going well and was being well received by the business. Three key benefits to the University were identified as:

  1. The IT support team could remote control into any device, anywhere. “It’s one of the best tools we have on the service desk because we can reach out to customer like never before”
  2. Bomgar’s ease of use. The appliance has received great feedback from students and staff.
  3. First time call resolution has decreased through remote handholding and IT team collaboration.

The Bomgar implementation included a cultural change in the approach to IT support. IT teams are encouraged to resolve issues remotely if possible rather than face to face, which is very different to how support has been delivered traditionally at the University, but ultimately leads to faster support and a more efficient use of resources.


See also “Supporting Digital Change” in CIO connect.


Image Credit