After years of experience deploying ITSM solutions in a variety of customers, and in the midst of a major soccer tournament here in Europe which brings out the managerial expert in football-watching folk, I found myself musing on what would be my “Fantasy” ITSM team.
What is that seemingly mythical combination of team members that brings about either an aura of calm or a maelstrom of chaos.
The ITSM Solution Architect
Quite often with fingers in various pies – a little project management here, a touch of subject-matter-expert (SME) there and a healthy dose of OCD in terms of getting Visio lines to snap to geometry.
You will typically work directly with customers, to understand what magic is required to get this Service Management tool malarkey to work.
And then – you find yourself stuck in the middle of a team trying to get processes and tools to live in harmony, so maybe add the role “politican” to your skill-set.
Size does NOT matter
No really – believe me, it does not where ITSM projects are concerned.
My most recent deployments have been as part of outsourcing projects – and even within those beasts of burden, the projects have ranged from the Service Management work-stream being a small part of a large outsourcing project, or a small group running as jacks-of-all-trades.
But there is one common denominator in all this – the need to dovetail the team’s efforts into reworking of the process with the development/customisation of the tool.
1) Don’t Make Me a Liar…
Process Implementation and Solution rests in two camps. If you are lucky, the project will have a work-stream specifically for Service Management and the two areas can advance in lock step with each other.
And they NEED to.
The Process team has to know what the capabilities, and at times limitations, of the tool as they are redefining processes.
The worst case scenario here is that the earth is promised, yet for whatever reason the tool simply cannot deliver, leaving everyone looking a little foolish.
2) You can Have it all…
Of course the flip side of the coin is that you twist the tool to do anything you want, and add anything to the process.
That tends not to help much either, (see above re: foolish)
3) So Happy Together…
There are several ways, in my opinion, to bring the Process and Tool together, without uber-educating one individual to be a complete Service Manager, Process Implementation Manager, and Tool Subject Matter Expert!
(Mind you, just think what you could ask as a daily rate!)
- A single work-stream which brings together the Service Management Processes and the tool implementation team together.
- It requires a strong, knowledgeable Project Manager who can understand the technical, and process elements, but steps back and manages the project using those resources.
- Collaboration between the members of the team – there is absolutely nothing wrong with a little skills cross-pollination.
- It doesn’t hurt to herd Process folk towards the tool – yes I know, it’s horrible and it involves clicking and things, but it does bring to life those lovely diagrams you make!
- Actually – it also doesn’t hurt for Solution Architects to perhaps get up closer and personal with some of the administration of a system so that they can combine brain-power with the Subject Matter Experts/developers from time to time
Is it ever possible to do things “turnkey”?
Now that IS a good question.
“Turnkey” is a phrase I heard all the live-long day on one project, where it was assumed that customers would just sign on the dotted line, leaving us to go and pretty much do what we wanted.
Once upon a time, maybe that could have been true, but not in the 20 odd years I have worked in the industry!
1) Requirements Gathering
No two customers ever have exactly the same business requirements. But most companies will have developed decent sets of templates to drive out specific requirements – standardised questions and a repeatable approach helps here.
2) ITSM Solution
Ah, we architects LOVE our solution templates – plug in requirements and it might be useful to work out what belongs to Process, what are Organisational and whatever left is Tool.
THEN figure out what the tool does easily, what the contract says, and work out where your implementation headaches will b
Here’s where we start to overlap. Whether your tool solutions are high or detailed level, it is likely to start to cross some boundaries especially if the definitions for elements like Impact and Urgency need to be configured in the tool.
The solution needs to reflect the way the process has been written and the process needs to be implementable.
This cannot be done in isolation and also is likely to involve SMEs or developers for more fine tuning of the tool – do not leave them out of the equation.
4) Tool Implementation
The magic area where it all miraculously comes together!
Priorities, urgency, impact, fields, workflows, data loading… need I go on?
People wonder why Service Management deployments take a while!
Some things, of course, can be standardised, for example supplying standard data loading templates, but sources of information will differ, and it is worth remembering that often the project will have to interact with groups who are maybe not directly involved with the ITSM project.
A fool with a tool… how to avoid that scenario!
There can never be a single person who possesses all the tools to make a Service Management Deployment a success – it has to be a team effort.
The best project managers have a degree of technical skill in Service Management, but can remove themselves from interfering in the technical detail.
The best process managers are actively involved with working alongside the implementation team and perhaps involved in developing testing material to aid that familiarisation.
The best teams have engaged service managers who have a vested interest in what is coming their way – all too often they are either the last people to be informed, or worse they feel they are too busy to give it the time – a recipe for disaster, every time.
The best architects understand at the very least the ITIL basics to hold their own in process/solution design discussions, and it is better still if they can hold their own in the more heated debates of “the book says” vs. “the tool does, in alignment with ITIL Best Practice”
The best implementation teams have a good bond between architect and SME; often two heads can be better than one in getting darned pesky tickets to go where you want them to.
The nature of the deployment beast is that you may have some, but probably not all of your perfect team attributes but if enough of balance can be struck between the vital roles Process Implementation and Tool Implementation play during a deployment – then I think you are half way there.