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.
One thing that has surprised me during my initial exploration of ITSM tools is the simplicity of some SaaS based pricing models.
Software licensing options offer vendors the ability to flex their competitive muscles, adapt their solutions to different customers and maximize revenue.
Microsoft is particularly good at this, if you are a left-handed student living in Outer Mongolia – Microsoft has a SKU code with your name on it! To the other extreme, Salesforce.com licensing is remarkably straight forward, if you have fifty users and you want Enterprise Edition – everyone must be on Enterprise Edition.
The counter to this simplicity is that customers might end up paying for development of software that they don’t use, but I think this is easily outweighed by simplicity and predictability. No hidden surprises and endless fiddling about with licensing scenarios.
Moreover, for a SaaS based subscription model it is in the interests of the vendor to ensure you are a happy customer, rather than the vendor constantly trying to sell the next upgrade or option. Vendors are more interested in longevity and retention over winning the big deal, in theory at least.
The KISS Principle
I was pleasantly surprised to see some SaaS based ITSM vendors offering one simple price per user per year. For everything. I’m not the sharpest tool in the box so I’m all for keeping things simple when the opportunity presents itself. KISS.
Being this crystal clear over licensing represents a significant paradigm shift for some traditional ITSM tool vendors. It is difficult to wean yourself from high margin professional services revenue when you have grown used to it – how will that revenue be replaced if we simplify everything for our customers? Similarly some vendors position relatively low cost ITSM tools specifically to generate new business for their consulting business.
Eyes Wide Open
I believe pricing simplicity should be a serious consideration when choosing a tool vendor. I have compiled a quick pricing ‘Ouch-O-Meter’ to help during the tool selection process. Click on the image above to enlarge it.
I’m not saying that SaaS is the only way to go, nor am I anti-consultant (being one myself) – I just like the simplicity of the licensing model. I believe how things are priced moving forward should be a serious consideration when exploring a new vendor relationship, there is nothing worse when securing a great deal than to find the hidden extras.
Am I entering into an ‘all you can eat’ license or a ‘We’re going to nickel-and-dime you every time you breath’ relationship?
Have I missed anything here? What else should be considered when it comes to vendor pricing?
At the SDI event I attended last week, Ken Goff gave a compelling talk on tool selection.
This is not a new concept and I’m sure many readers would have used similar methodologies, nonetheless the credit for this article goes to Ken and SDI.
In this article I aim to provide an overview of Ken’s logic. The goal is to build a decision matrix for tool selection that is closely aligned to your requirements. The focus is on making an objective decision based on facts and stripping away any emotion or subjective bias.
Step 1: Define your criteria, wish-list and desires of a new tool (This is a whole topic by itself and won’t be covered here).
Step 2: From this list define which of your criteria are Must Haves or Show Stoppers, there is no point investing in a tool if these features are not included. The remainder will be ‘wants’ or ‘nice to haves’.
Step 3: Assign a weighting score against each criteria
Step 4: Score each tool according to the criteria, then multiply the score by the weighting score to generate an overall score. Eliminate any candidates that do not meet the ‘Must’ criteria.
Step 5: Total all scores to provide an overall objective rating.
To demonstrate this in action I’ll use this methodology to choose a new house to purchase.
Step 1: Criteria: I’m looking for a house to buy in Poole, UK. I would like 3 bedrooms, a Sea View and for the property to be in Poole.
Step 2: Must or Want: It must have a least 3 bedrooms (Must), The Sea View and Location are nice to have.
Step 3: Criteria Score: I will assign a score to the criteria as follows: 3 bedrooms (10), Sea View (8) and Poole location (5).
Step 4: Scoring: See table below. As an example Property 1 has no Sea View (Score 0), it has four bedrooms (score 9) and is within Poole (score 8). Total aggregate score of scores versus weightings equals 130.
Step 5: Property 3 has the highest score, Property 2 is eliminated because it only has 2 bedrooms (A must) and Property 1 is last.
This method might seem overkill for 3 criteria, but becomes very useful when dealing with 50+ requirements.
I have used Poole in Dorset, UK specifically as an example (The fourth highest land value, by area in the world) since it doesn’t matter how suitable your tool is if you can’t afford it. Indeed, the price range of the tool might be factored into the criteria.
Please let me know if you have anything to add to this process or if you have any experiences to share.