- Executive Support – Perhaps the most critical and obvious. Almost all implementations hits bumps along the way, so consistent support is a must. The tougher question is “who are the stakeholders?” Remember that ITSM is about improving service to business. If you don’t have the support of business, you’re project is likely at risk.
What I think is critical here is to maintain that executive support and buy in THROUGHOUT these usually LONG initiatives. It’s one thing to get the initial support and buy in on how the initiative you’re proposing is going to help improve this or that prior to starting the project, but keeping this for the long haul is CRITICAL! You’ll ultimately be faced with justifying resource allocations over months and maybe years. The “what does this person do” or “what value does this person/function provide” questions will be asked. This is closely tied to the scoping of the initiative and alignment with business objectives mentioned below. Make sure to come up with creative ways to ensure that “support and buy in” aren’t just token gestures but are more than skin deep. What does the executive water cooler talk sound like?
- User Involvement — Too many ITSM implementations begin with some ITIL experts in a room developing their idealized process model. Unfortunately, this Ivory Tower exercise is often a waste of time (see Standardized Infrastructure below) and misdirected. Early effort should be directed to working with users to understand how processes currently work, gather change recommendations, and measure the ability of the organization to implement those changes.
From what I’ve seen, everyone gets really excited in the beginning with “ITIL Buzz” and takes advantage of the opportunity to get some free training and a new certification for the resume. What seemed to work in my last initiative was to have named process owners (high level position) and then have named sub-process owners (matrixed to the named process owner) in each part of the organization that contributed to the overall process creation and implementation (got a vote). Those not directly involved seem to take advantage of the free training/certification and then go back into their own “reality” and take a “believe it when they see it” attitude and cease contributing. You should spend as much time as you can comforting those who say this will make their jobs worse or cause more work. Put these issues to rest as fast as you can — if you can’t, get them off of the project as quick as you can. Their hate and discontent will spread like a wild fire. Again, what does the employee water cooler talk sound like?
- Experienced Project Management – ITIL certifications do not equate to experienced project management. Make sure you have project management that has been through an ITSM implementation before and understands more than process. Seek external, professional help if you can’t meet these criteria internally.
True, so true! Include budget dollars for this up front in your proposals! I think you’ll get more “buy-in” and interest when an outside consultant or expert is involved. Just be careful about “perma-consultants” or hiring them on as FTE’s. I was really impressed with a presentation given by Don Page of the Marval Group at our last ITSMF LIG meeting. I’m sure other consultancies engage in similar ways, but his message and approach really stuck with me. It just seemed “real” and full of so much common sense.
- Clear Business Objectives – Don’t fall into a trap here. “Implement change management” is not a clear business objective. It is really just a means to the end of improving the service provided to business. Any project must have measurable goals for improving the efficiency and effectiveness of IT services to risk becoming irrelevant and failing.
Watch out for the hard/soft benefits trap as well. If you have metrics available from your operations and support teams such as support calls, failed releases, outages, etc. that you can equate to measurable costs, use these as much as you can. Look to resources from the Help Desk Institute (HDI), outsourcing, call center trade magazines or analysts who have done studies on the costs of downtime/outages and their causes as drivers for aligning improvement initiatives to business objectives (control costs and make money). Also be on the lookout for those emotional metrics that management sponsors may have (tied to compensation/bonuses, etc.) and drive alignment towards those (usually cost or revenue related)..
- Minimized Scope – This is critical. Just about every successful ITSM project I have heard of starts by implementing an achievable, manageable set of business objectives and their supporting processes.
One of my more recent personal experiences was our attempt at implementing four of the eleven ITIL process areas (SLM/Service Desk/Incident (all rolled into one), Security, Change and Release). I’d say we were most successful with one of them and the rest were diluted efforts that never recognized any of the stated goals or objectives. It may be best to focus on one or two at first. The question becomes which one(s) to do that best support the point above and have the most buy in!
- Standardized Infrastructure – At first blush, this may seem to have more to do with software development than process implementation. Think again! The old rule of thumb is that an application is about 80% infrastructure and only 20% new code. The Chaos Study indicates that virtually all projects that create infrastructure are doomed to failure because it is an inefficient use of resources. ITSM projects are really no different. Existing best practice based process models, such as the IBM Tivoli Unified Process (downloadable from http://www-306.ibm.com/software/tivoli/features/it-serv-mgmt/itup/index.html ) probably contain 80% of what an organization needs to document their operational processes. Do your project a favor and use one of these models as a starting point. You’ll lower cost and risk.
- Formalized Methodology – Yes, ITIL is a formalized collection of best practices observed in the IT industry, but it is infamously quiet on implementation guidance. If you haven’t already considered it, look into industry models like CMMI or leverage a consultant with proven services for assessing your organizations needs and ability to change, and for developing realistic implementation roadmaps.
Absolutely! I wish I had known about ITUP three or four years ago! I think the future of ITUP and those who leverage it is extremely promising!
- Reliable Estimates — “We’re changing a few processes, how hard could that be?” The short answer is “very”. Change is always hard. The Chaos Study has shown that the average IT project has a 63% time overrun and a 45% budget overrun. Bottom line: make sure your staff remains optimistic, but keep your project estimates realistic and conservative.
Spot on here. Put considerable time into these project management fundamentals. Understand your critical path items. Have contingencies identified. Know your risks and how you’ll address them when they arise. Over communicate your progress and delays.
I’d add the following:
- Communicate — Establish a formal communication plan. Include not only the key stakeholder’s and project team members, but also include those not directly involved but who’ll benefit from your planned improvements (lines of business, technical support, customer care, etc.) Create a weekly/monthly/quarterly newsletter, create posters for the break room or hallway. Recognize and over communicate successes and small wins. Highlight improvements frequently!
Powered By Qumana