That IT service management (ITSM) automation project you are about to undertake is big and complicated. Because it is so technical, it's easy to become so focused on the technologies that you might find yourself overlooking other critical considerations that could cause your project to fail. Choosing a top-notch service management tool is just part of the solution.
If only you had a road map to help you avoid potential missteps. Over the years, I have been involved in several ITSM suite implementations. With each there were things that went well and things that became learning opportunities, never to be overlooked again.
While there are many ways to unwittingly sabotage your own service project, here are my top 10.
1. Go in without a clear vision
When you initiated your ITSM suite implementation project, you probably had a preliminary goal in mind. Perhaps your organization had outgrown the old system and the goal was to replace it. Perhaps the old system didn't support automation, or someone in your organization was bitten by the ITSM bug and said, "We need a tool that does ITIL!"
Whatever it was that triggered your project, that probably was not the complete picture. Beginning with the end in mind is good advice, but what is the desired end?
I once inherited an ITSM suite implementation that was intended to "fix" the support desk. Fortunately, I was able to convince my new boss to hit pause and allow me to work on processes first!
Technology cannot fix people and process problems. Step back and work with your stakeholders to discover what success really needs to look like before you go any further.
2. Don't worry about having an engaged executive sponsor
Unless you want to guarantee project failure, do not set down the path of implementing a new ITSM suite without truly engaged executive sponsorship. While you may have tons of support within the IT department for your project, or think you do until you start asking for resources, recognize that an ITSM suite represents considerable change.
An engaged executive sponsor will help promote the value of what you are doing, help you remove roadblocks, and get the resources you need.
I have had executive sponsors support me during difficult meetings when stakeholders were unhappy with an outcome, and others who have made magic happen when resources were too busy no matter what I did. One of my best executive sponsors from years ago once told me, "My job is to be a dam; I'll let the good stuff roll down to you, and the other stuff stops with me."
Because employees look to their immediate supervisor and senior leadership when it comes to accepting change, a positive mindset like this is invaluable.
3. Don't manage ITSM automation as a project
You work in IT, and you are already involved in many projects. So do you really need a project manager for this? After all, you know how to run a project, you have the connections, you can multi-task, and you certainly don't want to wait on a project management office (PMO) resource to be assigned to your project when there are so many other projects in play.
The reported percentage of IT projects that result in failure depends on the article or survey you read. Sources quoted by a 2016 CIO.com article put the number at 55%. A later CIO.com article, which referenced the Project Management Institute's 2017 Pulse of the Profession survey, stated that organizations with mature project management have only a 6% failure rate.
Even if you have good project management skills, you can’t run a successful ITSM suite implementation off the side of your desk; believe me, I have tried.
4. Consider this an IT project, not a business project
Your ITSM suite is not an IT tool any more than email is. If ITIL teaches us anything, it is that ITSM is a strategic approach to design, deliver, manage, and improve services that meet the needs of an organization.
In other words, IT provides services to the business; your ITSM suite implementation is one of them.
Back in the early days of my IT career, the help desk (not to be confused with today's service desk) used "ticket tracking" software that very few people outside of the help desk, and certainly no one outside IT, used.
It can take some effort to convince people, especially those without any knowledge of ITIL or service management, that this should no longer be the case. An ITSM suite supports many business-impacting processes; it is essential to engage your stakeholders in the business for them to understand how your project will provide value.
5. Fail to understand your level of ITSM maturity
How can you start down the path of implementing an ITSM suite without understanding your organization's ITSM maturity? Many organizations do just that.
Take the time to perform a process maturity self-assessment to ensure that you understand exactly where your organization's process maturity lies today and to help plan a process strategy. This will help you select an ITSM suite that is right for your current maturity level as well as your desired future state.
6. Start with incomplete requirements
Unless you identify and talk to all your stakeholder groups, gathering and understanding their functional and technical needs as well as their pain points, your project is not going to be successful.
One of the biggest mistakes I ever made was not insisting that key stakeholders took time out to discuss their needs with me. Rather than being persuasive and explaining the value of their input, I thought I knew enough to adequately represent their interests in the requirements documentation.
My intentions were good, but we all know where the road paved in good intensions leads.
Having a complete picture of your "must haves," "should haves," and "could haves" before you begin talking to vendors will save you time and keep you from making preventable mistakes.
Be sure to ask the right questions and identify areas your stakeholders may not have considered, such as processes that should be automated, and opportunities for integration and consolidation.
7. Focus on just those shiny product features
No disrespect to my ITSM colleagues in sales, but a great presentation can completely derail the best requirements documentation. It is easy to become so focused on the shiny new features that you lose focus on your "must haves."
There have been times when my colleagues and I have been so impressed with what we saw in a presentation that we almost found ourselves glossing over some misses in our "must haves."
Beware when you hear the answer, "We can do that." Given enough time and money, anyone can do almost anything, but not necessarily optimally or cost-effectively. Especially when it comes to automation and required integrations, you want to hear, "We have done that." Caveat emptor.
8. Take a 'big bang' approach to your rollout
You know how we are in IT; we like to "get it done." While the "big bang" approach—migrating all users to the new system and making the legacy system unavailable—can be faster, easier, and cheaper as a rollout strategy, it does not allow time for adjustments or to facilitate acceptance.
On one rollout, not going "big bang" allowed us to discover web server and load balancer configuration issues in a small market with relatively few self-service users; as a result, the implementer was able to make the necessary adjustments without anyone really noticing. Had we rolled the app out to all markets, the publicity impact could have cost our project its credibility.
Further, when it comes to your automation strategy, a phased approach allows you to start with simpler processes, demonstrate ROI, and move on to more complex processes as stakeholders become more aware of the value of automation.
9. Overlook organizational change management
A successful implementation requires buy-in from both IT and the business. To gain acceptance, you must understand and address the impact to the people, processes, culture, and technology of your organization.
All too often, I see implementations where the people element was overlooked, resulting in complaints and nay-saying to the point where your technically “perfect” implementation is deemed a failure. To better understand people’s differing reactions to change and what can happen when they understand the benefit of change, read Dr. Spencer Johnson's book Who Moved My Cheese?
10. Lose your momentum
Implementing an ITSM suite is not a "one and done" project. While it is very important that you take the time to celebrate your initial success and improvements to various key performance indicators, don't sit on your laurels.
Your automation and integration strategy will evolve over time, and your organization should be seeking to improve process capability and maturity. You should be an advocate for such opportunities. Remember that continuous service improvement is built into the fabric of ITSM and ITIL.
The common thread
There's a common thread here when it comes to avoiding sabotaging your ITSM automation implementation. Plan beyond the immediate needs and wants of IT and the service desk and avoid the temptation of just "getting it done."
Taking the time to do your research, understanding the needs of the business and your stakeholders, thinking ahead, and being prepared are other keys to a successful, well-accepted implementation.
Join me for my presentation at Service Management World in Orlando, Florida, where I'll talk more about how not to sabotage your ITSM automation project. The conference runs November 11-13, 2019. I hope to see you there!
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
