Today, I’m going to dust off my IT Service Management consultant handbook and talk about ITSM solution design—common mistakes and pitfalls leading to costly changes, explosive debates (those ITIL® purists!), and the sudden departure of project sponsors. I hope this hard-won advice will help you avoid regrets, recriminations, and remorse over your ITSM software.
By the way, my blogs are always JFZs (judgment-free zones) so names have been purposely omitted.
Don’t design to the exception
Organizations that set out to implement ITSM software by designing and configuring to the exception rather than the rule will face large costs, big headaches, and low adoption. This was true 15 years ago, and it rings true today. Of course I am not saying you can’t have exceptions. You will. But the key to success is to design a process to deal with exceptions, rather than building complex and costly customizations (which are never supported by the vendor) to accommodate them.
I have heard time and time again during requirements and design sessions: “That team just has to have things done that way. They are different, unique, and special. They are responsible for a critical service that’s core to our business, so they need to get what they are asking for.” I don’t mean to make light of this issue, but the end result always seems to be buyer’s remorse—due to poor design decisions, not technology capabilities.
Don’t take my word for it!
For fun, here are a couple of real-world scenarios (slightly tweaked) from my consultant vault to illustrate the point.
Customer – How do we use more out-of-the-box functionality for this scenario? I’m starting to regret buying your solution.
Me – But what happened to that expensive, must-have, show-stopper customization you paid for?
Customer – No one uses it.
Me – Why not?
Customer – Because the scenario we thought happened all the time doesn’t actually occur that often, and when it does, it’s not such a big deal after all. Out-of-the-box functionality probably is sufficient, now that we think about it.
The next story is about a year-long remediation. Here’s the Cliff Notes version:
Customer – The system is really slow and we are not happy with your product.
Me – Well, the custom workflow that you designed has about 100 steps. Do you think that might be a contributing factor?
Customer – Could be, but we have a lot of one-off situations that we had to account for and a lot of teams that needed their steps included.
Me – Are those folks you had to accommodate happy with the system, at least?
Customer – No.
Me – Why?
Customer – They complain the system is too slow.
Me – So was it communicated that their one-off requirements could be accommodated but only at the expense of performance?
Customer – No, we didn’t think that would be a problem. I guess we truly didn’t understand what our users wanted.
Recommendations from the vault
Of course, I had advice then, and I have advice now. You have to understand the out-of-the-box functionality of a solution very well during the sales cycle. During demos and trials, I recommend that you ask about what you are being shown. “Is this out-of-the-box functionality?” If the vendor says, “Yes, but it’s very configurable,” stop and ask for clarification:
- How do they define configuration?
- How do they define customization?
Then ask what configuration is covered by their support organization and what requires you to engage in a separate, third-party support contract.
From my experience, the BMC Presales team does a very good job arming prospects with this detailed knowledge. And the BMC Customer Success team is another critical resource to engage for information about other customers’ post-sale experience.
When selecting your ITSM solution and vendor partner, be sure you have collected requirements from your stakeholders:
- Try to get reasonable business justification for requirements.
- Try to involve the implementers of the solution during the sales cycle, including watching demos. If they are not involved in submitting requirements or evaluating candidates, it may turn out that the chosen solution doesn’t fit their needs and you’ll have to go down the customization route.
Follow the 80/20 rule
My highest success rate with customers is the result of applying the 80/20 rule to solution design. In other words, design the solution to accommodate 80 percent of the requirements, and design great exception processes and escalation paths to accommodate the remaining scenarios. This is not new common sense, but what I saw missing over the years as an ITIL educator, has been the benchmarking (or stake in the ground!) so then you can compare – and measure change and/or improvement! Is that 20% accurate? How do we know? If you didn’t take a snapshot at this point in time, how will you know if you were successful? My answer is…
Define a success plan
What does success with this solution actually look like? It was supposed to be the right answer (you bought it!), so what was the question it was supposed to address? The customer success manager should be asking you how you define success with the solution.
For example, BMC customer success managers work with Remedyforce customers to understand:
- Do you have a strategy?
- Do you have metrics to determine success?
- How will you train your staff and your client base to use the new solution?
- Do you have standard processes? If not, you may get requests for special treatment and expensive special designs from rogue business units. (Also, if you have no processes, you may not do a good job with chargebacks, so IT will be on the hook to deliver special exceptions.)
- What about technology – do your design decisions and integration decisions tie back to a strategy?
- What about governance?
Defining success plans, establishing success metrics, and creating ITSM strategies are increasingly important in our digital service management world. With changes occurring at light speed, we really do need strong foundations and common-sense thinking. Without them, we keep rushing to decisions based on assumptions, not metrics – which is costly in many ways.
To end this chapter from my ITSM consultant handbook on a positive note, both organizations described in this blog did eventually get their ships back on course with only minor scars.