SysAid Blog

Blog Home
Welcome to the SysAid Blog - the place to go to find out where the IT industry is going, and what is SysAid’s role in it.

Workshop as a Blog: How to Mature a Service Management Process

Posted by on March 31, 2015 in ITIL
.itSMF Conference workshop I recently attended itSMF Norway 15 Conference. What an incredible experience with some of the most dedicated people in IT service management! I had the privilege of being one of the Service Bazaar workshop leaders. My session was How to Mature a Basic Change Management Process. The format was groups of up to 8 attendees in each of three 90-minute workshops. Each group had industry leaders (including ITIL book authors) and beginner practitioners side-by-side. The sessions were lively to say the least, and everyone learned something. Me? I got a triple dose, and learned the most. This blog isn’t a traditional How-To, but rather a summary of some gems that came out of my three workshop sessions. Note that while the sessions focused on maturing Change Management, what we learned applies to any process.

Start With Why

Leadership expert, Simon Sinek, gave a TED talk entitled Start With Why. He explains how the human brain is wired to need a why before accepting what or how. One of the challenges we face in IT service management (ITSM) is our tendency to focus more on the process, and less (often much less) on the desired outcomes and business value they create. In other words, we jump directly to what and how, and bypass why entirely. If we (and the business we serve) aren't in agreement and completely clear on the business outcomes that the proposed process maturity will achieve, we've already lost the battle. So, before we set out to mature an ITSM process, let's pause and ask a tough question:  why do you want to mature the process? And, as you may have guessed, all three groups I worked with came up with some good and some not so good reasons why. Let's get some of the not-so-good ones out of the way first:
  • The ITIL book says so
  • The ITSM consultant/expert said so
  • Process assessment rated the process low maturity
  • We need to be more like...
Better reasons why:
  • Reduce post-implementation incidents and business impact
  • More rapid implementation of beneficial changes
  • More responsive to business needs
  • Regulatory compliance
Don't worry if you struggle with the question itself, or find yourself drawn to some of the first answers. I’ve been there myself. Big part of why I'm so passionate about this is because starting with the wrong why will cause nothing but heartache and be an uphill battle. Remember that the goal of ITSM is to enhance business performance and remove barriers. It's all about business value and the results the business is able to achieve as a direct result of improvements in IT services. You need to start with an easy to understand, business-value WHY. Keep in mind that it's possible the current maturity level of a process is sufficient, and maturing it further will not increase business value.

What Are the Obstacles?

After we finished with the whys, each group then came up with a list of obstacles they face in maturing their Change Management capability. The list was lengthy and sadly all too familiar:
  • Too focused on technology
  • Too focused on processes
  • Insufficient senior leadership support/involvement
  • Insufficient resources (staff/funding)
  • Not a business enabler
  • Too bureaucratic
    • Too many forms
    • Process bottleneck
  • Lack of shared vision
  • Inconsistent understanding (terms, scope, goal)
Quite a list of obstacles, wouldn't you say? Where do we even start?

Circles of Influence

It's very tempting to focus on things that really should be in place. Things that are out of our control.  For instance, senior management really ought to be committed (bonus points if you get the double meaning!) When faced with such a daunting list, I find it helpful to label each along these lines: Can I control it directly? Can I influence it? Stephen Covey described this in his timeless Circle of Influence.

Stephen Covey's Circle of Influence

In short, there are things in your direct control, things you can influence, and beyond that—things over which you have no control, i.e. "gravity issues". If you want to make real progress, focus most of your energy on things you can control, and some on things you can influence. But those outside of that, don’t waste your energy.

Good Old ABC's

Next we took a look at the good old ABCs (Attitudes, Behaviors, and Culture.) If you're not familiar with ABC of ICT™, take a moment to check out the phenomenal work of Paul Wilkinson and team. The short of it is: Attitude - What we think and feel. Behaviors - How we act based on our attitudes. Culture - The collection of accepted behaviors within a group. In one session at itSMF Norway, we labeled each obstacle as A, B, C, or other. Guess what? More than 80% of them were ABC issues. In other words, non-technical, non-process, non-ITSM issues that relate to people. Of the three, you're more likely to change behaviors than attitudes or culture. It's been said that you change the culture one behavior at a time. You’ll never overcome ABC issues with process and technical solutions. For instance, if your Change policy states that all changes must come to a Change Advisory Board (CAB), leadership must consistently address those who do not. It’s not a process issue, it’s a people issue! If the behaviors are not dealt with, the culture, in fact, accepts unmanaged changes. But change the behavior, and eventually it becomes a cultural expectation.

Start Small and Mature in Phases

One challenge with any service management process implementation is trying to adopt a fully-mature process. Many times these efforts fail because it's too big of a leap for the organization. Fully-mature processes are also dependant on other processes that may not be in place yet. In the workgroup, I talked about a multi-phased approach to introduce a very basic process, with clear checkpoints to incrementally mature. The approach is basic Continual Service Improvement, and it works. Stuart Rance wrote The Help You Need to Adopt Continual Service Improvement, which includes a handy downloadable whitepaper.

Getting It Done

The Service Bazaar was an overwhelming success. The sessions were filled with engaged, passionate service management professionals. The collective knowledge was incredible, and the energy was off the charts. We boiled process maturity down to some key elements:
  • Start with why
  • Focus your energy on what's in your control
  • Change the culture one behavior at a time
  • Start small, and plan for incremental improvements
Join the conversation. What have you found helpful in maturing IT service management processes? Photo credit: Simone Jo Moore

Like this article? You may also like: 4 Things You Need to Know About IT Maturity Assessments

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Human Communications Protocol

Posted by on March 26, 2015 in Service Desk

.ITSM communications is a two-way process

How many times does the word ‘communications’ get mentioned as an issue in your organization (and we’re not referring to networks and routers)?

The basic human function of communicating information accurately and appropriately between people seems to pop up regularly as the reason for failure, the stumbling block, the broken link in the supply chain, and generally as the barrier to success.

Often the term ‘communications’ is used to cover a multitude of issues, from lack of information, to too much information, plus of course inappropriate information. Usually, however, this comes down to the extent to which individuals are aware of their own communications actions (or lack of them) and how this is received or experienced by others. Often it’s about misunderstandings, or in some cases personality clashes – i.e. when people don’t get on with each other.


The net result however is usually some form of problem: waste of money, delay, additional cost, failure of delivery, loss of service, missed business opportunity, etc. So communications failure isn’t just about people not being nice to each other – it’s a real business problem.

Consider the following scenario:

Your organization may be implementing a new technology service and needs some external (paid) consultancy to help with technical implementation. However the consultant is booked to arrive on a day when the person who needs to give said consultant access and support to your infrastructure isn’t available, or even aware of this happening, so the cost of the consultant is wasted.

Why did this happen? Maybe no one contacted and booked time with the relevant people. Or maybe an email was sent but didn’t make it clear what was expected, or even was sent with the assumption that all involved were okay with the details and didn’t check up. Nobody purposely meant to fail, but poor communications meant that the result was failure.

Of course when you get large projects and these gaps are not managed, this can have a huge impact on budget and delivery targets – and this regularly does happen when dependencies and logistics are not closely and dynamically managed. In addition, you are probably already aware of the potential for misunderstanding when escalating incidents and events between teams, if written and verbal notes between teams are not clear and very specific.

Technology can go so far in reducing these issues but ultimately this comes down to how well people communicate with each other as human beings. How can we make this better, particularly as people working in technology where communications is a huge part of what we do apparently…hmmm.

Send and Receive

Communications must be a two-way process. Successful communications only happens when messages are not only sent, but also known to be received and understood.

Too often in IT we think that simply sending out a message (e.g. an email) is sufficient as a form of communication, when in fact this is only (the first) part of the process.

It might be useful for IT folk to consider one of the most basic of all IT standards as a parallel – i.e. communications protocol.

As soon as computers began communicating with each other, and across geographical divides, it was established that simple protocols were needed to establish that contact was good – reliable, continuing, consistent, and also two-way. Communications protocol states that all electronic communication is predicated on the following steps:

  1. Making contact– verifying and acknowledging the link. This happens as a 2-way process, with send and acknowledgement messages being exchanged.
  2. Maintaining contact– ensuring that the contact remains in place and that messages are exchanged successfully. This involves a continual process of send/acknowledgement messages.

Technology communications protocols do the things that we humans often forget to do, namely: (1) check and acknowledge that contact has been made and (2) keep checking and verifying this.

It’s never enough to simply send a message to another party; there needs to be an acknowledgement back that the message has been received. If no acknowledgement has been received then the sender needs to take some further action to establish and confirm that two-way communication has taken place.

So, if computers do this, why don’t we humans follow the same approach?

Appropriate Human Interactions

Of course it is important to check that your messages have been received and understood, and to then also check/verify the next course of action that will be taken and by whom. This comes naturally to some people, whose personality drives them to check up and chase for responses and answers when they send out messages. These individuals are great for incident tracking and SLA management, as well as driving for results for longer term issues or problems.

Unfortunately, this isn’t always a natural condition for technical people and often they need systems (and nagging) to drive them to check up for responses. One way or another there needs to be a culture in organisations that ensures that ‘sending is not enough’. Follow up/chase activity is just as important, and is the responsibility of the sender until a response has been received.

Here are some further recommendations that can help to improve communications and thereby reduce problems:

  • Think about the message that needs to be communicated. Communication will be more successful if there is a clear objective in terms of message that needs to be sent. Try to edit and remove non-essential details that might distract or confuse the key message. Often IT projects can over-communicate too much information that is unnecessary and actually blocks the understating of the key messages.
  • Write using appropriate language for the receiver. There’s no point in using jargon, technical, or IT process language when trying to communicate with non-IT people – so don’t do it! It’s actually quite patronizing and disrespectful to include content that your audience doesn’t understand or have any need to know, and again this will reduce the impact and level of understanding of your intended message.
  • Test the understanding of your messages. It’s useful to use a number of informal feedback loops, for example the coffee machine conversation, to check senses and understanding of what you have communicated. There’s nothing like a dose of reality to help you to improve and refine your messages and the various media that you use to send these out.
  • Simplify / visualize / tell stories. Words and text are useful forms of communication but of course they are only one form of contact. Pictures and simplified short sentences are more memorable and therefore more likely to stick in people’s minds. Nobody tells a child a bedtime story using PowerPoint slides and bullet points – for a good reason. Stories require emotional engagement and use of the imagination for understanding. This actually uses more of the brain than simple text and therefore will be more likely to be retained. Use this principle to send out simple clear messages to individuals or groups.

Overall it’s important that IT people understand that they need to be good communicators to be successful at their jobs. IT people need to be able to use some basic communications skills to show that they are listening and understanding. In other words – even though they are usually listening and understanding, they just need to make it clear to their customers that they are doing so. The great news is that this is not difficult and it will only take a few changes to really make a difference..

Image credit

Like this article? You may also like:
The Service Desk and Relationship Management: All You Need Is Love

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.

Continue reading

We Don’t Do People!

Posted by on March 18, 2015 in Service Desk

In IT, we don't do people?!.

When I started in the IT industry I was a fairly junior hardware engineer. One day I went out with an experienced engineer to learn about a particular mini-computer that he was going to mend. It was a complex problem and I learned a lot from watching him work. On returning to the office our manager told us that she had received a complaint from the customer, because the engineer had been rude and didn’t provide updates about what was happening. The engineer’s reply to his manager was so shocking that I still remember the exact words he used. What he said was “I don’t do people, I only do computers”.


That is an extreme example, but I still see a similar culture throughout the IT industry. There are far too many people in IT who think that their role is to manage the technical components, they “don’t do people”. Even in IT organizations that claim that customer experience is the most important aspect of what they do, I often don’t see the investment of time and resources that would be needed to make this true.

We often represent IT service management as a balance of people, process, products, and partners, like this…

ITSM: A balance of people, process, products, and partners

… but whenever I see a project to implement or improve an aspect of IT, or IT service management, the people aspects usually have insufficient planning and far too little investment. One example of this was a recent post on the Back2ITSM Facebook group, where James Finister described a project Gantt chart that had “change organizational culture” neatly allocated a two week bar.

There are lots of people working in IT who understand the importance of attitudes, behaviour, and culture (ABC) and some IT organizations do invest the time and resources needed to get these aspects of IT service management right. But for every great IT organization I see, there are another 10 that spend all their time thinking about processes and products, and assuming that the people part will just happen. They “don’t do people”.

So what can you do to address these people issues? Unfortunately there are no simple answers, but there are plenty of things that can help. Here’s my advice:

  • Start by thinking about yourself, and how you relate to customers and colleagues. A very powerful learning for me was hearing my colleague saying “I don’t do customers”. This made me reflect on my behaviour and led to major improvements in how my customers saw me.
  • We all have a big effect on the behaviour of people around us. If you demonstrate the kind of behaviour you expect to see from others and share the positive results this generates, then you may start to influence your colleagues, and the culture of your organization.

If you are responsible for managing people or processes in an IT organization, then there are many more things you can do:

  • Think about how you recruit people. If the only factor you consider when taking on new staff is their technical competence then you are storing up problems for the future. One organization I know recruits many of their first level service desk staff from within the business they are supporting. This gives the service desk an enhanced understanding of the issues their customers face, and helps to ensure they display the required level of empathy.
  • Include experiential learning into how you train IT staff. There are some very effective business simulations available and a number of vendors can deliver these. This training really can help your staff understand how their behaviour impacts their customers.
  • Design customer experience into everything you do. Don’t just assume you know what customers want; ask them, engage them, and make sure your processes and tools work for them. Every process, every user interface, and every interaction should be designed to deliver a great experience for your customers. If customers aren’t involved in the design stage then it’s unlikely your staff will be able to get things right.
  • Make sure that the way you measure and reward people promotes the behaviours you want. One organization had a key metric of average time to close incidents. A particularly rude and unhelpful service desk agent could score very highly on this metric, leading to the exact opposite of good customer service.
  • Talk to staff about customer experience. Have regular sessions with all IT staff where you discuss customer experience, don’t just talk about financial and technical metrics. You need to help staff understand how they contribute to customer experience, in the same way as they should understand how they contribute to your financial performance.
  • Finally, you should ensure that people issues are allocated sufficient time, and money, in every IT project. Don’t assume that people will do what you expect, and behave the way you want. Make sure your people understand what you want from them.  Don’t allocate a two week slot marked “change organizational culture” to your project plan. Think about how people might react to your project, and how you can help them to adopt any changes you need. I recommend reading Balanced Diversity – a Portfolio Approach to Organizational Change by Karen Ferris for an overview of how to do this.

If you address these people issues then you can be one of the really great IT organizations that does “do people”, and the result of this will be happier customers and increased opportunities for you to deliver great service.

Image credit

Continue reading

Governance: Management? Leadership? Culture!!

Posted by on March 10, 2015 in ITIL
Show true leadership in your ITSM projects One of the most quoted words in use in tech management and marketing these days is ‘governance’. What do we actually mean by this and why is it such a big and ongoing topic?

Governance refers to "all processes of governing, whether undertaken by a government, market or network, whether over a family, tribe, formal or informal organization or territory and whether through laws, norms, power or language” (Wikipedia)

Governance is the exercise of political, economic and administrative authority necessary to manage a nation’s affairs (OED)

We get that fact that it’s about overseeing and running and managing. In fact, it’s basically running the show.
So is governance just another word for management? In some ways this could be true and often the term governance is used both separately and interchangeably from management, particularly when referring to processes and IT Service Management (ITSM) functions. For example: “the Problem Management process had no governance”, “there is a lack of governance around the implementation of the new ITSM tool”, or “our IT organisation suffers from a lack of governance”. Some words are frequently used in a nebulous way as a means of sounding intelligent or interesting but actually avoiding the issue, like “we need better governance here” when we mean “management isn’t doing its job” or “this process has no governance”’, meaning “no one is owning or managing the process”: Whatever the taxonomy, there are often issues around the management and policing of processes, tasks, and general areas of work delivery that need to be clarified and reinforced to all concerned. Let’s take a look at governance, management, and leadership…and ultimately how this defines culture.

Governance

This is the over-arching (executive) system that is in place in an organisation to manage and maintain quality, standards, compliance, security, and ultimately successful delivery of services. It requires a number of coordinated components – people, roles, responsibilities, guidelines, means of reporting, means of decision-making, transparency, and auditability. For all of these there is no excuse for ignorance – they are expected and must be understood and delivered by those with executive responsibility. In a limited company this is the legal responsibility of directors who may face serious consequences if they do not dispatch their duties in relation to the interests of the organisation and its shareholders. All directors and executives of all types of organisations are bound to follow and execute good governance of their organisation and its best interests. If not, they face not only the wrath of stakeholders (customers, employees, debtors), but also their justice system. The reason for mentioning this in some detail here is that IT is no longer a fringe activity that company directors can brush off and feign ignorance of. Now, IT is the business and they need to understand their responsibilities associated with it. The flip side is the need for IT to have more elevation in terms of positioning within organisations – direct access to board level discussion, not just a commodity team that reports to the Finance Director (who may or may not have any interest or understanding of it). For IT, ISO 38500 is a simple and really useful standard that all C-level/directors/executives should own and understand. It’s only a few pages and written in non-IT terms – it’s also a simple and really effective checklist for the things that they are responsible for in relation to IT. Every director/executive should own a copy. For ITSM, governance is often used in a number of ways – not only referring to the need to define processes, procedures, and accountabilities, but also for the controls, checks, and measures in place to ensure that these are being followed. So governance is about people, ensuring that other people are doing what they are supposed to, as well as taking clear action and steps to follow up if they are not. Often the first part gets done (not always well, but it happens), however  it’s the second part that fails, either due to lack of good governance in the organization or due to weak management. And so, sloppy culture is born…

Management

If it’s the job of the executive to set and control the way an organisation is run, then it’s the job of the management team to execute it. Simple? Well of course this depends on whether the organisation has a governance structure in the first place, and then the extent to which this is applied and communicated. Some clear key points are needed:
  • Clear guidance on the governance expected from management
  • Simple guidelines for how to select and promote managers
  • Clear policies and budgeted plans on management training
  • Clarity around management governance – i.e. who checks up on what they are doing?
In ITSM terms, if there is not a clear and strong culture around good governance across an organization, it will be difficult to make end-to-end processes work successfully. This is the crux and real critical success factor for most ITSM projects, i.e. the strength or weakness of corporate culture and the willingness or otherwise of middle management to challenge and contravene it. This is the reason, frankly, that most ITSM implementations are still centered around incident management, support and Service Desk operations – it’s been too difficult politically to go further. For example, it would be difficult to make some basic processes work across an organisation if managers know that it will not be supported by their peers or even by their (peers) management. Weak corporate governance will be the biggest challenge for the project. Some managers will have the skills and attributes to take this on but many will not, and those not interested can hide behind this culture. There is also the problem with ITSM/ITIL that when we say Incident/Problem/Change Management, we mean manager, and so everyone thinks that there is someone responsible somewhere for doing this, when of course this should be a global, shared responsibility.

Leadership

Leadership is another often used word these days, particularly in the context of personal skills. In other words, anyone and everyone can and should show leadership, regardless of their role or position. Leadership is not just about being a manager, it’s about taking personal responsibility and leading by example. Leadership can mean the Service Desk analyst who takes personal ownership of an incident and goes the extra mile with the customer to ensure that the issue is resolved, perhaps beyond the stated SLA. This could also be someone who digs in and stops a change happening at a CAB because they believe this will impact the customer experience or up-time, even if some of the IT management folks are insisting that this should go ahead. These and other examples can show great initiative, passion, and care for the customer and the service provided. They require some courage, and in some cases the need to challenge authority and process. By definition, they happen regularly in orgnaisations with good governance and management, but only sporadically, if at all, in those with poor management, governance, and culture.

Culture

So culture is actually the tone and rules set by the executive (consciously or not) and the degree that this is then implemented and maintained by the management. It’s no coincidence that in organizations with a clear, positive, and transparent governance and management, the culture needs less rules and micro-management to enforce it. Leadership should be encouraged from all people in an organisation but this depends heavily on the prevailing culture already in place. Clearly the process of changing culture is not a simple or speedy one, which depends on commitment and real leadership from those who can influence governance and management alike, as well as inspire others to show leadership qualities. In ITSM, for too long we have seen culture change as a project line or checkbox that needs to be added to our plan but often isn’t fully defined or understood, yet ultimately this will determine success. So with an impartial appreciation of the current maturity levels of governance, both management and culture in your organization will help you to set realistic and tangible plans for your ITSM project – that in itself shows true leadership! Image credit

Like this article? You may also like: The Service Desk and Relationship Management: All You Need Is Love

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Hospital IT Heroes

Posted by on March 3, 2015 in Service Desk

ITSM/service desk solution in hospital healthcare

Over the last few weeks I had the opportunity to speak with several customers in various industries about the exciting and quirky ways that they’re using SysAid’s ITSM solution in the field. I’m truly amazed at the myriad of ways in which they have implemented their service desks – from Australian emergency services to Italian fashion designers; from elite U.S. universities to Irish hospital networks.

I was fortunate enough to talk with Andrina O’Neill (pictured above), Senior Systems & UC Engineer/Service Desk Supervisor at St. Patrick’s Mental Health Services – Ireland’s largest independent provider of mental health services for adults and adolescents. Andrina is based at the organization’s main campus – St. Patrick’s University Hospital (associated with Trinity College). She is the pioneer IT professional who was brought into the hospital six years ago to assist in revamping the existing ineffective service desk in order to provide better quality IT services. Coming from a background of IT in the corporate sector, Andrina experienced a professional and mental shift upon entering this not-for-profit hospital environment.


I asked Andrina what it’s like to switch working environments, what challenges she faced in reconstructing the IT processes across multiple centers, how the hospital is making use of the service desk, and what she believes she’s achieved so far.

What was it like to move from the corporate sector into a charity-based healthcare organization?

When I started working at St. Patrick’s Mental Health Services, I was forced to change my whole mindset from being focused solely on making a profit to focusing on the wellbeing of hospital service users. At the core, St. Patrick’s is a charity which employs 600-800 staff including consultants, therapists, nurses, administration and support staff who are located across the country and actively rely on their service desk daily for the logging of IT-related incidents and requests, to ensure they’re providing professional care to mental health patients. For me, it’s an ongoing challenge to understand the clinical team’s thinking and needs, because unlike the end users in my previous corporate working environments, the clinical team’s focus is to provide the best care for the patient sitting in front of them.

Why did the hospital bring you onboard? What sort of IT services existed at the time?

St. Patrick’s has an excellent nationwide reputation for providing mental health services, but six years ago the management team acknowledged that its existing IT service desk (an outsourced 3rd party phone service) was failing to respond to the needs of hospital personnel. The service users, mostly clinical and administration staff, whilst competent with computers had a limited understanding of the IT jargon used by the external service provider. The service provider had zero understanding of the patients’ or clinical teams’ needs, which caused significant problems. The internal staff were never provided with a confirmation that their call had been processed, and the prioritization of requests was random, with no problem management in place. It was a disaster time-wise. There was frustration across all departments. The hospital decided to replace the service provider with an in-house IT department, of which I was one of the first recruits.

You paint a picture of a ‘Tower of Babel’ scenario that required a total rethinking of process and culture. How did you approach this momentous task?

My greatest challenge was to tackle the organization-wide frustration of staff whose IT issues had been frequently misunderstood or left unresolved. Their poor experience of the previously outsourced service left them with little confidence that things could change.  I needed to establish a completely new process across all departments involving new technology, training, and at a deeper level, restore the staff’s trust in service request management.

Firstly, it was crucial that the terminology on the end-user portal be easily recognizable to clinical and administrative staff in order to ensure a smooth transfer of data and requests. The problem I faced was that most service desks I evaluated were extremely rigid, and couldn’t be configured to serve our specific hospital needs, such as the use of medical terminology. This is why we adopted SysAid because it was so easy to configure to our needs, and we got it up and running within a couple of days. Of course, it was a change for the end users, but it allowed us to streamline incident management and make the process so much less time-consuming for the nurses and staff. Their requests were finally being logged and were instantly trackable through automatically-generated emails, which gave them a renewed sense of security.

What was the scope of the new service desk implementation? How difficult was it to introduce new technology to staff who aren’t so tech-savvy?

We implemented the new service desk across all hospital departments. Thankfully the task of re-educating the staff was a breeze because the platform was so user friendly that our end users could get onboard immediately. It was without a shadow of a doubt far more efficient for staff and it included reporting, which was essential for ensuring effective service for their patients.

What were some of the specific pain points and what processes have you implemented to respond to these?

The hospital relies on a complex share-drive system and privacy of patient data is of utmost importance. In the past, we were wasting a lot of time on new hospital employees – determining which drives, folders, and mailing lists should be made accessible to them. Although the heads of departments had defined file-sharing rules, in practice, new employees often required access to additional folders. These changes cost our team enormous time – up to 5 follow-up calls per new recruit. SysAid’s ITIL modules have enabled us to identify huge volumes of such incidents and resolve them much more quickly by recording and managing incidents and requests separately. It allows the hospital to focus on serving patients, instead of wasting time on administration. From an organizational perspective, the service desk is critical for saving time: we’re continually reducing the number of incoming tickets. Our team would be lost without this platform for problem management.

What about your remote ‘Dean Clinics’ for outpatients; how do you cope with managing IT processes for off-site centers?

Supporting off-site centers is a constant challenge for the IT Department. The main bugbear is the inherent sense of isolation felt by staff at these 5 remote sites. Our Dean Clinics are an integral part of the mental health services we provide, each staffed by specialist multidisciplinary teams who provide appointment-based outpatient services.  Due to the volume of appointments (there were over 12,000 visits last year), the clinical and administrative staff stationed there are under a lot of pressure to provide efficient and comprehensive services for the patients standing in front of them, so their technology and network connections must be reliable at all times. We were receiving many complaints from frustrated staff saying certain services weren’t functioning as they should be. With SysAid’s reporting capability, we were able to identify common issues across the clinics and implement comprehensive solutions, such as improving training for off-site staff and improving WAN connections between the main campus and the clinics.

Have your process improvements been appreciated by staff outside of the IT department?

The heads of departments definitely acknowledge tangible improvements to the service they receive. In fact the Chief Pharmacist for the organization, Amanda Fitzpatrick, was so inspired by how easy it was to use SysAid’s end-user portal that she recently approached me to find out if SysAid would be suitable for streamlining the clinical request processes within the pharmacy. For me, this was treading in uncharted waters as I’d only used SysAid for IT service management. We conducted a brainstorming session and it quickly became apparent to me that SysAid, when customized and tailored to the pharmacy's requirements, could be the solution Amanda was looking for. Amanda supervises a growing team of 16 pharmacy staff, who until recently were using Microsoft Access to record medication-related queries received from doctors and nurses. These ‘end users’ would either ask in person, call or email the pharmacy. This meant that the query needed to be manually entered, and only one permitted admin had access to the software.  Request logs were often delayed or not recorded at all. Also, it was a very laborious process to enter the data; it wasted hours of pharmacy time each week.

How did you go about adapting the service desk for non-IT processes?

There is a major drive for the pharmacy department to report activity levels and resources more effectively in order to improve efficiency, so Amanda’s manager gave her full backing to find more efficient software for their needs. We worked together with some help from SysAid’s Professional Services team to customize our platform: we configured the categories and labels with terminology that’s familiar to the pharmacists so they’re not scratching their heads thinking “What does that category mean?” We’re even using SysAid for a special project that enables clinical staff to log and monitor medication queries, which are automatically printed onto customized stickers for patient files. And for the purpose of working more efficiently, all of the pharmacy’s clinical incidents are now categorized, so it’s become much easier for Amanda to identify recurring incidents; she’s actually implementing problem management without even knowing it!

After hearing Andrina’s story, I decided to catch up with Amanda – the driving force behind this special project. Amanda started working at St. Patrick’s University Hospital pharmacy 15 years ago and is very committed to the cause of mental health and providing an effective service for patients. I asked her what value SysAid brought to her team and activities.

What sort of value does the service desk provide for the pharmacy?

Amanda: St. Patrick’s is a university hospital, so knowledge and continued learning are fundamentally part of the organization. It’s been my personal challenge to centralize requests and archive the learning from our clinical cases and queries relating to medication. SysAid allows us to retain good information on our activity levels. It provides a rich source of information allowing junior staff to learn from more senior staff and enabling pharmacists to learn and share evidence-based knowledge.

The service desk enables us to do multiple jobs at the same time. Firstly, my team can record their activity in real time and print their recommendations into each patient’s chart. Secondly, it has enabled us to centralize a log of our activities which allows me to oversee and supervise all clinical pharmacy activities. The automated reports have made all data accessible at the click of a button, and we’re now able to track where requests are coming from, types of requests, how long we’re taking to deal with them, and how effective our solutions are. My whole team finds it a far more effective system for tracking our activities.

All of these benefits can improve patient safety. For instance, where a query is received about medication use in pregnancy, the pharmacist will undertake a literature review and prepare a report. SysAid’s internal communications system combined with our new customized printouts allow us to provide the information to the relevant members of the team securely and confidentially. Cases such as these are saved in the knowledge base and provide a starting point for similar queries in the future. When such a query arises again, we can apply the service desk’s ‘duplicate service request’ function to capture and resolve these queries more efficiently. Staff can also learn from previous reports and save time.

Finally, I asked Andrina how she feels about her managerial IT decisions and achievements over the last 6 years.

We’ve come a long way in streamlining the hospital’s internal processes and our teams have grown considerably. Both the IT and pharmacy teams would be lost without the platform. From an IT perspective, SysAid is crucial for our organization. From a clinical perspective, it means improved patient safety. The value of implementing efficient processes for the hospital has been clear and even our facilities department have queried if they too can implement SysAid as they’ve heard how useful it’s been for the pharmacy department and how configurable the end-user portal was in terms of specific terminology and needs.

We’re always looking at better ways to manage our IT requests. Our latest development is that we’ve recently started to roll out ITIL via the service desk, and we can already see tangible benefits in terms of being able to resolve and track requests and incidents separately, which yet again saves us time.

Like this article? You may also like:
How Can You Create an SLA that Helps to Delight Your Customers?

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.

Continue reading

Defining Metrics for the Service Desk

Posted by on March 3, 2015 in ITIL
Defining Metrics for the Service Desk I have written a number of blogs about metrics and Key Performance Indicators (KPIs) recently, each focussing on a different area of IT service management. These blogs were very popular — this is clearly an area where lots of people are looking for help. Here are some links in case you’ve missed any of them. One response I got to the earlier blogs was “What about the service desk?” so here are my thoughts on how you could set about defining metrics for your service desk.

Principles to Think about When You Are Defining Metrics and KPIs

In previous blogs I explained how important it is to define your own metrics, not just copy the list of KPIs from an ITIL book, or this blog. Every organization is different and the examples in a book or a blog are just there to help you think about possibilities, not to be used unchanged. You also need to keep reviewing your KPIs, as the things you care about will change over time and KPIs that worked well for you in the past may no longer be relevant. Remember the “K” in KPI stands for key, so you should focus on key things that are important to you; you should not measure and report every number you can. You also need a clear understanding of your objectives, and the Critical Success Factors (CSFs) that are needed to achieve those objectives. Every KPI should support one or more of these objectives or CSFs. Reports and discussions with your customers should be structured around the objectives and CSFs, not the KPIs. The “I” in KPI stands for indicator. This is because a KPI is not proof that you have achieved your objective, it is just an indicator to help you and your customers understand trends and issues.

Objectives and CSFs for the Service Desk

So what is the service desk for? What are the things that you really care about? Here are some ideas of things that organizations might want to include as objectives or CSFs for a service desk.
  • We make it easy for users to contact IT to request help, ask questions, or provide feedback
  • We communicate well with our users, keeping them informed, and meeting their expectations
  • We resolve user incidents quickly and efficiently
  • We fulfill user service requests quickly and efficiently
  • We achieve high levels of customer satisfaction
These are just examples of some things that you might have as objectives and CSFs for your service desk. Please don’t just copy them - you should sit down with your customers and define your own - but this list might help you to get started. I’ve used the phrase “objectives or CSFs” to cover these high level requirements. We could have endless debates about the difference between these two terms but it isn’t really important. Just make sure you identify the things that you care about. Ideally you should end up with between 3 and 6 objectives or CSFs. If you have more than this then your reports will be too long and not sufficiently focussed.

Service Desk KPIs

Here are some examples of KPIs that could be used to measure the objectives and CSFs that we listed above.
  • We make it easy for users to contact IT to request help, ask questions, or provide feedback
    • All user interactions can be initiated via phone or web-based form (Yes/No)
    • Percentage of phone calls to service desk answered within 30 seconds
    • Percentage of phone calls to service desk abandoned before they are answered
    • Result for survey question “How easy is it to contact IT when you need to?” on annual customer satisfaction survey
  • We communicate well with our users, keeping them informed, and meeting their expectations
    • Percentage of incidents where user contacted the service desk to ask for an update
    • Percentage of incidents that were reopened by the user after being closed by the service desk
  • We resolve user incidents quickly and efficiently
    • Percentage of incidents resolved within agreed SLA targets
    • Percentage of incidents resolved using web-based self-help
    • Percentage of incidents resolved during the initial customer contact
  • We fulfill user service requests quickly and efficiently
    • Percentage of service requests fulfilled within agreed SLA targets
    • Percentage of service requests fulfilled using automation with no manual steps from IT staff
  • We achieve high levels of customer satisfaction
    • Percentage of users giving a score of 4 or 5 on post-incident satisfaction survey
    • Increased satisfaction with service desk on annual customer satisfaction survey
These example KPIs are based on the objectives and CSFs for the service desk. They shouldn’t be confused with more detailed KPIs that you might be using to measure your incident management process. You may also need some additional internal KPIs to measure how efficiently you use your service desk resources, but these are unlikely to be of interest to your customers.

Conclusion

You can’t define KPIs for your service desk unless you have agreed what you are trying to achieve. You need to sit down with your customers and agree what the service desk is for, and what they care about. This will enable you to define objectives and CSFs. You can then define a small number of KPIs that will help you to demonstrate how well you are performing. When you report to your customers, you should discuss the objectives and CSFs. You can use the KPIs to illustrate trends and to support your opinions, but be sure to discuss achievements against the higher-level requirements with customers, and most importantly — listen to how they perceive your performance.

Like this article? You may also like: Defining Metrics for Incident Management.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Information Technology: What Business Are You In?

Posted by on February 24, 2015 in Service Desk
Information technology, service desk, help desk - what's your business? Think Nike is in the athletic shoes and apparel business? Not on your life.

“Nike sells shoes but it’s not in the shoe-selling business. It’s in the business of selling emotion and aspiration. Nike sells achievement, Nike sells perseverance and Nike sells Victory.“ (Brandstories.net)

If you ask most IT people what business they're in, their answer will invariably focus on “technology”.  But are we actually in the technology business, or something more fundamental (like enabling business outcomes)?

Fatal Attraction

If you asked White Star Line in 1910 what business they were in, they would say the transatlantic shipping business. It was an industry engaged in a fierce competition for bigger and faster ships – deeply reflecting their focus on shipping (with a lesser focus on moving people). Every organization must answer The First Question of Innovation: What Business Are You Really In? Both in its design and its operation, White Star Line’s Titanic was intended to demonstrate dominance and superiority in the competition for bigger and faster ships — a focus that turned out to be both misguided and fatal. Had they foreseen the arrival of air travel and its wholesale takeover of transatlantic shipping, they may have made other choices and still be in business today.

That's Entertainment

Harvard Business School lecturer Theodore Levitt coined the phrase Marketing Myopia to describe the failure of organizations in defining their mission too narrowly. Had Hollywood stuck to its roots in celluloid film technology, it would have been kicked to the curb in the coming domination of television and digital entertainment. But Hollywood knows its business well: Entertainment (not film!)

Risky Business

IT Service Management is about enabling business outcomes. This is our business. We are very strong  in the use of technology, but our business is enhancing business performance and removing barriers. The measure of our performance is the degree to which we enable business to achieving their goals. Steve Jobs stands out as perhaps the best example of a geeky technologist turned visionary leader. He didn't see technology as an end in itself, but was gifted with the ability to see what technology could enable. Too often we spend more time debating the merits of one operating system versus another, than trying to understand what our customers need servers to do. Have you ever reported 100% server uptime when the customer was dead in the water? Imagine how your customers feel when you report network round trip times are “well within SLA range”, when they are experiencing significant “network delays”. It's not that technology components and their efficient operation aren't important. They are the very foundation upon which business services are based. But, just as Hollywood isn't in the film business, IT isn't in the technology business. IT is in the business of enabling business outcomes.

Dances with Wolves

In order to help the business achieve its goals, we have to know and understand them. Get in their space; walk a mile (or two) in their shoes. It never ceases to amaze me how little we seem to know about the workings of the businesses we serve. We need to get out there and engage our customers. If we leave Relationship Management exclusively to those with the title, we're excusing ourselves from our very reason for existing. Get invited to business staff meeting. Listen to their plans and challenges. Understand their struggles and concerns.

You Can't Handle the Truth

As you engage your customers, ask the tough questions. But, be ready to hear the truth, in all its splendor.
  • What is the biggest challenge you face?
  • What's changed in the last year in your business, and what changes do you see in the year ahead?
  • What IT services do you use the most and what do they do for you?
  • What IT services to you use the least, and why?
  • What would you like to see more of from IT (and less?)
  • Can you show me how you use your IT services?
  • If IT and technology weren't a barrier, what would you do differently?
  • What technologies are your competitors using?
IT Service Management aims to maximize business value from IT, enabling the achievement of business goals. In our business, we use technology, but our real business is enabling business outcomes. Focus more on what business outcomes can be enabled by technology and less on the technology itself.  Get to know your customers in their native habitat, and measure your success by the outcomes you enable. What business are you in?

Like this article? You may also like: The Service Desk and Relationship Management: All You Need Is Love.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

10 Best Practice Tips for IT Transformation

Posted by on February 18, 2015 in ITIL
IT transformation in ITSM We talk a lot about transformation in IT. That the changing IT landscape is causing us to evaluate and ultimately adopt new technologies. Or at the other end of the spectrum, that business transformation is driving the need for new, and more, IT services to support new business and new business models. 2014 was definitely a year filled with “digital business” talk, with the associated opportunity (for either glory or failure) available to corporate IT organizations. At a high level, most corporate IT organizations are up-to-speed with the need for both IT transformation per se, and that business transformation is also driving the need for IT transformation. But IT transformation is ultimately organizational change – changing the people and process as well as the technology. And when we start to talk about organizational change within the IT organization, it can start to seem scary, or scarier, given that the people part of the ITIL-espoused “people, process, product, and partners” (formerly people, process, and technology) can be a significant barrier to change. At best, it’s a banana skin waiting to be slipped on.

10 Tips for IT Transformation

So what can you do to better traverse the common barriers to IT transformation (and to avoid any potential banana skins)? My good friend Ken Gonzalez gave some sound advice, and a few laughs, on this topic in his recent session at the Pink Elephant Conference in Las Vegas. My 10 tips are strongly influenced by Ken’s content. So think about the following 10 points:
  1. IT transformational change rarely follows the plan.  So stop thinking that, and acting as though, it will – and be prepared to go off-plan as needed. Shift happens (do you see what I did there?)
  2. Look beyond the end (IT transformation) to focus on the means. Pay particular attention to leadership, communication, and accomplishment.
  3. Ensure that you understand the service provider (IT) and customer (the business) relationships. It’s difficult to change things when you don’t properly understand the service delivery environment and status quo.
  4. Understand management imperatives. It might sound obvious, but change and IT transformation don’t happen in a vacuum. Ensure that the proposed IT transformation sits well with the existing management imperatives or expect a bumpy, and potentially short, ride.
  5. Collaboration won’t happen by itself; it needs to be worked at.Whether it’s intra or inter-team collaboration, getting people in the same room to discuss a common goal is not necessarily collaboration. Look out for pointy fingers versus open palms. People can push and pull but it needs to be in the same direction.
  6. Be aware of cultural barriers, especially inappropriate behavior. To quote Ken: “Culture is more insidious than politics.” It’s often the unsaid rather than what’s said that will hurt your IT transformation program.
  7. Ensure that you truly understand what culture is. I like Ken’s definition: “The overriding view and the corresponding forces which permeate a group.” And remember that while many cultural issues can be predicted and planned for, there will of course be some that can’t be – and I refer you back to my first point.
  8. Check your IT organization’s strategic and operational mindset. Is IT merely responsible for building and managing the IT infrastructure and applications? Or is it responsible for enabling business results and proactively managing customer experiences? Both the former and the latter will dramatically affect not only the ability to transform but also the quality of the outcome. It will also most likely affect the long term viability of the IT organization.
  9. Understand that with transformation “correction is inevitable and improvement is mandatory.” And with this, it's fine to concentrate on your strengths (as a corporate service provider) but you also need to address your weaknesses.
  10. Remember that informing does not replace actual communication.It ties in with the earlier collaboration point, and the old adage that “a message sent is not necessarily a message received.”
It’s also worth remembering that not all change is IT transformation. And if you look at #ocw2015 on Twitter you’ll see many of Ken’s Pink15 slides and additional points captured within the timeline. Pink ITSM Conference, Las Vegas Finally, I’d love to hear your personal advice on IT transformation. What works and what doesn’t? What did Ken and I miss?

Like this article? You may also like: 15 ITSM Tips for 2015.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Pearls of ITSM Wisdom from SysAid’s Competitors

Posted by on February 12, 2015 in Service Desk
ITSM and service desk pearls of wisdom There’s no law that says different IT service management (ITSM) solution vendors can’t play well together. In fact some of my favorite people work for the competition, or used to. Last year I spoke with some lovely ITSM people, gainfully employed by SysAid’s competitors: I’m beginning to think that undertaking a blog interview with yours truly might be the ITSM vendor kiss of death.
In any case, all of these guys (note to self – I must interview some ladies in 2015) gave their personal answers to questions such as:
  • What do you think is the most important element missing from traditional ITSM? And why?
  • What do you think is the biggest mistake that people can make in ITSM, and how can it be avoided?
  • What one piece of practical advice would you give to somebody working on the Service Desk?
  • What one piece of practical advice would you give to the CIO of a company with regards to ITSM?
  • If you could change one thing about the ITSM industry as a whole, what would it be and why?
  • What do you think the ITSM trend to watch will be in the next 12 months? And why?
  • Where do you see the ITSM industry in 10 years’ time?
  • Finally, what would be your 5 tips for success in ITSM?
I also asked them who their ITSM hero was. But I couldn’t include that question as they all pointed to me. It isn’t easy being an intergalactic ITSM superstar [Editor: Joe, I think you might be being less than honest about this question].

Some ITSM Pearls of Wisdom

If you don’t have the time, or the appetite, to read everything Patrick, John, Ashok, Stephen and Arvind (the ITSM One Direction?) said, here are some of their ITSM pearls of wisdom. Patrick:
  • Traditional ITSM mentions the four “P’s” – People, Process, Partners, and Products, but I think the most essential “P” often gets missed, and that is “Perspective”…  There’s too much focus on the services we provide, and not enough on the outcomes they deliver to customers.
  • We are all customers and know what service should feel like. At work, when we’re the service provider, why do we forget so quickly?
  • Focusing on ‘cost reduction and efficient delivery of IT services’ will prevent existing value from being destroyed, but won’t create new value.
John:
  • The most important element missing from traditional ITSM is the same thing missing from many IT trends in general; the lack of focus on the customer (the right customer) and lack of focus on business fundamentals.
  • The biggest mistake in ITSM is in thinking that “implementing” a framework automatically results in “magic value.”
  • Reduce the focus on dogmatic certifications for people and technologies and focus energies on increasing and certifying business skills.
Ashok:
  • The main mistake that organizations make is not properly documenting their requirements.
  • My advice to the CIO of a company is to understand that automation in ITSM operations is important.
  • The ITSM Industry should invest more in the development of people and process maturity models.
Stephen:
  • “IT is not about the IT” but about what the IT brings, in terms of business outcomes, to the organizations that employ it.
  • The biggest mistake that people can make in ITSM? Thinking of ITIL (and in many ways ITSM) as just a small group of processes (incident, problem, and change management) rather than a new mind-set around delivering IT as a service.
  • Ask service desk agents to treat their customers as they themselves would like to be treated.
Arvind:
  • The first and foremost thing needed for successful ITSM is some ‘reality’. One thing to remember in ITSM is ‘knowing is not doing’. For instance, you can read a lot about swimming, but knowing how to swim is the reality.
  • ITSM is not about implementing the processes based on the guidelines. There is no bible for ITSM. It’s about implementing what works for you.
  • ITIL/ITSM certification should not be about completing the course, but to observe and learn from the experience of others, what works and what doesn’t in real life situations, what will fit into your IT environment and what will not, and then to go about implementing the processes.
  • Of course they say a lot more in the original blogs. Check them out if you have the time. In addition, I’ve also put all of their top tips into the office blender to create a Top 10 ITSM success tips list.
Image credit

Like this article? You may also like: 15 ITSM Tips for 2015.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

ITSM Basics: A Simple Introduction to Incident Management

Posted by on January 27, 2015 in ITIL
ITSM Basics: A Simple Introduction to Incident Management Don’t tell anyone but for some reason I can post to the SysAid blog now... and to start I want to provide a simple introduction to incident management. Humble is what I do best. Oh, and I’d better be on my best behavior. So I’ll quickly cover:
  • What incident management is
  • Major incidents and service requests
  • The objectives of incident management
  • The “incident lifecycle”
  • The benefits of incident management
If you read my blog, then you know I refer to ITIL quite a bit (you might think too much) but you can quite easily use your own self-created process and activities or look to alternative sources of advice such as ISO/IEC 20000, ISACA’s COBIT, USMBOK, or Microsoft’s MOF.

Where Incident Management Fits In

To set the scene, corporate IT organizations need to consistently provide:
  • Uninterrupted IT and business services
  • A level of service that meets customer needs at an acceptable cost
  • Speedy resumption of service when IT issues or failures occur, particularly when these issues adversely affect business operations
Incident management can help with all three, but will support the latter point for the most part. Incident management helps to keep business services available and employees productive. And most IT shops already do some form of incident management – though they might call it IT support, help desk, ticketing, service desk, or something else. Put simply, incident management is the process or set of activities used to identify, understand, and then fix IT-related (but business impacting) issues, whether it be:
  • A faulty laptop
  • Email delivery issues, or
  • A lack of access to the corporate network, a business application, or the internet, for example

Incident Management Definition

ITIL, the IT service management (ITSM) best-practice framework formally known as the IT Infrastructure Library, uses the term “incident management” to describe the handling of such IT issues from identification through to resolution. With the objective of incident management being: “To restore normal service operation as quickly as possible with minimum disruption to the business.” This is where the IT issue requiring attention (“Any event that disrupts, or could disrupt, an IT service and/or business operations”) is termed an incident. According to industry surveys, incident management is consistently reported as being undertaken by approximately 95% of organizations. And this process or set of activities is commonly supported by fit-for-purpose technology, i.e. a service desk, IT help desk, or ITSM solution.

Separating Out Major Incidents and Service Requests

ITIL separates out the severely business-impacting incidents as “major incidents.” These highly disruptive incidents – such as an online sales system or the corporate HQ’s internet service being down – are often treated as emergencies with significant IT resources applied to ensure a speedy resolution and the resumption of business operations as soon as possible. Some organizations will operate a separate major incident management process. If you would like to read more on this, Rob England, aka the IT Skeptic,has written a great blog on major incident management. At the other extreme are service requests, which are non-incident-related calls to, or contacts with, the IT service/help desk. And, as the name suggests, these are requests for new or changed IT services such as:
  • A request for new hardware or software
  • An access request: for an application or shared drive
  • Information on a particular IT service, e.g. what does application X do and should I have access?
  • “How to” information, e.g. how do I access my emails while out of the office?
It’s important to treat incidents and service requests separately due the relative urgency of an IT issue versus the need for a new IT service.

Incident Management Objectives

ITIL defines the objectives of the incident management process as:
  • “Ensuring that standardized methods and procedures are used for efficient and prompt response, analysis, documentation, ongoing management and reporting of incidents.
  • Increasing the visibility and communication of incidents to business and IT support staff.
  • Enhancing the business perception of IT through the use of a professional approach in quickly resolving and communicating incidents when they occur
  • Aligning incident management activities and priorities with those of the business.
  • Maintaining user satisfaction with the quality of IT services.”
It might sound complicated but it does really just boil down to the earlier ITIL incident management objective of “To restore normal service operation as quickly as possible with minimum disruption to the business.”

The “Incident Lifecycle”

ITIL recommends that incidents be managed through a lifecycle, or process, that includes a number of steps, activities, or sub-processes – from the initial identification or reporting of the incident through to its resolution and the closure of the incident record. This is the order:
  1. Incident detection and recording
  2. Initial classification and support
  3. Escalation to a major incident process where needed
  4. Invocation of the service request process if not an incident
  5. Investigation and diagnosis
  6. Resolution and recovery
  7. Incident closure
Continuous ownership, monitoring, tracking, and communication are involved throughout each step as per the sexy little diagram I have created below. ITIL's incident lifecycle: the flowchart

Incident Management Benefits

The benefits of incident management include, but are not restricted to:
  • Shortening the “incident lifecycle” and decreasing downtime, thus maximizing business productivity.
  • Resolving incidents before they can adversely impact business operations.
  • Making better use of potentially scarce IT resources. Having defined roles and responsibilities and a single, consistent process not only speeds things up but also reduces duplication of effort and wastage.
  • Facilitating better collaboration between different IT teams and preventing dropped issues or issues “ping-ponging” between teams.
  • The ability to leverage existing knowledge to speed up resolution.
  • Reducing the costs associated with both IT service delivery and IT support.
  • Reducing the adverse effect of business-impacting incidents. This might potentially include lost revenue, lost reputation, or even lost customers.
  • The ability to identify, and act on, opportunities to improve IT services and IT service delivery.
  • Improving customer service and the business’s perceptions of the IT organization as a whole.
Well there you have it – my first post in the SysAid blog. Did you find it helpful? If you want to read more from me on incident management, then please look at:

Like this article? Then you will certainly enjoy ITSM consultant Stuart Rance's white paper, offering the help you need - with 6 top tips - to improve your incident management. DOWNLOAD THE TIPS

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading
Subscribe
Watch & learn from industry experts about ITSM and help desk hot topics!