Typical ITSM Implementation? I Should Think Not!

As much as the IT director, manager or even senior executive might wish, there are no ITSM implementations that can be considered “typical”. In fact, I would advise you run at right a sharp right angle (as if from an oncoming tornado) from those consultants who might tell you how to develop anything that might be considered “typical”. Just this past week I discussed this very point with a potential client who, I suspect, was looking for a “silver bullet” solution. There are no silver bullets and there are no perfect solutions; particularly if you pitch a solution prematurely. But we can be sure to establish the best approach for any organization by following a few simple guidelines at the outset. While simple, they do require some thoughtful commitment of time and resources. But they are necessary - and reasonable:
• Understand why the organization needs to address ITSM. What do they really want to accomplish? If the answer is IT-centric, find out what business issues are driving the IT needs.
• Understand, document and analyze the IT weaknesses and their strengths. Where are the points of pain? At what do they excel? What are their capabilities across the spectrum of ITSM disciplines? What strengths may be leveraged and built upon to improve the weaknesses? Where do the gaps exist?
• Now, and only now, think about the problem. You have gathered the background and have an understanding of the organization. It is now time to develop a concise and clear problem statement. Only once the organization comes to terms with the problem they’re addressing does it make any sense what so ever to consider a solution.
• The problem statement may be recast, then, as a vision for the program that will then serve as the guiding influence for the programmed solution.
• With the background and problem statement in hand, begin developing a plan of attack. Look to the best practices of ITIL, Six Sigma, COBIT, Balanced Scorecard, Theory of Constraints (Goldratt), Deming & Shewhart (PDCA), Crosby and others to design an integrated program for change. Here the term “program” is intentionally used. It must consist of a series of projects managed by a central governance entity that can tie the objectives of the program to the business drivers and account for interdependencies that dictate sequential activities. Anything less than a programmed approach limits the potential for success.

The implementation roadmap that will take shape will be scoped to the needs of the customer, their objectives, vision and goal, the project timeline, and the capability/maturity of their process (es) baseline. It will also address the responsibilities of all stakeholders and clearly document accountabilities at all levels of the implementation. At a minimum, the roadmap will:
• Explicitly identify ALL key stakeholders
• Clearly document the stakeholder CTQ criteria
• Include a thorough RACI chart of the project team their responsibilities and those of all stakeholders
• Include key milestones correlated with appropriate communication interfaces
• Identify all interdependent processes in a sequence appropriate for effective implementation of the primary focus of the program
• Outline the required budget and sources of funding
• Identify program governance including the program lead (ITIL Master/Manager), individual project managers and program steering committee.
• Include a clear and fully integrated COMMUNICATION PLAN. With out the communication PLAN, the project WILL FAIL. That I will guarantee. I have a case study as proof.
• Include an action - task - for each process to develop a Control Plan. This document is designed for the process owner. The Control Plan empowers the process owner to maintain the improvements made and to drive continuous improvement.



The ultimate output is a fully integrated roadmap, charter, and specific deliverables which may range from policy statements, process maps, procedural documentation, definitions, plans, role definition, metrics, to specific tasks, process/tool integration, tool selection, training, etc.

The actual "deliverables" will vary from one organization to another and within a single organization, from one point in time to another. In this case, such variance is a good thing. That is, if it’s planned, managed and controlled.