Handling a big IT Rollout

My post today is on the subject of ‘the big rollout’ – when a new or upgraded application is rolled-out to end users.

My experience of this over my career is mixed to say the least. It varies between someone calling and saying ‘I’ve got a problem with this new application WidgetSkillz’ and me saying ‘Oh what’s that?’ at one end of the scale, whilst at the other, I had an employer plan meticulously for 1000 ‘rollout’ Incidents in the first week and receive only 20 or so.

Firstly, I’ll risk being a master of the obvious and state why new rollouts cause problems

  • The new application of service might be buggy or have errors in its configuration
  • Users may be unfamiliar with the application
  • If the rollout involves deployment to desktop machines, you can usually be sure that some of these will fail (or at least not be 100%)
  • Some users don’t like change, and need someone to vent their frustrations on (often the Helpdesk and Service Desk staff).

This post is all about how some of the things I’d so for the front-line team – your Helpdesk or Service Desk.

1. Pick the roll-out time carefully. This is a tough one, because often there is some business driver (like a new contract) that gives you the start date. However, often you can influence the date even if you bring it forwards a little. Dates are important because there is often a ‘cyclic’ nature to IT support, with periods of greater activity coinciding with greater user activity and stress at certain times. At least consider this carefully, use reports (like the 26 week-by-week report in SerioClient) to spot any such cyclic activity and consult widely to see what other things are happening in the business.

2. Make sure your Service Desk/Helpdesk team leader (or your Incident Manager) is part of the project team. This is not always the case, particularly when you’ve got an in-house team writing or upgrading the new application. My experience has almost always been that developers focus solely on the code and delivering a stable application at the expense of issues like training and documentation.

3. Make sure a late, stable version of the application is available for your front-line support team to learn about. Make sure they have time to use it and understand it’s key functions. But please, don’t ‘give it to them to play with.’ I’ve seen this so many times and it always ends the same – the people who need to know how to use the application know nothing.

Instead, give them (the front-line team) a suite of exercises to perform, usually involving a couple of business processes, and ask them questions at the end. Make sure their time is structured and not wasted.

4. If you can, run a pilot. A pilot roll-out to a select band of users.

5. Using the pilot, try to develop a Frequently Asked Questions (FAQ) list, or collection of knowledgebase documents, to help get over any rise in calls coinciding with the rollout.

6. Finally, look at your leave rosta carefully. You wouldn’t be the first manager to plan a big rollout for a day when a large number of staff were on holiday.

For those of you on holiday over Easter have a great time, for those of our readers working (and there are quite a few) you have my commiserations.

Categories: