I am repeatedly asked where a group should begin their ITSM journey.There are many ways to answer this question and doubtlessly if you ask a hundred seasoned ITSM “experts” you may get just as many different answers. There is, however, one answer that is always right – “it depends.”
“It depends” has become somewhat of a tongue in cheek joke in the ITSM community and frustrated many a newcomer.“So, where do I start?” or “How should I implement a process?” or “What metrics should I use?” all are examples of questions that can only be answered by “It depends.”
The reason “it depends” is the answer is that there are a number of important questions that need to be asked in order to give a response.For example, consider the following and how different responses could affect what is done:
What is the goal? – what is it that you are trying to achieve?The answer to this must drive all decisions.
What is the available timeframe? – it may be that a phased implementation would be better or that the scope needs to be reduced to meet the schedule.
What is the level of senior management support? – if there isn’t senior management support then the likelihood of failure is very high.They need to understand the benefits in order to support the requested changes.
Is there a budget? – changing or implementing a process needs to be managed as a project and as such have a budget to utilize the necessary internal and external resources, fund training, and so forth.
What is the current level of process maturity? – starting from scratch vs. starting with a relatively mature process can affect decisions dramatically.Imagine, for instance, trying to do something in an organization that does not value processes.
What is the level of stakeholder ITSM knowledge? – in some cases understanding ITSM and what it is trying to achieve in a given situation can be very valuable.
What is the political climate? – in an organization that is very political, trying to change how work is done can be very difficult.
Are outsourcers involved? – environments where this is the case can be a complex challenge due to politics and existing contracts that detail what is to be performed and how changes will be managed.
Thus, when someone asks a question that requires background information such as the above, the only possible answer is “It depends.”Rather than get frustrated, people need to think about potential dependencies in their situation.One approach is to think in terms of PPT (People, Processes and Technology) to identify what may be needed.So, for groups looking for guidance on how to best leverage this blog post, my response is “it depends”.
In certain circumstances organizations need to bring in specialized help to facilitate the accomplishment of objectives.One way to do this is to hire consultants.While many times this works as intended, there are also situations where the consultants come in, never quite deliver and also never quite leave.This can become very expensive very fast.
The single best way to avoid risks relating to achieving objectives within the timeframe and budget allocated is to use project management.A project-based approach with a project manager reporting on progress, issues encountered, risks, and so forth will significantly boost the likelihood of success.In addition, to project management in general, here are some additional suggestions:
First, there need to be clear objectives that can be measured and/or observed.This could range from deliverables to performance based measures such as improvements in availability.The consultants must be contractually obligated to fulfill those objectives within the identified budget or following the approved funding method.
Second, there needs to be a project plan that identifies tasks and owners.It needs to be sufficiently detailed enough to measure progress, if there are issues, etc.Depending on the procurement cycle, the detailed project plan may need to be developed early on in the engagement, but there needs to be an understanding that it will be developed and managed to with appropriate reporting.
Third, understand that changes are inevitable.It is critical to have a method to manage changes from submission, to review, approval/rejection, action (if any), and post implementation review.If changes aren’t managed, it is far too easy for the sum of all the little changes to be tremendous in terms of costs and risks to the project.In fact, the use of a formal change management process should be identified in the contract.
Fourth, recognize that the lowest quoted consultancy will likely not have the lowest total cost of ownership.One stratagem is to underbid the competition to get the work and then make the money up in change requests.Another is to cut corners and let quality suffer in order to make up the profitability.As a result, some procurement groups choose to automatically discard the lowest bidder in some bidding situations.
Fifth, if the area is unknown, use an objective third party consultancy to develop the RFP, project plan, etc.They serve as a safeguard because their engagement is limited to planning and procurement and not getting the ultimate work.This way their knowledge can be leveraged to select and manage the other vendor.
In closing, most consultancies that I have worked with, or observed, honestly work to help their client.The biggest challenge is dealing with misunderstandings that can and will occur.Both groups should work together to find a solution when these situations arise. Just to reinforce the main suggestion – use project management!
There are reports of organizations either canceling or postponing their ITIL implementations.While there are many potential reasons for this, it is worthwhile to stop and consider what is going on.
Capital Limitations
Doubtlessly some organizations are playing things very conservative with borrowed money and keeping their capital expenses as low as possible.If part of the ITIL recommendation is to buy an ITSM tool suite that costs tens or hundreds of thousands then that may be part of the cause.
In response, groups should seriously consider whether the capital component is needed or if there are short-term benefits to moving ahead with the ITIL project in a revised manner.
Lack of Understanding
In some cases, ITIL is perceived as some nebulous project that IT is working on to somehow help IT.Without a clear benefit to the business overall, management is delaying or canceling the project.
In response, organizations need to show the causal relationships between business strategies, functional area objectives that support the goal (what sales is doing to aid the business, and the same for marketing, accounting, finance, customer service, etc.) and what IT is doing to support those areas via Goal to Objective Mapping (GOM).
Then, IT needs to explain how ITIL and the philosophy of IT Service Management is going to specifically improve IT’s ability to provide quality services to those areas.Management must be able to understand the causality between investing in ITIL/ITSM and benefits to the organization.
Business Case Challenges
This is somewhat related to the second point, but the difference is that a business case was assembled and senior management doesn’t believe in it or has cause to question the promised benefits.
In response, the ITIL team either needs to ask the senior manager championing ITIL to find out what the problems are or they need to recruit a champion to help isolate what the challenges are and what needs to be done to overcome them.
In closing, there are many reasons why ITIL/ITSM teams may find their funding delayed or cut in today’s economy.The best overall response is to find out what the concerns are and then take the necessary actions to create a credible business case that ties ITIL/ITSM efforts to real business benefits that support and protect the goals of the organization.
I’ve encountered several groups that either are not doing ITIL, or are stopping ITIL implementation, because of entity-level Lean or Lean Six Sigma quality management initiatives.Doing so reflects a fundamental misunderstanding about the roles of these quality frameworks.
The Lean approach uses analytical methods that focus attention on the reduction of waste.The Six Sigma methodology is focused on identifying defects and driving down the costs of rework.Not surprisingly these two approaches are complementary.The combined approach is known as “Lean Six Sigma” and is about addressing defects, wasted time and increasing the overall speed of the system while reducing costs.While the roots of these quality management methods are in manufacturing, they have spread out to service industries as well including healthcare, insurance, finance and so on.
ITIL espouses IT Service Management that is also very quality driven.Great care is taken in terms of understanding business requirements, designing, transitioning and supporting IT services in production.Wrapping this is a culture of continuous process improvement.Moreover, ITIL gives example processes that organizations can look at and eclectically borrow from.
You know what?The same way that Lean and Six Sigma work well together, so does ITIL.Regardless of the exact Lean, Six Sigma or Lean Six Sigma approach, ITIL can help IT understand gaps between what they are doing relative to best practices and, when used correctly, give a comparison other to help formulate corrective actions.One of challenges is that business management typically knows very little about ITIL.
IT organizations that are being told to forget about ITIL and do Lean, etc., need to educate management about the synergies of combining ITIL with another quality approach.Lean, for example, can be used to identify wasted activities.ITIL can then be used to compare the organization’s approach against best practice and then a corrective action plan developed.Without ITIL, the approach the group will come up with will be based on their experience versus the combined experience of many organizations around the world since the late 1990s.
Imagine being told that the way the organization performs Change Management is wasteful and then trying to improve it without leveraging ITIL.Where would an IT person get the necessary information to chart a roadmap from current to future state?The answer is that person, perhaps with input from others, would try to design the best process they could based on personal experience or maybe some digging on the Internet.These approaches aren’t very re-assuring in today’s high-pressure world of competitive business rife with security and regulatory concerns.By using ITIL, effective and efficient processes can be designed and implemented faster and at lower cost than waiting for internal evolution to runs its course.
So, for groups facing this challenge today, review how ITIL can help make the results of the organization’s overall quality approach better.The benefits and rationale need to be assembled and then a discussion with the relevant stakeholders needs to be hand.Without a doubt, ITIL plays well with Lean, Six Sigma or Lean Six Sigma and can help accelerate the development of efficient and effective processes that meet business requirements.
Most organizations fundamentally need IT in order to operate.IT, of course works to provide services that meet the needs of the business.In an effort to provide “good” service, some personnel even go way beyond what is required.This is known as “gold plating” – to provide more than what is required.On one hand, it sounds wonderful “we are going to provide excellent service and exceed expectations”.The reality is that gold plating can actually set expectations that can’t be consistently met and damage the credibility of IT.
Think of it this way, if service is inconsistent, then what is the customer to think?If a service request is fulfilled in 4 hours, then 9 hours, then 2 days and then back to 4 hours, what should be the expectation?People might well conclude that 4 hours is but the SLA identifies two days.Bear in mind that while Service Level Agreements (SLAs) are useful, they do not safeguard against unrealistic expectations being set at some point in time.If customers grow accustomed to a certain level of service and then it’s not met, SLA or no SLA, they aren’t going to be happy.
IT Service Management (ITSM) is about understanding the needs of the business through Service Level Requirements (SLRs), and then carefully negotiating what will be delivered as formalized in the SLA.It is operation’s role to then fulfill the negotiated services in a consistent manner.If there are inconsistencies between negotiations and performance, even if it is in favor of the business, then the outcomes could be viewed such that expedited service came at the cost of something else, or the SLA was too loose and IT wasn’t truthful with the business, or IT is potentially overstaffed or over-funded and so forth.None of these perceptions are good and the interpretation depends on who is looking at the activity.
IT definitely needs to provide services to the business that meets requirements. If actual delivery doesn’t match what was negotiated, then the root cause should be understood and the SLA updated if appropriate.It may be that the service has genuinely improved for one reason or another and it would be worthwhile for stakeholders to understand what changed and how it benefits the organization.
The business must view IT as a trusted partner and not one that either doesn’t know what it is doing or is building SLAs that favor IT at the expense of the business.Gold plating by well intentioned employees doesn’t help as these actions can adversely affect expectations and thus perceptions of all the stakeholders involved.
Now that I have your attention, let me explain that ITIL doesn’t fix IT organizations – people do.ITIL is a collection of books that cost a fortune, are colorful, look great on bookshelves and their owners are ascribed near mystical status. Don’t get me wrong, ITIL is a great source of guidance around processes but at the end of the day, ITIL can’t do anything.
First and foremost, an organization wishing to improve has to know what its objectives are.ITIL contains excellent best practices than serve as means to ends but the underlying concept behind IT Service Management is that IT provides services to the organization that meet requirements thus fulfilling IT’s dual role of value creation and protection.
Second, IT needs to understand the current state of processes, culture, technology, management commitment, and resource availability.An understanding of objectives and the current state will serve to ground IT in determining a how to proceed.
Third, IT needs to create a roadmap that identifies what processes will be implemented and in what order. By implementing in phases IT can achieve objectives without undue stress.When I talk to people about ITIL they want to know what to do first and get frustrated when I answer with “it depends on what you want to achieve”.Without understanding the aforementioned details in greater detail, it is the only answer I can give.
Fourth, when designing processes, ITIL is a comparison other.How each process is designed must be based in the decisions made above.One of the reasons for a phased implementation is that it allows for focus and the ability for people to learn and evolve.There is a very real risk of trying to change too much too fast.Taking iterative steps and using continuous process improvement are critical.
Last, don’t forget what we opened with – ITIL doesn’t fix anything – people do.Unfortunately, the reverse is true as well – ITIL doesn’t break things – people do.Care must be taken change the culture as well.Processes don’t just change over night.With deliberate planning and purposeful action, IT must facilitate cultural change and the adoption of new processes across all the stakeholders both within IT and the larger organization.The best processes in the world don’t matter at all if people do not follow them.
ITIL doesn’t involve magic.IT groups looking at improving their processes need to understand what they want to achieve, their current state and then plan accordingly both in terms of process design and how best to facilitate cultural change to achieve objectives.ITIL is an excellent reference source and, in the end, it needs people to understand both it and their organization to decide how best to proceed.
We are definitely in the midst of difficult economic times.Corporations are being squeezed by higher increasing costs for commodities and transportation.Consumers are being hit by rising food and fuel costs.In reaction to these tough times businesses are taking their all-too-predictable short-term reaction – they are slashing IT budgets.
Cost cutting is always an immediate reaction but the problem is that cost reduction isn’t a sustainable strategy.In the past, organization were running with plenty of “fat” in the budget in terms of staffing, operating expenses, capital projects and so on.Cuts didn’t have a dramatic impact on the overall system.
Since the dot com bubble burst we have seen a steady trend of organizations running leaner and meaner.The budgets are very tight and staff are working extra hours to get the job done.Today, typically, IT budget cuts today have an immediate impact.
When we look at IT’s role, it exists to support the business.IT is an enabler – a force magnifier even.When done right, IT can make business units more effective and efficient.Indeed, with current business practices, most organizations can not even operate, let alone be competitive, without IT.The old days of falling back to pen and paper manual processes are impossible.
So who really suffers when budgets are cut?The answer is the business.I’m far from the first person to recognize this phenomenon but not enough business leaders do.IT doesn’t exist for IT’s sake.IT exists to enable the business and without IT the business is stuck or must resort to clandestine outsourcing, shadow IT, etc.These actions can cause security risks, compliance findings and even cause higher total costs.
Instead of suffering the after-effects of budget cuts, IT must reach out and develop a partnership with their business counterparts.I’m not talking about “organizational alignment” from the theoretical perspective.Rather, this is about recognizing that it is in the best interests of IT, the business staff and the organization overall to relate IT activities (operational support and new projects) to business objectives.
When it comes time for funding or budget cuts, management must firmly understand the cause and effect relationship between business and IT activities and how cuts in either area will affect the other.Otherwise, IT will be unable to support the business effectively and both value creation and protection will be jeopardized.
Well, ok, it's really not that simple - some qualification to that answer is warranted.
The advent of ITIL V3 and it's corresponding foundation curriculum has made this questoin of ITIL training an even more complicated question to answer. ITIL V3 is a thoughtful and well-constructed reorganizaton of processes into a lifecycle approach. The ITIL V3 Foundation course however, contains concepts that are more readily grasped by the managers and leaders within the IT organization. The addition of strategic concepts and roles has enriched the subject matter, but pushed the content beyond the interest and grasp of some individuals in operational funtions within the organization for the length of the Foundation course.
This leaves training providers with a dilemna when recommending ITSM training programs for their customers who wish their entire organization to be certified. So what options exist for these organizations?
ITIL V2 curriculum continues to remain alive for operational level individuals. It can be a more appropriate option as it contains the more relevant ITIL tactical and operational processes and can get into each process in more detail. For those organizations really interested in only V3, ITIL awareness training may be a better way to go.
Bottom line is that ITIL V3 Foundation certification training may not be the be the right solution for all levels of the organization. For those organizations looking for Version 3, getting managers and leaders Foundation certified to act as mentors for others in the organization using an "awareness" approach could be the most effective way to get the organization grounded on V3 concepts.
It is important to get the whole organization grounded in IT Service Management concepts - therefore, "yes", ITIL training is for everyone. It is important to put a training plan in place that identifies the appropriate training format/curriculm to provide successful and effective training to all levels of the organization.
I have been in some very dysfunctional IT shops with warring factions that somehow got the job done.In peeling back the layers to understand current state, an interesting common trait became apparent:They all profoundly believed in the organization’s mission.When the IT services failed, they’d go into full firefighting mode and get the services back up and then, they’d go back to dysfunctional silos.
This is fascinating when you stop and think about it – that having a strongly held belief in the organization’s mission could overcome personal and team issues.Granted, this is not enough, but how often do we worry about having believable goals that profoundly affect the people who work in an organization.
When groups are presented with weak direction and leadership there will always be challenges.One of the challenges with IT Service Management is that it requires a change in perspective.It isn’t just about the design and adoption of processes.It’s about fundamentally rethinking how IT provides services to the organization.
When talking with groups about ITSM, they sometimes request metrics and industry case studies so they can create their business cases.When told such studies don’t really exist they become incredulous.“How can something like ITSM exist since the 1980s yet have so few published metrics and case studies?”
The answer – because not many groups have wild success stories that make for great press either for the consulting group, software vendor, media body or even the organization who tried to implement ITSM.For some, such admissions would be career ending.
If a group just adopts a couple of processes that are codified in ITIL they will get very limited benefits.To truly transform, there must be belief in, and understanding of, ITSM’s underlying philosophy and the benefits it can bring once adopted.This transcends implementing processes and takes time, effort and unwavering management support. If you are considering implementing ITSM, in the middle of implementation or renewing efforts, it is very important to always tout the benefits of ITSM at the organization and team levels.People must believe in what is being done.
ITSM isn’t a religion by any means but it does require that the organization understands and sees value in what it will bring.Otherwise, the first distraction that comes along will derail process improvement efforts and ITSM will just become another fallen fad pushed by management onto the organization for unknown reasons.To avoid this, add to your check list two questions – “Do I believe?Do they believe” – and take appropriate action based on the answers.
George Spafford and I recently blogged about how the tools should not lead the process. Gather your requirements, define your processes and then choose a tool that most closely aligns. But when looking for a tool what are the top 5 things you should consider?
1. Choose the appropriate tool for the size, complexity and level of expertise within your organization.
Smaller organizations will not require the tool scalability that is critical to larger organizations. Simplier is better for organizations that don't have the staff or skills to support customizations and migrate those customizations as software upgrades are adopted. These enterprises may want to consider SaaS offerings.
2. Native capabilites or the ability to integrate with other tools to include the following process areas:
Incident Management
Problem Management
Knowledge Management (integration with off the shelf knowledge base products)
Change Management
Configuration Management (ability to integrate or federate to external repositories).
Service Level Management
Service Catalogue Management (ability to integrate)
Service Request Management
Workflow and escalation rules should be customizable for each process.
3. Integration with internal administrative systems (HR or LDAP) for authentication and list of supported contacts. CTI capabilities. Network and system monitoring integration.
4. Reporting capabilities - native reporting should be parameter driven, but the best case scenario affords users the ability to create their own reports.
5. Visualization - dashboards, CMDB CI relationship visualization or service maps, visual process status.
The specific requirements of your organization should lead you to a tool whose architecture, complexity and supported process areas or integration capabilities will meet your current and future needs.
There have been many times when I have been questioned about the master process template for ITIL - as if it ITIL were a product as opposed to a body of knowledge. As is the case for most of us who are in the field of leveraging technology to solve problems and automate business process, we would love to solve as much as possible with a tool. It's familiar; it's tangible; we can relate to it. And we think it can get us to the solution we seek with a greater degree of expediency - depending on the tool, that is ;^).
Unfortunately, there is no one-size fits all template for service management processes. Fundamentally, once implemented, the processes for managing services have similar properties. For example, at a high level the objectives, the inputs and the outputs or the change management process all look the same. But the nuances of a large company in a regulated industry will make the change mangement process have very different gates than a small company in a non-regulated industry.
So, in a fast-paced world, when we would like to get to the end point model as quickly as possible, by implementing the one-size fits all solutions given to us by tool vendors, we may want to think twice before just implementing "ITIL in a Box" and running with it without considering how the specific needs of the organization to operate process successfully. The tool itself may work well with the proper configuration, but unless we have properly considered the process steps appropriate for our organization's size, industry and governance needs and addressed any cultural changes that will lead to successful adoption, chances for success are pretty slim. Spend the time to figure out your process needs, define your processes and then select and configure a tool to closely align.
As I am surfing through web pages today, I see numerous articles touting how a given technology that relates to IT Service Management will directly lead to success.The promise sounds great – buy something and all your woes will be solved.The problem is that reality doesn’t guarantee solutions that will work “off the shelf”.
At its core, ITSM is about providing services that will enable the business to achieve its goals. This service concept is very important for two reasons.First, it helps people to understand in order to enable the business, IT must think like and be a service provider.Second, it’s not just a technology that IT is offering.The service concept helps provide the proper context that anything IT offers is a bundle of hardware, software, people, documentation, processes, facilities, etc.
Next, outcomes must not be left up to chance.In order to provide these services consistently, effective and efficient processes must be formally designed and implemented.These processes are collections of the necessary people, documentation, training and technology assembled to achieve the desired outcome.In the case of ITSM, the results of the processes are the support of the services that, in turn, support the business.
ITMS is not the outcome of a “technology push” mindset.Rather than buy technology and try to get the organization to conform to the tool, the correct approach is to understand the business and then design services and processes that will help enable the attainment and protection of the organization’s goals.Technology then is selected on the basis of its ability to meet at least 85% of the mandatory functional and technical requirements that arise from these processes and not the other way around.In this respect, technology is “pulled” into place.
Some groups I talk to hope that by purchasing a leading tool that the woes of their world will be solved.If the understanding of requirements is circumvented and a tool simply purchased then there is no guarantee that the functionality the tool provides will align with the needs of the organization in question.In fact, an ill-selected tool may even cause greater harm.
In summary, technology is subordinate to the needs of the business, the IT services and processes that are defined.Because technology is implemented to enable these services and processes, planning must not be circumvented.In the end, it is through understanding the needs of the business and putting forth a solution that meets those requirements through the proper blend of people, process and technology that matters most.
When assessing change requests it is important to understand the potential impact of a given change or a collection of changes.While it is common to see IT groups assess the technical impacts, technology is only one dimension, albeit one that IT has the most experience with.What we are more concerned about is the potential impact of a failed change to the organization.
This means involving stakeholders who can provide the relevant perspectives needed.For example, let’s imagine that an organization is publicly traded in the United States and thus subject to Sarbanes-Oxley.If a change is planned that may impact a critical financial system, then a formally designated representative from finance should be involved to assess the risks.The impacts should not be assessed by IT alone.It is possible for finance to “pre-approve” certain low-risk standard changes, but let’s not digress too far from the main theme.
The idea of involving people outside of IT isn’t to make meetings lengthy or create giant email threads that copy nearly everyone in a company.Instead, the intent is to ensure that the potential impacts of making a given change are weighed against the potential impacts of not making the change.These are business risks.
When all is said and done, it is business risk that we are worried about.If a patch fails on a server and the main order entry system goes down during a peak period, it is the business that suffers – not just IT scrambling to recover.
In this situation, a change should have been planned, tested and reviewed per a formally adopted Change Management process.The people reviewing the change certainly need technical knowledge and there also must be people to assess “should we implement the change right now during peak business demand”?In some cases, the answer could be “yes” and others “no”.It is the business that decides what level of risk is acceptable.
So, depending on the change, involve the people who have the necessary perspectives to help assess the business impact.These people may be from accounting, legal counsel, regulatory compliance, facilities, marketing, etc. Who to involve depends on the change in question.One caution – do not have all of them sitting on a call or in a meeting every week with nothing to do.Instead, involve them as needed and help them understand that by their being involved, unwanted surprises can be avoided.
Understanding potential impacts and managing business risks are vital.While technical challenges are one dimension, the ability for the organization to conduct business is even more vital.As such, the right change review stakeholders should be formally identified and involved when needed.
Images
