Learn the 5 Key Reasons Why any Project Fails

Someone on twitter recently asked me “what are the 5 key reasons why IT Service Management or any project 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”, a little focus on the following 5 points, your chances of completing a successful IT Service Management project will rise dramatically.

 No plan

Would you build a house without a set of blueprints? So why is it that so many companies embark on an IT Service Management program without a detailed plan. A good IT Service Management 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.

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 roll 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.

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.

Poor Requirements

There has been a recent trend towards trying to implement IT Service Management tools “out of the box”. The story goes something like “the tool is based on ITIL, we use ITIL  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 IT Service Management tool tailored to accommodate. Bad requirements lead to a poor ITSM tool implementation.

Poor Governance and Controls

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 a 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 IT Service Management 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 IT Service Management program? I would love to hear them. This article was first published on ITILNews originally

David Mainville

David Mainville


David Mainville, CEO and co-founder of Navvia, is a passionate advocate of Service Management and a frequent presenter, blogger and well known member of the ITSM community. With over 35 years of experience, David has held progressively senior technical and management roles allowing him to "connect the dots" between the Business and IT. At Navvia, David leads the charge to bring innovative ITSM solutions to market focusing on Product Development, Marketing and Operations.


• Posted by David Mainville on Nov 08, 2012
• Filed under Articles
• Tagged with

Share this post