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.

What Good Are Rules?

Whether explicit or implicit, rules exist for a reason. Rules exist to govern activities. Some rules are understood by the parties doing business. Others have to be learned and often, over time, transition from the explicit to implicit: it's no longer necessary to state the rule. These rules apply as “rules of engagement” between organizations. They also apply for sales, marketing, governance and financial management. Just as the organization that violates the implicit rules of gentlemanly engagement-that is, of doing business between two entities -those who violate standards of management can expect failure, sooner or later. One medical organization once told me that his customers were “different.” I am compelled to ask, different from what? Do you mean to tell me that your business doesn’t need to understand your customer needs? It’s not important to translate those needs into specifications which will feed the service design process? Your customers will not need to approve the service design? You won’t look to them for feedback on how the service is performing or how you may improve your service to them? What you’re telling me is, because of your “unique” goals and position in the industry, the rules that apply to others don’t apply to you!

Hey folks, there’s nothin’ new in this universe. To maintain integrity with your customers there is a norm of behavior. Violate that norm and word will get around. Your employees and ultimately your customers will see through the shallow promises built on the sand of disingenuous behavior. Similarly, violate the norms of customer-led business, and you’ll find yourself at the mercy of your competitors.