Real World ITIL Blog - Business Value of IT

IT Transformation and ITIL- Which Comes First- Process or Automation?

info.nospam@nospam.evergreensys.com (JillLander) — Sat, 22 Aug 2009 10:35:00 -1000

It seems an obvious answer doesn't it? The whole idea behind ITIL is best practices in PROCESS improvement- right? But how many times do we see ourselves and our peers looking for a short cut to solutions through technology that automates. As an ITIL consulting firm, over and over we see clients that pay lip service to ITIL process transformation but are often looking for technology alone to solve the problem. IT otpimization and transformation, it seems, at its core, is simply analysis of tasks and workflows that are repititious and can be streamlined and automated (through technology). And yet how can you possibly identify those that are good candidates for automation with analysis of process? And once processes that are good candidates for automation are indeed, changed, that leads to new, improved processes. Right? Please write and give us your opinion on this topic- which comes first, the process chicken or the automation egg? Jill Lander Evergreen Systems

Lessons Learned

info.nospam@nospam.evergreensys.com (scottdavis) — Tue, 29 Jan 2008 21:25:00 -1000

Joel your question about unsuccessful ITIL implementations is a good one. Although I can’t really provide any specific customer detail for a case study due to confidentiality, yet I can provide some overall insight and opinion based upon experience and other guidelines I’ve seen through industry analysts, scar tissue and the wisdom of others

In my opinion, the only real failures are those companies who choose “NOT” to adopt ITIL best practices. Success improves from there. That said, some companies embarking on this journey only achieve minimal levels of success. In my view, ITIL implementations can struggle in a couple of key areas:

Overall Program Management
Focus to Technology as the Solution

Program ManagementITIL implementations are usually large and complex and solid Program/Project Management discipline is required. Some companies start the struggle with grand plans based upon a huge scope and unreasonable expectations – then lack the organizational maturity (People & Process) to deliver to the expectations. The desire for real, quick value can be overwhelming and must be balanced with the realization that this is a “journey”, not a “sprint”. Getting strong sponsorship up front is critical. Beginning with a true assessment, needs/gap analysis and identification of how to lay a solid foundation while achieving quick wins with real business value can help to avoid that “period of blame” that can quickly set in. It’s kind of like building a house – or more specifically – like a large renovation and expansion project. In the first year, you are laying a new/additional foundation with a huge amount of new or altered processes and changes in the culture. Yet, you are living in the house at the same time, so you have to face up to the challenge to achieve/maintain business value and sustain momentum until the roof is on, the carpet is in and the new areas are “livable”. Your new foundation could possibly be a simple start in the area of things like “asset management” & then extending that to “Configuration Management” or by enabling some key wins in the areas of configuration management and incident/problem management with vision to move next to release and change. Bottom line: start with a real baseline/foundation and build quick wins and value on that.

Solid Program/Project Management with focus to project initiation (scope, sponsorship, communications) is a real help in this area. Yet, sometimes, even those who drink the cool-aid and apply best project management practices struggle. The best guidance I could provide for those struggling with current projects is: revisit your roadmap, limit your scope and extend your project as best you can and always deliver with a business value mindset. Even if you have a “failed” project in your lap, it may still be salvageable through recognition of the value you have already achieved, resetting expectations, re-aligning scope with business value, and re-visiting your tools, roadmaps and next steps.

Technology Mindset - The root causes of failure to achieve expectations in ITIL implementations can be often be a misplaced focus to the “technical” rather than the people and processes. It is not uncommon for the tool selection and purchase to come first (hey, there’s a glut of very good software sales teams out there). While software plays a huge role in ITIL, a tool first approach can actually impede success. To me, ITIL is not using best practices to use or manage technology - It’s about planning, executing and continuously improving a core set of processes to affect business outcomes. The technology simply supports that. I’ll sum it up like this…”would you buy a $10,000 lawn mower (tool) before you executed the process of obtaining financing, house-hunting and determining what type of property you even want. Probably not… but it you did … would you then allow your lawnmower (tool) to drive the process of purchasing your home (location, financing, funding, etc…)? What if you decide you want a condo? Hello Craigslist!

A solid CMDB is the key to any successful ITIL journey and there can be numerous speed bumps along the journey to a successful implementation. Try not to think of a CMDB as a technology and definitive reference repository. Rather consider it an overall set of processes, technology and culture designed to provide information to deliver business decisions and outcomes. Some software vendors may try to espouse their CMDB as the definitive repository. Try not to think of your CMDB as a single database. Successful CMDB systems usually contain a variety of information and data in various repositories across your organization (known as “federated” data). Relying on a single point of information sets you up for a slew of “data integrity and credibility” issues the first time your replicated data delivered from the single CMDB fuels incorrect decisions. The key success factor here is to enable a comprehensive CMDB systems and processes that provide referential integrity and “metadata” pointing to the real, “trusted sources” of the data where it resides – not trying to get it all in one place.

Once you know where to get the real, trusted data and are able to refine your contextual mapping to business services, the challenge is to make transform the data to information and knowledge - actionable to the decision making processes that consume it.

There are many other reasons that ITIL projects struggle… continue reading through Evergreen’s blogs, whitepapers and I’m sure you’ll find more… Hope this helps!

Scott M. Davis Process Consultant

Evergreen Systems

512 983-6492

scott.davis@evergreensys.com

Meeting Tough Customers Over Incident Management

info.nospam@nospam.evergreensys.com (scottdavis) — Thu, 10 Jan 2008 21:41:00 -1000

So you are scheduled to meet with that really tough customer who has issues with your overall service desk or incident management performance. My experience in running an incident management organization of over 100k problems per year supporting Fortune 500 customers may help with an approach that almost always facilitated a healthy and productive (although sometimes painful) customer outcome. Key Mantras:

Do your homework
Listen
Open your Kimono…Commit to improving your customers life
And do what you say you’ll do.

I was never big on Homework in school, but found the value in real life. The quote “those who don’t learn from history are doomed to repeat it” fit’s well in these scenarios. Demonstrating you know your customer is a key ingredient to constructive relationship management and overall service improvement. Try following these guidelines:

Drill down in to your standard service desk & incident/problem KPI’s from a customer perspective. Take a deep dive into the trend of incidents and problems with that customer, or department/organization in relationship to your overall KPI’s. What do you see from those trends? How do you stack up with this customer? Was the call response timely? How many incidents did they report per period? Is that trend higher than normal? How many are still open and how does that relate to your overall trends? How long have they aged? Do any customer specific patterns related to root cause appear obvious that you can learn from or that the customer can learn from.
Can you assess whether you are following documented process? Was each action planned and action taken well documented? Was relevant diagnostic data needed captured and analyzed in a timely basis? Were expectations set and followed through with the customer? Did a high percentage of calls result in some sort of escalation?
How was the tone of the incidents & how were our customer care skills?
What’s the history regarding service level performance?
Is there any funding or revenue dependent upon performance or known issues?

While looking at a single customers’ incident management experience doesn’t always offer trends, I always found that a little bit of research always facilitated two key areas of improvement:

how can we do better at resolving the incidents faster, more effectively and with customer focus
how can we help the customer help themselves (ie training, better diagnostics, expectations, etc…)?

You can add these approaches to some standard root cause analysis and gain a wealth of insight. At a minimum, the customer you are meeting with will certainly understand that you’ve taken time to know him better.

While all this historical self inspection and assessment is good stuff – it doesn’t relieve you of possibly the most important rule of thumb and that is: “listen to your customer”. My mom used say: “take the cotton out of your ears & put it in your mouth”. Sometimes I hate it when mom is right. I’ve found that customer perception and expectations can be managed, only in so far as I understood them.

Listening carefully enables me to find out what makes my customer tick, what drives that manager/executive’s success, where their pain is and how my service execution affects their business outcomes. One lesson I learned this way is that multiple open low priority incidents can equal customer perception of low service value and high business impact.

Bottom line: Customer perception trumps service providers interpretation of the facts – add one layer of scar tissue… “thank you, can I have another”.Understanding the facts and listening to the customers viewpoint help open the partnership to a mutually beneficial, open and honest discussion If a real inventory of your performance and the customer view uncovers a few “cockroaches” … “it’s all good! Continuous Improvement is all about exposing those little buggers, finding their food source ( ie.. getting down to the real root causes in your activities, isolating work instruction flaws and/or execution improvement) and then shining the light on the next set of the little buggers (sound like plan do check act?) Open your Kimono to your customer where it makes sense… It develops trust in the partnership. Hiding your warts & playing the roach only degrades the relationship and you’ll ultimately lose their faith and honest appraisal (right before they replace you. As you find real root causes in your area, that causes their pain, be honest and tell them what you found and what you plan to do about it (even if you it means you aren’t going to address it at present). Invariably though , these scenarios will drive you to constantly improve the activities and work instructions within your incident and problem management process and the honest approach with the customer increases the level of partnership.

I’m sure none of this is new to may of you…and of course your mileage may vary. To me, In the end, It’s all about showing your customer – Big C & little C that you have insight into their world, that you care about their pain are serious about continuously improving and executing a process they depend upon to deliver their business success.

Keep up the good work!

Scott Davis

Evergreen Process Consultant

Learn more by downloading our most popular white paper below:

Developing the Business Value Of ITIL

What’s Good for the CMDB is Good for ITIL Service Level Management

info.nospam@nospam.evergreensys.com (DonCasson) — Mon, 30 Jul 2007 21:58:00 -1000

In my last blog I laid out the proposition that Configuration Management and a CMDB is all about Change and that CMDB and Change are ‘partners’ in executing the work of IT efficiently and accurately. Seems pretty clear, right? Then it should be easy to justify and implement a CMDB based on large numbers of Changes, right again?

Not necessarily. Justifying, developing and implementing a CMDB is not an isolated activity, a technology implementation or a database development effort. A CMDB is a means to an end, not an end in itself, and the end(s) are increased ITIL best practice Change Management and control and increased Configuration and Release Management control.

So the business value of a CMDB has to be built on results achieved in other ITIL practice areas, including an improved Change and Configuration Management process, better Change control and overall better service level management. These objectives have to quantified to prove metrics that could include:

Business process re-engineering
Change Management lifecycle improvements
Change Management approval board activities
Change and Configuration Management executions
Metrics to support and make the case for improved Change and Configuration Management and the CMDB

Ultimately the CMDB should be profiled as a crucial tool to the improvement of overall ITIL best practice Service Level Management and an important underpinning to an accurate and effective Asset Management system.

A good CMDB is good for Change, Configuration and Release management and ultimately good for the entire ITIL Service Level Management process.

Do you agree?

Until next time,

Don

Also, don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

Are you trying to build a business case for a CMDB? Download Evergreen’s newest white paper on the subject: “The Business Case for Change and Configuration Management and the CMDB”.

CMDB and Configuration Management – Is It All About Change?

info.nospam@nospam.evergreensys.com (DonCasson) — Mon, 23 Jul 2007 22:00:00 -1000

Is the business value of a CMDB all about Change Control? And what if your organization performs root cause analysis? Do you really need a CMDB? We’ll address these and other CMDB, Change and Configuration Management issues in a new series of blogs this month.

As enterprises and their IT support organizations grow, their infrastructures become increasingly fragmented and spread across a variety of functions, technologies and organizations. As this IT infrastructure ‘sprawl’ continues, efficiency, optimization and overall control over IT resources suffers. Organizations often address the IT infrastructure ‘sprawl’ issue with automated or, in some cases manual, Change ‘root cause’ analysis tools. These tools analyze changes, in many cases failed changes, to get at the ‘root cause’ of the problem.

Although root cause analysis is critical to the improvement of change control, analysis that doesn’t take into account all configuration items (CIs) and their inter-relationships can be reactive, incomplete and in some cases, downright ineffective. Spreadsheets and manually maintained asset and specific purpose configuration repositories also do not sufficiently take into account the inter-relationships of CIs and can fall far short of effective root cause analysis for complex IT infrastructures.

So here’s my proposition - change process and CMDB are ‘partners’ in executing the work of IT efficiently and accurately. At the highest level, change is the workflow of IT and the CMDB is the information store that provides data to support the decision-making process. This partnership is the functionality that drives an efficient change flow engine.

Until next time,

Don

Also, don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

What do you think about the relationship between Change and Configuration Management? Download Evergreen’s newest white paper on the subject: “The Business Case for Change and Configuration Management and the CMDB”.

Value of the Post Implementation Review (PIR) Or we don’t need no stinking PIR

info.nospam@nospam.evergreensys.com (DonCasson) — Mon, 12 Mar 2007 22:01:00 -1000

People don’t seem to take the ITIL PIR concept seriously. Reviewing changes and projects are like hated exam papers. When they are turned in, no one wants to look at them again, regardless of grade or outcome.

But the PIR is an opportunity to learn and to avoid repeat mistakes thereby freeing capacity. And isn?t the lack of capacity one of the chief complaints from your staff?

So if you agree, your next question will probably be how to institutionalize the PIR into a formal component and ensure that the feedback loop is not broken?

The PIR needs to be owned by the original authorizing agent, typically the CAB. The rational is that people or teams who authorize something are accountable for the results.

Individual performance should include PIR contributions bonus points for identifying good corrective action, penalties for repeat failures. Plus it?s a concrete and easy metric to track.

Changes can be 1) bundled for efficiency or 2) setting a risk threshold for when a PIR is required. So you can?t use the excuse there?s too many to review.

Enabling workflow technology is needed (please don?t build your own) so the process will be enforced.

Yes and I have to say it, IT leaders (i.e. not managers) must expect improvement and reward individuals who help avoid repeat mistakes. If you only reward staff by solving 911’s then when will you ever stop to sharpen the saw?

Download Evergreen’s free Change Management Policies and Procedures Guide

Developing the Business Case for Change, Configuration and/or Release Management, part 2

info.nospam@nospam.evergreensys.com (ScottBraden) — Tue, 06 Mar 2007 22:02:00 -1000

Last time I shamelessly teased you by stating that speed, quality and cost can all be improved at the same time. Now I’ll tell you how I’ve seen it done in real-world IT shops.

Here’s the secret: they implemented strong, mature ITIL-based Configuration, Change and Release Management.

Here’s why it works: as I said, these three processes are tightly linked at almost every step.

For example, your planned changes (RfCs or Requests for Change) are assessed for impact and risk and which Configuration Items (CIs) are involved by using the relational data about your infrastructure that?s stored in your CMDB (Configuration Management Database).

Then, the Change Management process hands off the actual implementation of many (but not all) changes to the Release Management process, which is responsible for building, testing and implementing the actual changes to the infrastructure.

And of course, the CMDB gets updated with the new information about the CIs that have changed.

Because of this tight linking, smart companies are able to build in a high degree of control and quality checkpoints. For example, if a planned rollout fails, you want to be able to trace the cause of the failure back to its origin. When you build mature processes and tight controls, then review and act on the data and metrics you capture, you have specific, clear, measured information that you can use to make improvements in your policies and processes and procedures. It?s a continuous feedback loop.

Result: your operations become more efficient. Your shop can deliver more changes, with higher quality and reliability, at lower cost. CIOs love that stuff.

Till next time, keep up the good work, and ask yourself: ‘in our shop today, when a change causes problems, do we rigorously go back and find out not only the technical cause of the issue but the process or procedure gap that allowed the tech problem to sneak in?’

Scott Braden

Download Evergreen’s free Change Management Policies and Procedures Guide

Also, Don’t forget to register for Evergreen’s change management webinar: Take Change Management from Firefighting to Fire Prevention

Developing the Business Case for Change, Configuration and/or Release Management

info.nospam@nospam.evergreensys.com (ScottBraden) — Mon, 05 Mar 2007 22:03:00 -1000

When we’re working with clients to help them map out a long-term plan for ITSM (IT Service Management) using ITIL best practices as a guide and benchmark, one of the most important questions is “Which ITIL process should we work on first? Second?”

Well if you read my blogs, you’ll know my answer is going to depend on the results of the assessment, which makes heavy use of ITIL KPIs and metrics that IT and the business would like to see improve.

What’s not always so clear for clients is how to translate a business requirement or SLR (Service Level Requirement) into specific process changes that are needed to meet the goals.

For example, most businesses I’ve worked with in the past few years are looking for some combination of improved speed for IT to deliver changes, without hurting service quality and while keeping costs under control. Some of you are laughing already, as you recognize the old joke about ’speed, quality, price – pick any two.’

But, it is in fact possible to improve all three, at the same time. One of the most common examples I see is in the areas of Change, Configuration and Release Management. These three ITIL processes are very tightly linked, so that we frequently recommend that clients begin their SIP (Service Improvement Program) by focusing on these together, or at least in a very compressed time frame.

Next time, I’ll tell you why – till then, keep up the good work, and ask yourself “of the Changes our shop puts into production, how many are on time, on budget and produce no unknown errors?”

Scott Braden

Download Evergreen’s free Change Management manual

Also, Don’t forget to register for Evergreen’s change management webinar: Take Change Management from Firefighting to Fire Prevention

Conducting ITIL Assessment

info.nospam@nospam.evergreensys.com (ScottBraden) — Thu, 01 Mar 2007 21:54:00 -1000

When I’m working with clients on ITIL awareness training or conducting an ITIL maturity assessment, there’s always a tension between ‘what the official ITIL book says’ and ‘how can we implement ITIL in the real world?’

For example, the ITIL maturity model defines four levels of maturity - Repeatable, Defined, Managed and Optimized. So for a given ITIL Process, such as Configuration Management, we assess the client?s current state and assign a score. Looks really simple, on paper.

But in the real world, it’s not so clear. For example, ITIL assumes (or at least strongly recommends) that you have consistent company-wide policies and processes. But very few real-world IT shops have common processes - whether ITIL-driven or not - even between adjoining departments within IT. So- how do you score the company on the maturity scale?

You would be correct if you answered: “with much debate”.

That’s why it’s so important to get past ‘the official ITIL Configuration Management Process’, for example, and instead ask questions based on KPIs (Key Performance Indicators). For example, in Configuration Management one of the usual KPIs is the accuracy of the CMDB (Configuration Management Database) as measured by periodic audits of the data. This is a specific number, arrived at by a specific, defined process that nobody can argue with.

So when you’re considering your ITIL maturity level, think in terms of measurements, not in terms of comparing the descriptions of your processes with the text in the ITIL books.

Till next time, keep up the good work and remember - what gets measured gets improved.

Scott Braden

Download Evergreen’s white paper on developing the business value of ITIL, including the development of metrics, at “Developing the Business Value for ITIL”.

A Simple Method To Estimate And Measure Real Business Value Of Process Improvements

info.nospam@nospam.evergreensys.com (ScottBraden) — Fri, 12 Jan 2007 23:04:00 -1000

Last time I talked about why it’s so hard to estimate and measure business value. This time, I offer the outline of a solution that has worked for many IT shops.

But first I have to give due credit and say this is not my idea. I learned this many years ago from a very smart guy named Mahan Khalsa and his course called “Helping Clients Succeed.”

Here’s the method that we use, in brief:

Define the real opportunities, challenges and issues. For example, “implementing ITIL” is usually not the opportunity. The real opportunity may be that “the business doesn’t believe that we’re cost effective” or “the business wants faster delivery than we can provide so they’re going outside” or “we’re so busy fire-fighting we don’t have time for the real proactive work that we know needs to get done.” Spend a LOT of time in this area.
“In a crisis if I had only an hour I’d spend the first 50 minutes defining the problem and the last 10 minutes solving it.” -Albert Einstein
Find or develop evidence. This means DATA, not opinion. For example, if your core problem is “we’re so busy fire-fighting we don’t have time for the real proactive work that we know needs to get done,” then how would you show that in terms of measurable data? Would it be projects completed on time, or total Incident volume, or percentage Incidents solved at 3rd level versus 1st level? Or (most likely) some combination of several of these?
If you can’t find or can’t develop evidence, you either haven’t defined the right set of problems, or you need to pause the project and do some assessment work first. As Mahan says, eventually some executive will say “Before we write a check for this, could someone please tell me how we’ll know it’s money well spent?”
Find or develop Impact. This part is relatively easy, compared to defining the problem and getting evidence. Simply ask a few questions:
- how do you measure it (the impact)?
- what is it now (current state)?
- what would you like it to be (future state)?
- what’s the value of the difference (impact)?
- what’s the value over time (whatever timeframe your management uses for looking at this type of funding decision)?

But what about those soft, squishy outcomes I mentioned earlier? Maybe your problem was “the business doesn’t trust us to deliver on-time, on-budget so we’re in danger of having some functions outsourced.” Well how do you get evidence and measure the impact of improved trust? Well, this is the part that’s really hard for co-workers to do, especially IT people. It involves asking emotional questions, talking about personnel and HR issues.

So, what’s your big problem that you need to solve? What’s the nagging fear that’s gnawing on you, driving you to look for solutions?

Also, check out our new White Paper on “Developing the Busines Value for ITIL”.

If you’re involved in building business cases and scopes for large projects, I encourage you to check out Mahan Khalsa’s stuff: Helping Clients Succeed

Till next time, keep up the good work.

Scott Braden

Technorati Tags: help desk itil help desk software software

—–