As IT organizations strive to provide more value to the ever-evolving nature of business, the ITIL v3 Foundations Course has become very popular and teaches the concepts of managing IT as a set of services. This Service Management view of IT has become more and more popular in the past few years and is gaining momentum every day.
When students take the ITIL v3 Foundations course, they often leave the classroom excited about how they can adjust the way they work to help the business meet their business needs. Many times, this excitement is coupled with the desire to act immediately to show what people have learned from the course. This desire for immediate action can often be misdirected with negative results.
The following are some of the common mistakes people make after they complete their ITIL v3 Foundations Course.
1. "I just completed ITIL Foundations training. I'm going to create an Incident Management Group, a Problem Management Group, a Change Management Group..."
This is a common reaction when people first complete the ITIL Foundations class. They are inspired to move in the right direction. However, this direction is counter-productive to the concepts of IT Service Management.
While some processes, and sets of processes, may warrant a dedicated team to perform that process, processes are simply sets of activities and do not operate independently. Creating separate teams to support the processes simply moves from one silo approach to another. It is important to understand how the processes interact and how a single individual may perform the activities in multiple processes within the span of a few minutes, or even seconds.
Instead of focusing on the processes themselves, focus on the procedures that depend on the activities of the pertinent processes. These procedures can then be ingrained into the fabric of the new organization.
2. "I 'm ITIL Foundations Certified! That's all I need to be successful!"
Congratulations on your success! However, the ITIL Foundations certification demonstrates that you have base-level knowledge of the concepts of IT Service Management. One of the challenges that the authors of ITIL faced when writing such a complex topic, is how to structure ITSM so that people could learn the topic in a series of progressing classes instead of all at once.
The Service Lifecycle that you learned in the ITIL Foundations class is the first step in the progression of courses in IT Service Management. As such, the ITIL Foundations class simplifies the complex topics of IT Service Management into a few-day course with an exam at the end. There is no way that 1000+ pages of the IT Infrastructure Library can be learned in a few days. This simplified view of IT Service Management does not provide the necessary guidance to truly reap the benefits of what ITIL can offer an organization.
In the intermediate courses, the Service Lifecycle is explored in far more detail. This detail often conflicts with the simple concepts learned in the ITIL Foundations class as these concepts are explored and a full understanding of the concepts is gained.
An interesting side effect of continuing the intermediate and advanced courses is that students come away from the course realizing just how much they didn't know before the course and how much ITIL Foundations left out.
3. "Let's fix our Incident and Change Management processes first. We'll worry about what services are later."
While this approach is widely used to stabilize operations first, ITIL documents the practices to use for Service Management, not Process Management. Focusing on processes first, with little understanding or development of what services are offered by the organization, will result in short-sighted decisions being made that could potentially become an obstacle later as the organization begins to transform itself into a Service Provider. To overcome this, an organization should at least develop the definitions of services in parallel to the operational process improvements.
By documenting and better understanding the services that the organization provides, the concepts of services stay in the forefront of the improvements and influence the decisions that need to be made during these improvements. This effort will also begin the organization's cultural change from a technology provider to a service provider.
Ideally, an organization should develop their understanding of services first prior to any other improvement efforts. However, this approach usually only works in an ideal situation and most situations are far from ideal. When making operational improvements, keep the end-goal in mind - IT Service Management. Your operational improvements should be consistent with the path to the end-goal and not deviate too far off of the path.
4. "The CMDB is my project. I'll let you know when it's done."
Not only does this approach take place far too often in IT organizations, but duplicate efforts toward the same goal can also take place. This is common in larger, highly political organizations. While an approach like this is common for Configuration Management process development and implementing a CMS or CMDB, it can occur for other processes as well.
At the core, ITIL promotes the concept that IT is there to support the business through services. In order to provide these services, all of IT must work together, not only to ensure that the business needs are being met, but that other processes and functions within IT are working together to support these business needs. No process or tool should be implemented in isolation - particularly Configuration Management. Configuration Management and the CMS or CMDB is there to support all other processes. Therefore, all other processes must be considered in order to ensure that those process requirements can be met. While this is true for every process, it is particularly true for Configuration Management.
5. "I know what services we need to provide."
Once people start discovering the vision of IT Service Management, they begin to think in terms of services and about the services that they currently provide to the business. They then start to document these services and develop a Service Catalog. While this is a good start, it is not sufficient.
If your organization was already providing services that meet the business needs, then why is the organization exploring ITIL? There is obviously a gap betwen what the business expects and what IT delivers for an organization to explore ways to improve their environment. This gap in expectations needs to be well understood in order to close the gap between what the business expects and what IT delivers.
Services provide value to the business by facilitating outcomes customers want to achieve. As such, we must understand what the outcomes are that the business customers want to achieve. To enable this understanding, we must engage the business to understand these outcomes. While documenting the services that we currently provide is a good starting point (and recommended), they must be mapped to the desired outcomes of the business. During this mapping of services to business desired outcomes, the gaps between what we deliver and the expectations of the business will be uncovered and can then be filled.
6. "Is a password reset an Incident or a Problem? I can't move forward without this being answered."
This debate has been going almost as long as "which came first, the chicken or the egg?" If you read any ITIL forums, you will undoubtedly find this question posted at least once a year.
My answer to this question is: if it really matters, you are doing something wrong.
The very basis of this question shows that the person asking is far too focused on the process instead of what they should be focusing on; the customer of the process. Yes, you can be too process focused. It doesn't matter if a password reset is an Incident or a Service Request as long as your procedures of addressing this are efficient, effective and support the needs of the person needing their password reset.
For any organization, their adoption of the IT Service Management practices will vary from other organizations and that's OK. As an organization's Service Management maturity grows, the focus should be on making the customer and their interactions with the Service Provider more effective and efficient instead of debating issues like this.
So, the question should be restated as: "What would make our customers more efficient? Should we handle a password reset as an Incident or a Service Request?" From this question, you can devise your own answer that is pertinent to your organization.
(For the record, a password reset is, indeed, a Service Request because it has nothing to do with some disruption to the service. However, this can be further debated in the instance where the service itself causes the need for the password to be reset.)
7. "ITIL says we need a CAB. We should put this on the calendar and invite everyone."
While ITIL promotes the concept of a Change Advisory Board (CAB), it doesn't say how a CAB should be convened. Many people learn about a CAB and decide that before each and every change occurs, a CAB meeting needs to be convened to discuss the change. Upon the first meeting of the CAB, people who attend the CAB meeting are excited and involved as they learn about the proposed change and are eager to discuss it. Over time, and often very quickly, people's involvement wanes as the CAB becomes a sounding board for other issues that often don't involve many of the people present at the CAB meeting.
The structure of CAB meetings doesn't have to be a single, regular meeting with all of the stakeholders for all services. Instead, a creative approach to CAB meetings may provide more positive support and involvement from stakeholders. An example of a creative approach is a hierachic approach to CAB meetings.
Suppose an IT organization has complete control over a specific environment while other IT organizations have control over their specific environments. If a change is proposed for this specific environment, then the IT organization should be able to evaluate that change with the involvement of relevant stakeholders if that change only impacts that single environment. If the change has any chance of impacting any other environment, then the change cannot be evaluated in this manner.
A technique for handing this type of situation is to establish hierarchic CAB meetings. A CAB meeting would be convened for that specific environment on a regular basis to evaluate requested changes pertinent to that environment. In this manner, the local IT organization and the pertinent stakeholders can operate in an autonomous manner as appropriate.
Additionally, a higher level CAB meeting would be convened to evaluate changes that impact multiple environments. This higher level CAB would involve stakeholders from the different environments to provide the appropriate evaluation of changes.
CAB meetings shouldn't be long, drawn out meetings that result in the perception of time being wasted by the attendees. Instead, they should be highly relevant to the attendees and provide value to everyone involved. To accomplish this, creative means may need to be explored to provide the proper evaluation of changes through the CAB.
8. "I know that we should adopt ITIL. Why do people walk away when I start talking about it?"
My first rule of ITIL is never to talk about ITIL. When we start talking about ITIL, people who are not familiar with ITIL think that we are speaking in code and that ITIL is just another passing fad that will be replaced by something else in the future, so they don't want to waste their time.
Having some experience in ITIL, I am sure that you would agree that ITIL is mostly documented common sense. Any organization with enough time, forethought, and effort would develop something very similar. ITIL promotes IT as a Service Provider to meet the needs of the business. As such, instead of speaking in terms of ITIL, speak in terms of what is good for the business using your knowledge of ITIL as guidance. Over time, people will want to know where this abundance of common sense and business-orientation is coming from. At that time, you can direct them to the gold mine of knowledge found in the IT Infrastructure Library.
9. "I found a template on the web. This will work in our environment."
While many templates for the ITIL processes and procedures exist on the internet and other sources, they were developed either as a generic solution for the industry, or as a specific solution to fulfill a specific need. Templates are not meant to be a drop-in solution for your specific need.
Before using a template, ensure that the reasons for the template are needed. The process for which the template is to be used should be fully documented and all stakeholders of the process identified. Through this exercise, a better understanding of the process will be developed with the specific inputs, outputs, activities, and roles defined for the process.
Templates are good starting points, but not a means to an end. Review a variety of templates to determine the pros and cons of each. Then compare these good points to your defined processes to create your own procedures and documentation that fits your specific issue.
10. "We need to adopt Service Management in our organization. A tool will implement ITIL for us!"
This is far too common an approach to adopting IT Service Management within an organization. Many times when organizations want to "implement" ITIL, they look to a tool for their ITIL solution. While there are many excellent tools on the market that support the concepts of IT Service Management, IT Service Management starts with the organization itself.
IT Service Management is focused on providing value to customers to facilitate outcomes customers want to achieve. Begin with an understanding of the customer needs and then realign the organization's processes and activities to facilitate these needs. A tool will not do this for you. Tools have very specific purposes to support an organization's processes and activities, but the concepts of IT Service Management go far beyond what a tool can provide.
Before tools are sought out, an organization must understand what that tool is expected to accomplish. By starting with documentation and development of the underlying processes that support the concepts of Service Management, an organization can begin to develop requirements for a tool. The best approach (while not always realistic), is to perform the process without any formal tools to learn how the process operates within your organization. By performing the process manually for a while, an organization can better understand how the process works and improve the process without the distraction of complex tools and tool configurations.
Through this definition and manual operation of a process, tools can then be introduced to support the processes and activities instead of implementing the processes and activities. Through this technique, an organization can tailor a tool to support the goals and objectives of the organization's processes and activities instead of tailoring the organization's processes to conform to the tool. Remember that a tool should work for you instead of you working to support the tool.
11. "We've implemented ITIL! Let's move on to something else now."
Implementing ITIL is an oxymoron. As such, an organization will never implement ITIL. Implementation implies that it has been installed and can now be used as we move on to something else. ITIL is not a tool, but a way of working to deliver services to meet business needs. This way of working involves adopting a culture of service that focuses on the business outcomes instead of technology. This culture is ever-evolving as the business needs continue to evolve.
Additionally, ITIL promotes the concept of continual improvement. Continual improvement has no end and will never be complete. There is always something to improve.