Components of a Good Process

As promised, here is a list of components that make for a great process. While some might think that one component may not be needed or might be redundant, what's important to remember is capturing specific information to the following questions:

1. Is there a reason the document exists?
   
2. Is it clear who owns and maintains the document?
   
3. Are there audit measures in place to ensure the information is managed on a timely basis (Revision Control/Maintenance Schedule)? (Purpose and Intent), (Ownership and Approval for Changes),
   
4. Does it cover all the steps to complete the task? (Process Content).
   
5. Are acronyms and jargon clearly defined?
6. How are revisions and requests for changes handled?

To satisfy these questions, below are some components and their descriptions to make sure you have everything covered.

• Document Control: It's important to have clear and specific information about your document. Your document control should be a table that lists the unique name of the document, the URL/UNC to where the document is stored, date of publication, owner,expiration/review date, and stakeholder approval for the document.
• Purpose: This section should define a clear reason or purpose that the document exists.
  
• Scope: This component should contain a table that details what is In Scope and what is Out of Scope. This helps keep the document focused on the specific task and minimize creep.
  
• Definitions: It's easy in our everyday work lives to throw around and use acronyms as if everyone knows what they mean. Having a Definition section eliminates ambiguity and enables you to freely use the acronym going forward in the document.
  
• Process: This section would contain the steps and sub-steps to complete the task. As we've discussed in previous sections, the process should be logical, complete, and un-interprative - meaning the reader of the process is not left guessing. Read some of my previous posts to learn more about this component.
• Document Change Management: This table should contain the following fields: The Revision Number (Eg. 1.2, 1.3, etc), Date of the change, Section Changed, Author of the change, and a summary of the change.

There are other sections I've come across and used and it depends on your specific needs. As long as the points within each section are covered then you might find that you don't need certain components. Here are a couple more:

• Inputs: This section would contain information and links from processes that are needed in order to begin/initiate the current process. This is good for ensuring you have a tight logical relationship between all your dependancies.
• Output: Like the Inputs section, knowing where your Output goes help keep the logic between your different process documents. The Output section can be placed next to, or as a part of the Inputs section.
• Addendums: This component might contain any relevant information that doesn't seem to fit in any of the other sections, but is helpful and needed for the reader to know.
• Resources: External links to helpful or related documents would be put in this section.
  

Well, that's all I can think of for good components to a help desk process. I might also add that this approach can be taken to all facets of process and document control. If you found this helpful or would like to see examples of how these components look, leave a comment and we can get in touch.

Working with Process Diagrams

If you'll recall in an earlier post, process diagrams are very useful in getting the "10,000" foot view of your operation. Within each process box you can break down what transpires in the form of an itemized set of steps that completes the process box and feeds into the next one. What's important to remember is that all requirements for completion are listed in your process. If not, that's a whole or a gap and leaves the process open for interpretation. Continuing with our help desk process theme, I will demonstrate what might transpire.

Let's look at the first process event - "Analyst Uses Scripted Greeting". The requirements that satisfy this might go something like this:

1. "Welcome the Acme help desk. May I have your employee ID?"
2. Analyst obtains employee ID and enters it into tracking tool.
3. "Is this Joe Blow? And you can be reached at 719-555-1212?"
4. "How may I assist?"
5. Analyst follows "Troubleshooting Process".
   

So basically what we've done here is satisfy two process boxes in our process diagram. The scripted greeting as well as the decision box validating/acknowledging the user's entitlement to service. Bear in mind, the steps listed above do not a complete process make. What I'm talking about here is just the steps required to satisfy those parts of the process diagram.

This part of the process analysis will again lead to more questions relating to detail, providing enough direction, and how far do you drill with specificity. Those are questions you'll have to answer through the exercise of breaking down the detail and determining how far you need to go. It might be a task that no one person alone can answer, so seek help from subordinates and peers alike.

The Importance of Help Desk Process and Evaluation, Part II

In my last post, I explained how to do self-evaluation on your help desk process. In this post, we'll look at how to analyze the results.

Hopefully by now you are beginning to see holes and gaps and you might not be sure what to do with your findings. Also, hopefully you're not feeling overwhelmed by what might seem to be insurmountable gaps. If you don't know where to start, let's go back to those "pain points" I mentioned in the previous post.

Please note that in order to perform accurate root cause analysis, you will need a way to extract mined reporting data from your incident management ticketing system. You will need information about your product/service - most taxonomy is cataloged down to three levels. Also, you'll need to be able to filter your data by days and weeks in order to measure your error rate and monitor improvement. You will also want to do analysis on data such as technician name, resolver group, satisfaction surveys (if available), number of ticket "touches" or "bounces", and anything else that might shed light on trends. Let's look at some possible scenarios.

NOTE: This analysis assumes that you know how to navigate Excel pivot tables, as you'll want to export your taxonomy in order to filter and sort your data.

• Misroutes - Tickets are being misrouted to incorrect resolver groups on a consistent basis.
  
• Poor Documentation - Tickets are being escalated/dispatched without enough information in the ticket.
• Incorrect Taxonomy Selection - Technicians select the incorrect product/service causing the ticket to be incorrectly dispositioned.
• Unclear Support Path - This occurs often with new product roll-outs, products/services that are infrequently called about, or new technicians that may not have been trained adequately.
• Poor Troubleshooting - Informaton documented about the problem and associating symptoms to the problem are so far off, causing "dead-end" troubleshooting or incorrect support.

So, those are some common symptoms. Now, ask yourself some questions. Look for commonalities or trends surrounding:

1. What product/service types are being misrouted?
   
2. Do you see any trends with regards to specific dates the problems began to occur?
   
3. Filter by product/service and see what's being misrouted. Was there a new product roll-out? Change to an existing service?
   
4. New agent training that recently occurred?
   
5. What group is receiving the incorrect tickets? If there are several, capture them individually as you may have different reasons why it's happening to each group.
6. Was there a recent change to a support process and was it effectively documented and communicated?
7. Is the knowledge management system (KMS) up to date?
8. Is the KMS easily indexed and searchable? (Note: To help stay on topic, I'm saving KMS's for another time, as it is definetly a subject worthy of it's own topic)
9. Is there a "shadow process"? This occurs when diligent knowledge management falls to the wayside and "tribal" knowledge takes it's place. Basically, your support process might be dependant on whoever is giving direction on how to do it. Who knows the correct way to do it?
10. Is the product/service in question something that is not utilized frequently? Perhaps due diligence to capture the support information was not performed.
    

As you can see from this evaluation, most issues about poor support and quality surround:

• Training
• Knowledge Management
• Communication
• Change Management

While it may seem that we've drifted from our topic, I can tell you that all of these components fold in to what I would define as solid service desk process. You might also notice that complete service desk process is not exclusive to the actions of the technician. Meaning, solid process begins way before the technician gets to the phone. The point of this excercise is to look at all the extraneous variables that led you and your help desk to where you are.

For some, you may conclude at this point that you have more work to do than direction from just a single blog can provide. For the sake of others, we will assume that your processes are not as internally flawed as in the examples. I'll stop for now and in the next post we'll look at a more realistic view of where your desk might be and I promise we'll get to building the elements of a solid process.

Additional Reading...
How to do Root Cause Analysis?
How to create an Excel pivot table?

The Importance of Help Desk Process and Evaluation

Recently I had an experience with a transitioned help desk that really showed me how a lack of thorough processes and a solid knowledge management system can really sink your help desk right out of the gate.

This made me reflect on how detailed processes play such a big part to the success of a service desk. In this post, I will detail how I approach process analysis and/or creation. For this topic, I will not go in to detail about knowledge management, as we will cover this later.

To determine the strength of your processes - whether transitioning, creating, or analyzing an existing desk you must look at the pain points you are suffering. Pain points come by way of:

• Nasty emails from your tower/business peers such as a manager in another department wondering why their subordinates are sitting idle "waiting on IT to fix things".
  
• They may come from your customers in the form of negative surveys or continuous call backs wanting ticket updates.
  
• Perhaps your technicians continuously complain that they don't know where to send a ticket or they always have "those strange, one-offs" for which no support is known.
  
• Even worse - tickets are being mis-routed to incorrect groups en mass causing frustrations, flare ups, and finger pointing in your weekly status meetings.

If you find yourself
sitting in front of email all day...
being tapped on the shoulder constantly....
hiding in the bathroom to take breaks....
explaining yourself to your boss more than envisioning the future of your desk... then you probably have weak or inadequate processes.

So, where are you at? Do you have processes at all? No, I mean documented processes. If sharing the process means you have to tell me what it is, then it's not really a process. Well, I suppose you could call it a process, but it's a process prone to change, error, miscommunication, you might forget it, or heaven forbid it "walks" out the door. That reminds me of a story about this guy Vinnie who was my team lead when I was a support technician.

Vinnie had the life....he didn't have to be on the phones, he only had to answer our "next-level" questions if they weren't in the knowledge base. But he mostly played around with little trinket puzzles and surfed video game blogs. Vinnie hoarded all the information he could find and locked it inside his head. He wouldn't share or document things. Naturally, he was the most valuable player on the team. He had sponged everything. The desk was very unstable after he left.

My point is a process should be clear, hold accountable those who create, change, and implement the process, and provide clear direction to anyone who should read the process.

So, analyze where you are currently and get a good starting point. Create a focus group consisting of one of your brightest technicians...not necessarily the most technical. You want to see what's broken with your internal processes and this will be very different than just something your run of the mill technical person might be good at. If you don't have someone to help then perhaps you are the best to pick apart your process.

First, use the Input | Process | Output methodology to build a "road map" of your current processes. I've included a basic example above. Start at a high level such as the example above and begin "peeling the onion". You will find yourself creating more process boxes, decision trees, and you will probably find some questions. If you get to a dead-end or if questions start to arise then "light bulbs" might begin going off. That's okay. Make notes, but don't try to create solutions yet. You probably don't have all the correct information to complete the exercise in it's final state. We're just looking at the current state process.

Complete this exercise and we'll discuss more on the analysis and solutioning of the process problems in my next article.

A quick introduction...

Hello there....if you're reading this then you probably have an interest in trends surrounding IT, Service/Help Desk. For some time I've wanted to get my thoughts and ideas out for other's to ponder, as the direction of service support is ever evolving making the need for individuals and groups to share best practices all the more important. Please email me with any questions or suggestions you may have for topics.