Define Measure Acheive. Repeat

Archive

Posts Tagged ‘ITSM’

Steve Jobs, Apple and ITSM

November 21st, 2011

There has been an avalanche of copy written about Steve Jobs and Apple, so I apologize in advance for adding to it. This post is about some reflections on Steve Jobs biography, and how certain parallels could be applied by IT Departments looking to improve how IT services can be delivered.

As an aside, I found the Walter Issacson biography of Jobs to be a gripping read, although the format and story telling did not reflect the simplicity and focus of its subject . While I was reading through the copy it struck me there are a number of significant parallels between how Apple approaches product innovation and how we talk about these things within the construct of IT Service Management (ITSM).  A specific example is the introduction of the iPod and the musing from various industry insiders who asked the question “how on earth did Sony not invent the iPod and iTunes?”

At the time, the music industry was looking to Sony to produce a digital rights management solution that would counter the concerns over piracy and stem the decline in music sales. After two years of wrangling, the industry was no closer to a solution. As we know, Apple came along and provided a service that was completely integrated from the consumers’ perspective with the advantage that it was simpler to buy a song on iTunes for the average person that scour the web, and take chances on dubious quality alternatives.

Many people ideologically do not welcome Apple’s approach because (at the time) music purchased from the iTunes store could only be played on Apple Computers and iPod’s, however, despite your particular ideology on open vs. closed systems, the question remains; “how did Apple manage to snatch victory from Sony where they really had no business being able to do so”.  They had no history making a music device; they did not have the relationships with the providers (the artists) and they generated their money from selling computer hardware.

A large part of the answer is found in how the two companies were structured. As noted in Donaldson’s biography ‘Sony’s divisions were at war with one another’ and were continually trying to out-compete; thereby information sharing was limited and worse they would actively sabotage each other to prevent incremental increases in their organizational sphere of influence. Apple, driven by Job’s obsession in owning the user experience, saw the value in integrating its divisions. Tim Cook, then COO of Apple states “the company doesn’t ‘have “divisions” with their own P&L” and Steve Job actively encourages integrating of divisions to provide a cohesive end-to-end experience.

The parallel with internal IT organizations is apparent. Interestingly it is not from a technological perspective but an organizational one. Many efforts attempted at transforming the experience of delivering IT are hampered by Managers of silos that prevent change from occurring. In addition, Senior Managers do not push through the structural changes necessary to transform IT service delivery to be service (rather than product) as the push back from the organization itself seems too much to spend political capital on.

I don’t blame Senior Management unconditionally as our industry itself has let down IT Departments as we continue to focus on technology based solutions to attempt to address organizational issues.

IT Service Delivery can only truly reach its potential in those organizations where CIOs and CTOs step in and remove the traditional barriers by implementing a horizontal IT structure rather than what is traditionally a vertical one.

Steve Jobs is often dismissed as a ‘salesman’ or ‘marketing guru’ by many of our colleagues in IT Operations, however, we as an industry would do well to think differently about how we deliver services and the internal barriers that need to be adjusted to allow us to reach our potential of providing the right services at the right time at the right cost.

It is time for us to encourage organizations to stop investing in another ‘silver bullet’ tool but rather encourage changes to the fundamental issue of silos and hierarchical structure that impact cross communication, planning and delivery of great IT Services.

  • Share/Bookmark

Charles Cyna Uncategorized , , , , , , , , , , , , ,

A New Year’s Resolution for the Service Desk

January 5th, 2011

I love the New Year.  January is about fresh starts; hopefully you have had a break over the holidays and feel revived for the challenges ahead. On the Service Desk this is a time for renewal too, and there is no better time to evaluate your current Service Improvement goals for the year.  The business case for Service Improvement is easy to make – identifying ways to reduce costs and improve service is something all levels of management get excited about!

One of the easiest things to do is to find out what your customers’ think of the service that you provide. Many Service Desks’ find all kinds of excuses not to do this, however, by following some simple guidelines you can do a survey and get a snapshot in time of how your customers feel about the support you provide.

#1 Establish a repeatable approach to assess satisfaction and action improvements as part of a continual improvement practice. Make a commitment to survey and re-survey at regular intervals and if you want to improve response rates then share the results with your customers.

#2 Collect information within a Satisfaction Framework to create “actionable” information and simplify analysis and trending. You can measure satisfaction in key dimensions of the service for ease of analysis and action. Use a Service Quality Model to measure important service quality dimensions like: “ON TRRAC” – Timely, Reliable, Responsive, Accessible and Cost effective (see Survey Framework Overview below for more details).

#3 Focus initially on Client (IT User)  and Practitioner(IT Provider) satisfaction with the Service Desk and Incident Management Practice. (Later, you may want to consider adding a survey of the Business-Level Client (Business Executive) to help understand their satisfaction with key elements of your overall IT Services and IT Executives to see how well aligned they are with their Business’s satisfaction/importance ratings.)

#4 Execute an annual survey to baseline the satisfaction and inform annual improvement action plans. Client Surveys target users collected by business area. Practitioner Surveys target both the Service Desk and Technician level collected by group.

#5 Schedule “Checkpoint” surveys to gauge progress and to provide needed information to flag in-year corrective actions.

Client Surveys at targeted intervals throughout the year:

  1. Auto-generated short survey at the closure of every incident;
  2. Call-back short survey to a set # of users every month (closed tickets); and
  3. Optional – Warm call transfer short survey to users upon completion of their call to your Service Desk.

#6 Ensure that all survey results are routinely analyzed and incorporated into the Service Improvement Plan (SIP), results are presented to primary performance stakeholders AND that feedback is published back to survey recipients, provide them with the ‘What We Heard’ along with planned actions, ‘What We Are Doing About It’.

We make many of our tools available for use at no charge.

Start surveying your Clients (IT Users), Practitioners (IT Providers), IT and Business Executives today with ITSM Coach: Satisfaction Surveys (included as part of ITSM Coach).

To learn more click here…

  • Share/Bookmark

Charles Cyna Uncategorized , , , , , , , , , , , , , ,

Continual Service Improvement (CSI)

December 8th, 2010

Most IT organizations, if asked would say that they ‘continuously improve’; however there is a gap between saying it and being able to demonstrate that it exists.

For CSI to work in the long term, a culture of improvement needs to be instilled within IT. 

If the culture of improvement does not exist, the first step is to identify improvement behaviours and perform them consistently and repeatedly (let’s call the identification of these behaviours; performance tweaks).

Overtime these behaviours will begin to take root and become part of ITs fabric, impacting every project that is taken on board.

What is CSI?

Simple Behavioural Steps

For an organization who wants to get started with Service Improvement, there are some simple behavioural steps that can be followed to get started:

#1 Baseline your current performance (pick an area you suspect there could be an opportunity to improve upon and measure what you are doing today),

#2 Analyze your performance data and build a list of wins based on cost/technical complexity and benefit (this is key, as the organization will resist change unless you have the numbers to back up the benefit),

#3 Identify a group of people within the organization that need to be involved to address the issue you identified,

#4 Set a realistic meaningful goal and timeframe,

#5 Implement the agreed performance tweak, into your environment

#6 Track and measure how performance is changing with the performance tweak in place,

#7 Report on your success and set a new goal to sustain your improvement,

#8 Repeat this process for something new!

The key is to focus your initial performance tweaks on something that won’t cost a lot of money to change, but can provide a big impact.

If you follow this process just once a month, you will be taking the necessary steps of instilling the culture of improvement within your IT department.

About Us (ThinkITSM Corp.)

ThinkITSM Corp. manufactures tools that help organizations implement practical CSI initiatives within their organization. Our service (which we call ITSM Coach) takes a snapshot of your current service desk performance and baselines some key measures.

We help you learn how to analyze the information you gather in your service management tools to inform service improvement goal setting and help you establish internal changes necessary to meet your desired goals.

We make many of our tools available for use at no charge and you can get started today with a free baseline assessment of your Incident, Problem and Change processes.

To learn more click here…

  • Share/Bookmark

Charles Cyna Uncategorized , , , , , , , , , , ,

Are Service Management Tools Replaced for the Right Reasons?

December 1st, 2010

When we get engaged to be married, why do we focus so much energy on the wedding, which after all is one day, rather than the countless days we will be spending with our new significant other post ceremony? Why, when pregnant do we focus on the birth and not on the life that we will share for the rest of our time on this planet? And why when IT departments implement new tools or processes do they focus on the implementation and not much beyond?

The answer, at least in my humble opinion, is that we are slave to the human condition that focuses on something we can control. For example, it is easy to become transfixed on making the wedding day or labour the best possible experience because there is a sense of management. On the other hand, putting a plan in place to manage the rest of our lives – well, good luck with that!

With that being said, after working with organizations for over sixteen years on technology evaluations and deployments I can safely say that way too much time is spent picking a vendor rather than ensuring the project will be a success. If you work in IT, you probably know the routine, but to make my point, you may have been involved in painstaking web research looking for a Service Desk tool vendor, you narrow the list to about 50 (after all it would be positively rude to exclude). Then you build the RFI, where you construct a document inviting said vendors to answer a series of questions (most of which are often generic enough that almost all tools are designed to accomplish).

Then there is the RFP, the shortlist, the demos, the refined shortlist, another round of demos. Finally a decision is made and just when a final decision is to be announced… funding is pulled so the whole process can begin again next year. I have watched this process countless times, sometimes happening repeatedly at the same organizations for several years. Finally, a new tool is picked and work begins to implement. Everything is great, for a while that is.

Soon enough, the enthusiasm and hope for the initiative wanes as focus is on the next project and after a few years of no provable ROI or measures of what has changed, a decision is made that ‘we need a new tool’ and the whole un-virtuous cycle begins again.

Of course, it doesn’t have to be this way. But we as IT stakeholders need to make a stand and build a ‘life plan’ for our new products.

My guide for avoiding the rip n’replace cycle is as follows:

#1 A tool implementation is the beginning of a journey not the end of one.

Understand that 6-12 months after you acquire a new tool is just the beginning and recognize that budget and time will need to be allocated to ensure that this is going to run for a while.

# 2 Reporting should always be part of Phase 1.

The number one reason cited by organizations for a new tool is normally ‘better reporting’. Then the reporting phase is often relegated to Phase 2, to give everyone a chance to `gather the data’. The problem with this approach is that if you have not defined your measurement upfront, how do you know that you are gathering the right data?

#3 Never say you want ‘better reporting’.

Better reporting does not get anyone (holding the budget) excited. Decide on what you want to measure and then measure it.

For example, if you had a personal goal of getting healthy because the doctor told you that your blood pressure was too high. You might decide that the capability you will need to achieve the goal is improved fitness and weight loss. The activity you perform is reducing your caloric intake and increasing the amount of exercise.  The key measures that would track your progress toward your goals would be things like weight, waist size, blood pressure and resting pulse as they have all been proven impacts to reduce blood pressure. Now if your goal was to fit into a pair of jeans you wore 20 years ago, the capabilities (diet and exercise) might be the same, however, the measures would be different.

For the IT Service Desk, the goal might be an `Excellent` rating in customer service. The capabilities would include being able to track information consistently, and being able to solicit feedback after work is performed. The measure might be MTRS, First Call Resolution Rate and Customer Satisfaction Surveys. A different goal would require different capabilities and measures. 

#4 Achieving a goal is great but you damage the impacts by not showing where you started.

The winner of last season’s reality show, `The Biggest Loser` weighed in at 265lbs, a weight in itself meant the winner was still clinically obese. Yet, there was incredible accomplishment and a sense of victory because the producers of the show meticulously take a baseline at the beginning showing a starting weight of 526lbs.

Buying new tools provide tremendous opportunities to demonstrate value of your Service Desk, the value of IT to be able to execute and tell a story to the people who control the budget. Yet many organization don`t effectively take a snapshot of where they currently are, so those end results, however fantastic, don`t due justice to the journey that you went on to achieve them.

#5 Reaching your goal is part of the journey. 

Extending my fitness analogy from above, once you have reached your goal of lower blood pressure, the whole exercise (pun intended) becomes pointless if after it is achieved, it is no longer a focus and is not watched.

Similarly, organizations often do a great job with `sprints` but then do not sustain. Reaching a goal on the Service Desk is not a destination but merely part of the journey. Once the goal has been met, we need to understand what is necessary to maintain that goal over time.

#6 It`s not the tool, it`s you.

Sometimes we just have to look in the mirror and take ownership for the situation.

In 90% of the tool replacement projects I have been involved in over the years, the IT department blames a tool for something that is not within the tools domain to fix. There are absolutely valid reasons to rip n`replace a Service Desk tool, just make sure it is about cost of ownership and not `better reporting` or `ease of use`.

  • Share/Bookmark

Charles Cyna Uncategorized , , , , , , , , ,

Signs that a Service Management Initiative has Stalled

November 8th, 2010

Continual Service Improvement is the fuel that provides long term momentum for any Service Management initiative. The fuel of momentum is vital; great IT Service Delivery is a journey that can take months and sometimes years to reach the productivity and cost savings that were sold at the beginning of a project. 

Many Service Management initiatives stall soon after the beginning because, as we try to achieve efficiencies we generate organizational resistance (the human condition is that most of us resist change) and if we don’t have the ammunition to overcome the resistance then the project stalls, inertia overtakes and the Service Management initiative never has the opportunity to reach its potential.

Signs that a Service Management Initiative has Stalled:

You implemented a Service Management tool a few years ago and you have not performed any significant customizations to the tool since it was implemented;

You implemented a couple of practice areas (Incident, Problem, Change) but have not been able to move much beyond those areas due to time and cost restraints;

You did a Process Maturity Assessment over a year ago and have not completed a re-assessment to measure the differences over time;

You generate reports for management but there are no defined ‘next steps’  to improve service after looking at the information;

You survey your customers but do little with the results of the survey;

You are not sure what the business outcomes are for a successful ITIL or ITSM Practice;

And if you do know the business outcomes, you are not sure whether you are meeting them.

  • Share/Bookmark

Charles Cyna Uncategorized , , , , , , , , ,

Do you measure your incident backlog?

May 5th, 2010

Incident backlog provides an informative KPI that you should consider adding to your reporting repertoire. The KPI should measure the number of incidents outstanding that have missed an SLO or SLA. The KPI should be trended over time and should either be stable or decreasing.

In the example chart below, we can see the backlog rising over the last three months.

Incident Backlog

In this example we see the backlog increase by 50% over 3 months and should be investigated. To determine how urgent the issue is the first thing to explore is to breakdown the  backlog by incident priority.

Open Incidents

It would be highly unlikely that a backlog with high priority issues would persist over a period of time and the chart above now shows that a majority of the back log are priority 3 and 4. This is fairly common and is often systemically ignored. However, it is worthwhile to examine further. 

The reasons for the rising trend could include:

- Second line support personnel are not closing tickets in your ITSM tool.

- Resourcing level may not reflect the current volume of tickets being received on the Service Desk.

- The organizations Change and/or Release practice is causing unscheduled spikes in incident volume

- Are their particular workgroups with particularly high backlogs that could indicate a bottleneck?

  • Share/Bookmark

Charles Cyna Uncategorized , , , , , , , , , , , , , ,

Reporting is the soufflé of the IT Service Desk.

April 21st, 2010

For those of you that are culinarily inclined you will know that a soufflé is made with a couple of basic ingredients; a cream sauce and egg whites, and yet the final dish remains elusive to the many that simply don’t pay attention to the details for prerequisite success. Oh, and such success is wonderful to observe - fluffiness contained within a towering cloud of caloric goodness - it is truly an elusive culinary accomplishment.

Figure 1 – The rare object d’art itself – a light fluffy soufflé produced at L’Atelier by Joel Rubuchon.

Figure 1 - The rare object d’art itself - a light fluffy soufflé produced at L’Atelier by Joel Rubuchon.

Like the fracturable soufflé, good service desk reports are easy to order but more difficult to enjoy. 

Although the ingredients are simple, the execution is questionable and the ultimate result is often unsatisfying. The particular reports I am thinking of are not operational in nature (the wham bam thank you ma’am of reports). The ones, I am thinking of are tactical in nature. These require a little more finesse, they are the thinking persons’ report, a tactical view of service desk performance that can enable service improvement and actually inform decision making. In other words, reports that provide information that is ‘actionable’. How delicious!

Anyhow, so many of these failed attempts leave me wanting more. Inadequate execution reduces them to merely visually appealing, useless and perhaps even inconsequential. 

So perhaps we should examine the ingredients and execution that can turn a miserable meaningless humble report into something worth consuming.

Ingredient 1: Consistency

Consistency is one of the few things that matter when generating decision support material. Everyone should be saying the same thing when answering the telephone, asking the same questions, and documenting the information received in the same way.

Ingredient 2: Track the right stuff!

Set yourself up for success and build a support model. Outside of the obvious items like impact, customer information etc. there are three things that the service desk needs to capture:

#1 –what was the customers’ perception of the failure (i.e. the end to end service),
#2 - what was the underlying IT reason for the failure (i.e. the provider service) and,
#3 - finally what infrastructure item was involved in the failure (i.e. the component category).

See the figure below to see a breakdown of the critical criteria that should be captured in the incident.

figure-2-the-essential-elements-fo-information-capture-for-incident

Figure 2 - The essential elements of information capture for an Incident.

These items enable simple and easy information gathering from the customer plus makes escalation of the issue through the IT organization easier to manage.

Ingredient 3: Focus on the WHAT, the WHY and the ACTION.

Generating reporting for reporting sake doesn’t work. It sounds obvious but many of us get in the habit of reviewing the same reports every month and then do nothing with the information.

If this sounds like you, STOP! 

Ask yourself three things when looking at a report:

Do I care about what this report is telling me?

If your answer is NO, move on and deal with something more important.

If your answer is YES, then you need to figure out WHY the information in the report is occurring.

Once the WHY has been determined, implement a performance tweak or involve the relevant stakeholder group and share the information with them as part of the ACTION.

In my next blog (on Monday), I  will explore a real life example of how this process works.

  • Share/Bookmark

Charles Cyna Uncategorized , , , , , , , , , ,

IT Service Delivery is a Journey not a Destination

December 8th, 2009

Organizations increasingly recognize that proven frameworks are key to improvement in IT Service Delivery and aligning IT operations to the needs of the business. Often the recognition that ‘things need to get better’ manifests itself through the purchasing of a new ITSM tool and/or the hiring of a consultant to implement some basic operational processes such as Incident, Problem and Change Management.  Meetings are held; documents are drafted, re-drafted and re-drafted again until everyone is happy with the outcome. The new tool gets implemented, the consultant leaves and those process documents that everyone spent weeks or months building get filed away in some electronic repository often never to be seen again.

If this scenario rings true, you’re not alone. Many IT departments treat Service Management or ITIL process implementation as a project and not a journey. Like losing weight, if you do not have a plan for ongoing success then the weight will come back and all the gains you made with hard work are simply lost.

Conveniently, the answer to help us through this scenario is given new prominence in ITIL’s latest incarnation of version 3. CSI or Continual Service Improvement, which was merely implied in previous ITIL frameworks, is now thrust into prominence and has its own book and its fair share of the limelight. CSI provides the process that drives the value out of your other ITIL practices. The Incident Management process in itself does not generate value – certainly, it would tell you something like how incidents can be escalated to reduce impact to the business. This in itself provides cost savings and improved productivity but it does not speak to the elements that drive a business; it does not tell us how many incidents we escalated last month, what the areas of improvement are and how we will do better next month. The incident management process assumes that everything remains constant – of course, the business changes.

CSI provides the wrapper to the ITIL processes you have in place. It enables you to baseline where you are today, where you need to be and to drive a path through to the goal. Getting a baseline for your existing performance is key, because it is difficult to get to your next destination if you don’t know where you are today. The good news is that there is a range of knowledge and resources that can be tapped inexpensively to help you through this process. For example, The ITSM Coach from ThinkITSM gives you the ability to assess your end user satisfaction and help desk maturity for free, highlighting the area’s most in need of addressing. Often we know much of this information informally but to have objective data enables the change process and gets disparate groups on board to adopt positive changes in how work is done.

CSI and Quality improvement has revolutionized manufacturing and have given automobile companies such as Toyota and Honda a fundamental competitive advantage that they translated into market share gains and profitability. It is now time for IT to embrace quality improvement processes and truly drive business value from IT Service Delivery.

  • Share/Bookmark

Charles Cyna Uncategorized , , , , , , , , ,

ITIL maturity - where do you want to be and why.

October 6th, 2009

As a rule, a practice is not considered mature unless it is at a level 3 or higher. This means that the single practice is mature enough to be working as designed and is being used by all relevant stakeholders. It also means that the data it is generating is mature and can be trusted for decision-making.

At Level 3 the practice has control points that provide management indication when and if intervention is required. The practice is end-to- end and collaboration across departments has been optimized. For many organizations reaching Level 3 seems to be the end of the journey.

However, the value proposition of an integrated ITSM practice approach is that when practices reach Level 4 they begin to interact with each other. This provides the ability to share common data and provide insight that is not available at Level 3.

By working cooperatively the practices become more efficient and effective and whole becomes greater than the sum of the parts. Level 4 is the desired target state for the practices in scope for most organizations.

A maturity of Level 5 is often seen in single departments but rarely across all departments. The effort required to get to this level of maturity is high and costly.

Many organizations do not have the ability or desire to reach Level 5. That is ok and not all organizations will have business need for this level of maturity.

  • Share/Bookmark

Maria Ritchie Uncategorized , , , , ,

If at first you don’t succeed…improving incident assignment accuracy.

September 17th, 2009

One of the biggest incident management challenges for IT organizations today is ensuring that when an incident needs to be assigned to another support team, that this functional escalation is performed accurately. Assignments may be necessary if the help desk is unable to resolve at first point of contact, or if a Tier 2 technician detects a fault or degradation that they are unable to resolve. It is important to be able to measure assignment accuracy as it is one area where process improvements can really pay off, both in terms of improved resolution times and overall customer satisfaction.

One key element of a successful incident support model is the emphasis on the role of the help desk in functional and hierarchical escalations. There is often a tendency for Tier 2 support teams to want to assign incidents to their functional peer groups directly. This is not to be confused with assignment of an incident to individuals within their team, which is anticipated in some situations.

An example of inaccurate assignment would be when a server hosting team determines that the incident was assigned incorrectly to their group, but on inspection of the incident realize that the network team will likely be able to restore service, and they assign the incident directly to networking. This can often lead to ping pong assignments, where Tier 2 groups pass the hot potato until the incident finally reaches the right support team. And, if your customers receive notification on assignments, a useful and common mechanism to keep them in the loop on resolution progress, they will likely become frustrated and form a negative opinion about the effectiveness of the IT organization.

Why does this happen?

The core reason is that Tier 2 support teams are often composed of specialized, focused resources who have knowledge relative to their functional area. They are typically not equipped with knowledge that would ensure assignment accuracy, and as a result cannot be held accountable for inaccurate assignments. However, there is a perception that sending an incident back to Tier 1 is a step backwards. What Tier 2 may not realize is that if incidents are not returned to the desk, the following direct and indirect impacts can occur:

1) The desk may not be aware it is assigning inaccurately, and long term effects can lead to a more challenging task of changing this learned behaviour when this issue is tackled.

2) The incident may not be correctly re-categorized or classified on reassignment. This can affect reporting and may make it appear that one Tier 2 group is resolving incidents outside of their area of expertise. This makes incident trending for problem management identification challenging to say the least!

3) Escalations due to delayed resolutions may not be initiated unless the incidents are being tracked in real-time. While some enabling technologies perform this activity, they often depend on accurate incident categorization which may not be the case for mis-assigned incidents.

4) Service level treatments may be incorrectly applied, as the initial assignment from Tier 1 may result in the incident being monitored against the wrong service level than what a re-categorized incident should be.

It is not uncommon for the cluster in an IT organization to resist the model of reassignment back to Tier 1. That is expected, but this challenge can be overcome. Aside from training and communicating the value of a Tier 1 reassignment strategy, you may want to employ a top 10 mis-assignment strategy. Record the number of assignments and compare these two an average assignment count that you feel is representative of an accurately assigned incident. If your enabling technology assigns an incident to the help desk on initial save, or if your organization sends incidents back to Tier 1 so agents can confirm service restoration with the customer, you will need to factor this into your calculation. You should also factor into your analysis the situation where Tier 2 resources detect an outage prior to customers feeling a service impact. Then, report on the frequency of Tier 2 to Tier 2 assignments, sorted as a top 10 list by support group, where incidents were reassigned more times than your acceptable threshold. Report on this internally to all the support groups on a monthly basis until your top 10 list represents less than 5% of the total incidents assigned. This will provide both visibility and a motivation for support group queue managers to monitor and address inaccurate assignment activities. If the problem persists, you may choose to report on the specific resources, by name, in this ranking. This may encourage those who are resistant to change to avoid having their name in lights.

After introducing this first step, you should begin to see an increase in assignments back to the desk. This can be troubling at first but this is expected. Ensure that you have established a quality review procedure to address these re-assignments. This can be accomplished through additional training or the updating/introduction of a knowledge base, intended to ensure resources are leveraging assignment diagnostics. This may also result in the help desk requesting more detailed diagnostic information from Tier 2 groups or service owners as means to enhance assignment accuracy. Include a help desk assignment accuracy statistic after you have implemented the statistics at Tier 2. This will encourage the desk to reach out after Tier 2 to Tier 2 assignments begin to drop. The rationale for this staged approach is that both measures are interdependent. Improving assignment accuracy require a feedback mechanism to the desk (re-assign to Tier 1), and Tier 1 accuracy improvements require enhanced information from Tier 2 (diagnostic logic).

If this top 10 approach is communicated and sold with a focus on improvement of IT for your customer, this should not be viewed as a negative. Instead, this may foster some competitive spirit between your IT groups. Other metrics can be added over time. You would be surprised how effective sharing statistics can be on changing behaviour.

Assignment accuracy is just one outcome of a successful incident support model. I will provide some additional benefits to support modeling in future posts…

  • Share/Bookmark

Michael Oas Uncategorized , , , , , , ,