Shifting changes left – madness?


A little while ago I tweeted about a Servicedesk function taking on networking changes:

This question came up during a debate with one of my deputies – I used making network VLAN changes as an example of repeatable, documented tasks that a first line support role could reasonably take up, rather than relying on a 2nd/3rd line team.

Responses varied from cautious agreement:

Through “it depends”:


Not a whole lot of faith in the Servicedesk, it felt!

My belief is that, as with information on how to make the most of IT resources, we should always aim to “shift left”.

Shifting left, adopting knowledge centred support, isn’t anything new. Most of us by now have discovered (if not necessarily successfully realised – it’s a service that comes with its own challenges) the power of self-service. From a support perspective shifting information left speeds the time to resolution (either thanks to self-service, or by moving the knowledge to deliver a workaround closer to the user and eliminating functional escalation). From a management perspective, an issue resolved by 1st line is cheaper than 2nd line, cheaper then 3rd line etc.

So, why not delivering standard changes? Especially those which can be delivered electronically (in the traditional model of a “stationary” service desk, sat in an office)?

We already look to our Service Desks to do this in many different ways, from handling Identity and Access Management related requests, to delivering software and giving access to resources. Why wouldn’t we expand that list to include more involved activities? Who hasn’t had an experience with a company call centre where we’ve been passed from pillar to post to deal with an issue that, in the end, was dealt with by someone in front of a computer following a script? If it’s frustrating for us as users of mobile phone and banking services, why would we inflict that frustration on the people we’re here to support?

Changing configuration on a piece of network equipment is possibly an extreme example, but I would think it possible and appropriate for any task to be carried out by a 1st line support role, subject to the following prerequisites:

  • The steps that need to be followed can be simplified to the point (relying on automation, to pick up on Steve Patterson’s observation on Twitter) that they can be documented and confirmed as 100% repeatable (in Lean terms we’re talking Standardised Work)
  • Documentation has been tested (and tested and tested…), with the support function agreeing to accept it (no lobbing procedures over the wall!)
  • Training has been provided, the aim being to ensure the context of the activity is understood and instructions aren’t blindly followed – the idea being to understand enough to catch oddities and errors
  • There is sufficient configuration information available so what is being changed/updated is clearly identified and the impact of the change understood
  • The authorisation process is clear (and ideally automated) – don’t disable the VCs phone because has emailed asking for it!

On reflection, in an ideal world these kinds of activities exist in a culture of iterative improvement and welcoming feedback (Lean again) – but it could exist with a more formal, structured approach to process management just as well. Organisational readiness is a factor here – the level of maturity required to deliver this is quite high and I would see this kind of thing as being a development for an established team, rather than something to be thrust on an inexperienced group.

Looking back over some of the responses I got, I felt I could see that some of the thinking behind them is coloured by each person’s context. The Service Desk Manager’s concern about not wanting to sacrifice quality of customer service to do more, the techie’s fear of breaking the network, the IT Director’s acceptance – subject to conditions!

Done right I maintain that shifting standard change delivery left, like shifting information, can only be a positive thing. We move delivery closer to the user, meaning a cheaper and faster resolution. But that in turn frees up time in 2nd line and beyond to spend time on proactive activities like Problem Management, reducing the incident workload faced by the Service Desk – and again, benefiting users. The potential for a positive feedback loop here is huge.

And of course we shouldn’t limit how far we shift change delivery – user self-service needn’t only provide information, it can also provide direct access to services. There’s an awesome conference slide that demonstrates the power of online self-service by comparing a teenager’s ability to use services like Google Drive and YouTube to access services and resources in minutes, while Enterprise IT is still prepping its red tape:

I never managed to persuade my Deputy that I wasn’t mad on this – but his team is responsible for the network, so this doesn’t surprise me! But I am undeterred…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s