Someone on Twitter recently asked me "what are the 5 main reasons IT Service Management projects fail". I really didn't have to give it much thought. After 30 years practicing ITSM the reasons are pretty much top of mind. So I quickly rattled off the following:
- No plan
- Unrealistic expectations
- Skepticism
- Poor requirements
- Not doing the hard work
The more I thought about it the more I realized that these items are not unique to ITSM at all. They can apply equally well to any endeavor, whether it's implementing a new IT system, rolling out a business process, or something more personal, like embarking on an exercise program.
People too often jump into new projects without a clear understanding of what it is going to take. When the project fails they point to external reasons such as "the tool doesn't work" rather than looking inwards.
Maybe this behavior is part of the "Human Condition", however with a little focus on the following 5 points, your chances of completing a successful ITSM project will rise dramatically.
1. No plan - Would you build a house without a set of blueprints? So why is it that so many companies embark on an ITSM program without a detailed plan. A good ITSM plan should address issues such as awareness, organizational change, process development, tool selection and implementation, employee training and most importantly ongoing process governance.
The more detailed the plan the easier it will be to justify the effort involved.
2. Unrealistic expectations - I am still shocked when I hear about companies wanting to implement 12 processes in 12 months. There is a lot of work involved in designing and implementing a process. You need to review what's in place and you need to get the new requirements from all the stakeholders. Inputs, outputs, roles, responsibilities, activities, tasks, metrics and policies all have to be defined and agreed to. The newly designed process has to be implemented in a tool and don't underestimate how long that takes. Once implemented you have to train the stakeholders and role it out.
The larger the enterprise the more unique requirements there will be. Skipping over these requirements will only lead to a poorly implemented process.
3. Skepticism - How many times have you heard "we have tried that before, it will just fail again" when approaching management or colleagues about improving IT processes? You cannot underestimate the importance of getting people on board. Lack of support, regardless at what level in the organization, will completely undermine the program. I've seen managers publically support a program while refusing to allow their staff to participate, and then complain because they were not "involved" in the design.
One of the best ways to fight skepticism is not to over commit and to deliver on what you promise.
4. Poor Requirements - There has been a recent trend towards trying to implement ITSM tools "out of the box". The story goes something like "the tool is based on ITIL, we use ITIL so therefore we won't have to change anything". With perhaps the exception of smaller IT organizations this couldn't be further from the truth. Let me ask you a question "is your organization out of the box"? Ask yourself the following questions: How will the users be defined; what are the notification groups and rules; what are the workflow requirements; what are the escalation rules; what are the reporting requirements? These things are seldom "out of the box" and need to be documented and the ITSM tool tailored to accommodate.
Bad requirements lead to a poor ITSM tool implementation
5. Not doing the hard work - Designing a process is one thing, making sure people adopt it is another. I like to call it "walking the talk". Take incident management for example. For that process to be effective it starts with people actually entering good incident data. There has to be good categorization of the incidents. Escalation needs to be followed. Incident aging needs to be tracked and followed up on. Metrics need to exist and corrective action needs to be taken. This is where the rubber meets the road, it is where the hard work lies, and no tool is going to do it for you.
Governance of the process is every bit as important as having documented process and an implemented ITSM Tool.
While these are my "top 5 reasons" I am sure everyone has their own stories to share. What are some of the things that have impacted the success of your ITSM program? I would love to hear them.
Want to learn more about the state of ITSM within North America? Then check out our 5th annual ITSM survey at http://community.itoptimizer.com/resources/the-state-of-itsm-implementations-in-north-america-2/