I’m old enough such that my IT career began long before popular IT “movements” or frameworks – whether that be IT management or IT service management (ITSM). Back then, our IT and ITSM best practice was learned through trial and error, and based on the documentation given to us by our suppliers, as well as requests from stakeholders who demanded greater use of technology in business operations.
Then came the “movements” of ITSM, Agile, Lean, DevOps, and many others. It sometimes feels that hardly a month goes by without someone announcing they have the latest new best practice available to revolutionize how corporate IT organizations deliver IT services.
It’s a lot to take in, so how do you choose what to use? How do you weigh up their relative pros and cons? And do you have to use only one?
This blog will help you to answer these and other questions about the best approaches and frameworks to use.
Why Do We Seem to Be on an Endless Quest for New Best Practice?
Everyone wants that ITSM magic bullet. Everyone wants to introduce something that makes life better, but then this happens:
It’s usually the result of not involving people in the organizational change early enough (along with failing to dealing with other organizational change management issues).
What if people ARE involved in the organizational change earlier? It’s not impossible, in fact it can be quite easy…
Here’s an idea I’d like to propose. Invite a group of 10-12 people to a one-hour session, hand each person two post-it notes, of two different colors (say red and green, for example), and then tell them:
- On the red post-it note, write down one thing you don’t like about working here.
- On the green post-it note, write down one thing you like (or value) about working here.
Then, organize the notes onto two flipcharts.
Amazingly, the post-it notes, and their groupings, in my experience usually show that people want better interactions, more collaboration, better processes but not heavy governance, and the capability to respond to change. They are defining the desired outcomes of organizational change rather than the means of change.
This is the beginning stages of blending ITSM with other IT management approaches such as:
- Agile – which is about making things better or introducing agility.
- Lean – which is about thinking how you can do things differently to do things better.
All three (ITSM, Agile, Lean) strive for value, improvement, and a focus on customers and staff.
So, What If We Took, and Used, All Three?
Not in isolation, of course. I mean that by using some of the Agile techniques, we could make or change things iteratively. Using the Lean techniques, we could keep our eyes on the whole flow and the impact on customers and staff. And ITSM techniques could be used to help with established, best practice ways of working and common sense governance.
We could have our cake, with extra icing, and eat it too!
However, it’s very easy to type this concept out into a blog such as this, but it’s a completely different thing to achieve it without some practical help. So let me outline the art of the possible through a personal example.
Blending Agile, Lean, and ITSM in Action
I once led a team of technology program managers, developers, security personnel, and IT operations and service desk individuals in piloting a program for blending Agile, Lean, and ITSM to resolve a specific business issue – the onboarding of new employees.
The company would hire a new employee, and by the time they arrived 2-3 months later, it would still typically take another eleven days until that person was fully functional in terms of everything they needed to fulfill their new role.
So, using Lean, we set a key metric – our North Star – which we called “You Start Work So You Start Working,” such that any new starter would have everything they need to work from day one. This metric would be our guide as we iteratively changed things to ensure that we were going to not only reduce the time it took to onboard someone, but actually let people work on the day they started – with the right technology, facilities, and HR services.
Then using Agile and Scrum we looked at the way the process worked today, and iteratively kept changing things such that we achieved our goal. Finally, using ITSM we created role profiles and a service catalog to simplify the ordering of things such as access rights, technology, or a desk, with these linked to the HR and facilities processes and tools.
Reflecting on Our Success
It was a team effort and the only thing it really cost us was time – which was good as we had set another goal, based on Lean and Agile, of improving without additional spending. It wasn’t easy but it worked. In one month, new employees started their new job and already had all that they needed to start working.
Management was impressed and gave us the approval to improve other processes and activities. They of course particularly liked that we were making things better without asking to spend more money. And we went on to improve in other areas such as:
- The escalation process for incidents
- How incidents are passed from Level 1 to other teams or external suppliers
- The speed of change – removing change approval meetings and automating requests (we called this “automating trust”)
Importantly, the improvement teams saw how, with each sprint, they could devote a portion of their time to improve things.
Within 18 months we had: removed €150m of recurring costs from the technology budget (and with no fired people), improved the customer satisfaction percentage from the 60s to high 90s, increased service quality, and found that our staff were more attentive and retentive.
So not only does the blending of approaches work, it can work extremely well.
Try blending Agile, Lean, and ITSM. If you already have, I’d love to know what you achieved.