Use the Right Tools and Have the Right Discussions To Ensure Your Process Works

To know if a process is working in your IT service and support organization, it’s important to accurately document that process, with detailed information provided every step of the way. Just as important, however, is to see if what is documented meets reality, and that will take face-to-face, or at least Zoom-to-Zoom, conversations.

Let’s take a look at both steps:

Process Mapping

A foundational tool for improving any process is documenting – or mapping – the process. While this is a common-sense and logical step towards any effort to improve a process, it is also one that requires a significant amount of work. The effort is well worth it, however, if only because having good documentation is always a positive thing. Being able to leverage that documentation towards an improvement initiative is just a bonus.

A good process map is a layered document with a high-level flowchart that drills down to a granular map, which, in turn, links to associated documentation and tools. Because a process is rarely static, the process map needs to be reviewed on a regular basis to ensure it remains accurate and up-to-date.

A process map breaks out the general responsibilities of different functions. In our example, let's say there are two functions – the Service Desk and Level 2. Each step is labeled and numbered, and at the top of the map there is often a timeline that indicates the expected duration of the process. Based on this map, the duration from the point the agent takes the call to the final disposition – either resolved or assigned – should take no more than 15 minutes.

In an interactive process map, there would be one or two, additional layers underneath each of these process steps. For example, if we were to click on “Step 1 - Incoming Call”, perhaps the underlying documentation is information on the phone queue, how to answer a call, or use the phone.

“Step 2 - Incident Diagnosis” may have more than one layer. Clicking on that box may take you to a more detailed map made up of the broad steps involved in Incident Diagnosis.

In this example, the map tells us that the Diagnosis step entails gathering customer information and details on the incident, checking the knowledgebase, and documenting what is found before returning to the higher-level map (as indicated by the circle). This map likely has a further level to get details on what is generally required in each step. If the agent clicks on “2C-Check Knowledgebase”, they may be taken to documentation on how to access and search for knowledge. Likewise, clicking on “2D-Documentation” would provide a template on how to document the incident, what the customer was asked to do, and whether the incident was resolved or needed to be escalated further to a specialized support team.

This just scratches the surface on how a process map works. A well-researched, accurate, and documentation-linked map can be hugely beneficial, not just in day-to-day activity, but in training and onboarding new employees and getting them quickly up to speed on how things flow through the support process. It can even be a marketing tool for IT to demonstrate to customers or the business that there is useful documentation, which in turn can be helpful in regulated environments in the event of an audit.

The Human Element

This leads us to another foundational tool in the CPI arsenal. If you truly want to know how a process works, there’s no better way than to talk to the people who are actually doing the work on a daily basis. If you’re a manager and you work within a large organization, you probably have certain assumptions on how a process works, but unless you’ve spent the time talking to the people who do the job, your assumptions are probably wrong. Even a well-documented process will, over time, become corrupted, as individuals find workarounds. The workaround could even be a better approach than what is documented, but that improvement fails to become a best practice because of management assumptions.

To know what’s happening on the ground with your well-documented process, take some time and set up focus groups with the people responsible for doing the work. If you have documented processes, bring that documentation into the group, as well. The key to an effective focus group is the freedom to speak candidly and openly about how things work. Depending on the environment, it may be more effective to use someone that could be considered a neutral 3rd party to lead the discussion.

As an example, one series of focus groups I led in a support organization did not allow any management into the meetings. My introduction clearly laid out the ground rules – avoid personal attacks, speak openly and freely about how things get done (or don’t get done), and understand that anything we spoke about within the confines of the focus group would not leave the group with anyone’s name attached. Since we were having multiple focus groups across many different locations, we could be assured that everyone maintained their anonymity.

Take the first half of the meeting, or if possible the first meeting, to walk through the current process documentation. Gather feedback from the group on whether the documentation is accurate, and if the process is working well. Flag the problem areas, but avoid getting bogged down on finding solutions.

The second phase of the meeting will be looking at the problem areas and brainstorming possible changes that could improve efficiency and eliminate waste or non-value-adding process steps. It can be amazing how often there are steps within a process that are remnants of different initiatives and have remained in the documentation because “we’ve always done it that way”.

There are a couple good tools that can help facilitate brainstorming. The first is the fishbone, or Ishikawa diagram. The Ishikawa diagram focuses on a single problem, and breaks out the potential root causes into categories. In this case, there are six, ranging from Equipment to Management issues. In each of the categories, the group will brainstorm the issues they see that could have a downstream impact to the overall problem. This enables the problem to be broken into components that are easier to manage and quicker to address. It’s not really necessary to draw the diagram, though there are some tools that take care of that part. Usually, it can be simpler to just create columns in a spreadsheet, and create separate tabs on the spreadsheet for different problems.

A similar tool is called mind mapping. This is one of my favorite tools for facilitating brainstorming sessions. There are a number of open-source applications that run on a variety of hardware and operating systems, which makes it an attractive option. I find it to be faster and much less cumbersome than the fishbone diagram.

Mind mapping is simple and intuitive. It starts with a central topic or problem, to which are added main topics and subtopics. The concept is very similar to the Ishikawa diagram, but much more versatile. It’s quick and easy to create new fields or move between fields by using simple keystrokes. It’s great to put up on a screen and fill it out in real time.