A common and effective example I use to convey the ITIL message for Service Support is to use an analogy within a Hospital.

Someone walks into an emergency ward with a severe arm injury causing bleeding.

The receiving desk (ITILs Service Desk) receives the patient and begins documentation, assesses the situation, and tries to administer first level support. Based on procedure (the OLA), the receiving desk may have to escalate to the triage team (ITIL Level 2 support). If the situation warrants higher expertise, then the doctors are called in (ITIL Level 3 support). This current flurry of activity is focused on stabilizing the situation (and not diagnosis) as quickly as possible (consistent with the Incident Management goal of ITIL).

Once the situation is stable, there is time to run tests and perform diagnostics to investigate the root cause and true nature of the injuries (this is Problem Management and the Problem Control activities). Upon finding the underlying cause, the medical team can recommend a solution and would typically consults with other experts to get a second opinion. The most agreed upon solution is the one implemented (these are the Error Control activities).

The medical team with the appropriate skills would be assigned the task of planning and documenting the medical procedure (in ITIL this is the group that creates the Request For Change - RFC). The plans are submitted and approved by the Board of Governors (in ITIL the Change Advisory Board – CAB). The medical procedure is carried out and verified successful by the medical team, and is also independently validated through post-procedure care and monitoring (in ITIL this is Change verification).

With a successful outcome, all records are closed by the receiving desk (the ITIL Service Desk) and the patient is released to “normal service”.

Something that hopefully gives you another perspective of what ITIL has to offer. ITIL is not new; it’s borrowed, and there are many examples that can be referenced outside of the IT perspective.

Have you ever noticed?

How productive you are when you work during the Holiday season?

How good it feels when your email inbox is less than one page?

How you often let your inbox manage your day?

How many people use their inbox to manage tasks?

Me too. Now do a little digging. How many of those emails come from people within your company?

If you are like most people I know, you spend 1 to 2 hours a day “processing” email and 70% to 80% of that is from your colleagues. Do the math. In the average 20 person department or company you are probably spending $250,000 a year paying people to “email”. As the old saying goes, “that’s not putting shoes on the baby”.

Take heart there is a solution. As we pondered this over the Holidays at B Wyze we came up with the answer. Some of our clients have “email free” days. One day a week they don’t send any internal emails. Our casual research told us that this helped increase their employees’ productivity one day a week. On the down side the day before and after there is a noticeable increase in email traffic.

So, what did WE do? Simple, the email moratorium challenge. We challenged every employee to limit their daily email traffic to any other employee to two per day.  Book meetings (with agendas) to your heart’s content and assign specific actionable tasks with due dates (we use exchange) as often as you need to. IM, and phone calls, no problem.

So what happened?

I’ll use my blog posts to share interesting ideas/frustrations/stories from my conversations with ITSM Management.

Incident Categories - AWESOME perspective!
1.  Ticket comes in.
2.  Ticket gets categorized based on what the Service Desk Analyst believes to have caused the incident.
3.  Ticket get escalated.
4.  Ticket gets closed by 2nd or 3rd level.
What’s missing here?  What is the categorization that 2nd or 3rd level would use to classify the ticket!?  That’s the true classification you’re looking for.

Balancing what is new and what is efficient
We’re in IT, and IT is cool to us.  That’s sometimes the reason that network, security, and applications groups want to implement new technologies.  However, IT is a service to the business, and as such we must ensure that we balance what is new and what is feasible given business needs and budgets.
When considering new technologies, make sure you perform a:
- Benefit Analysis
- Cost Feasibility Analysis and
- Risk Analysis
Good questions to ask:
- Should we implement a new solution now, 6 months from now, or next year?  
- How will the change interact with other changes already scheduled?

MJ

I’ll use my blog posts to share interesting ideas/frustrations/stories from my conversations with ITSM Management.

Change Management Automation
1.  Manager created the change process.
2.  In Heat, he designed the entire process in the tool, from proposing change and linking it from an incident ticket, holding all RFC-related documents like test and back-out plans, to asking CAB (Change Advisory Board) members for approvals, etc.  
3.  A report on all approved RFC’s would be run by the CAB Lead before every meeting.  Therefore, the CAB meetings were concise and to the point.
4.  Changes given to Release Management.

How to get Developers to adhere to your baby, the Change Management Process
1.  Instruct them on change process.
2.  Watch them not follow it.
3.  Redirect!!
4.  Once they start seeing that less production environments get escalated to them, and in turn they can work on the assignments they would like to instead of firefighting, they will buy in even more.  Remember that 50-80% of incidents in production are caused by ill-managed changes.

Enhancing Buy-in & Adoption for Process Changes
1.  Create process
2.  Bring everyone in the room and show them how the process works operationally in the tool they’re using.
3.  Ask them to poke holes in the tool.  Too often training happens and the technical staff go to lunch and tear apart the process.  This way, you can capture the constructive criticism from the process executors and make them part of the process reengineering.
Institutionalizing process changes, especially when it comes to Incident, Problem, and Change Management, does not occur when documentation is created.  Too much time is spent documenting.  We’re businesspeople, not Lead Editors for an ITIL newspaper.

MJ

Mike here, Director with B wyze.  I’ll use my blog posts to share interesting ideas/frustrations/stories from my conversations with ITSM Management.

Band-aid solutions

Instead of buying the appropriate storage equipment as advised, patchwork storage hardware was used.  The power capacity on the datacentre is now at above 90% usage!  Scary stuff.  What’s the worst band-aid solution you’ve seen?

You think you’re busy?

A Transition Manager I talked to today from an Outsourcer handled 2-3 migrations (i.e. Service Desk outsourcing) simultaneously, working 20 hour days during peak periods.  I couldn’t make this up!  What’s the longest you’ve ever worked?

MJ