Who are your users?

[sherman_1206]

Our process council discussion makes for perfect segue into understanding our user base. Today I will dive into the trenches of day to day operations and establish who your user is. Each user may wear a different hat; it depends on situational context.

Due to the nature of higher education, we are presented with a diverse range of users. Students come and go, professors can remain for decades. Therefore the biggest key to understanding your users is to assume you don't know who they are. By designing end user interactions under this assumption we enable ourselves to provide multiple facets for user interaction. Some want no interaction, they want their issue resolved or request fulfilled. Some want live chat, some email... for discussion of an incident. Consider a self service user perspective on change management records. Should all users view all changes with the same level of detail? Probably not. Each of these users should be presented with a contextually relevant interface based on their affiliation with IT service management. Students need to know when wireless in their dorm is out, they also desire control over how they receive such a notification. They probably aren't following your Twitter feed, or your Facebook page; they should decide how they interact.

Let's run through a small example to understand these contexts. I would like to introduce to you Joe Student. Joe is sophomore undergraduate, he likes long walks on the beach, and yesterday a classmate next to him was experiencing an issue authenticating to the wireless network. Yes the classmate is probably wanting to browse facebook or some other non-class related web service but this is beyond our concern.

Tommy Classmate asks Joe is he can help in anyway; Joe emits a tech-savvy persona. First Joe troubleshoots the issue himself. (In some situations this could make the incident worse than it originally was which presents a completely different context.) After trial and error, Joe logs onto his self service portal and enters a live chat session with a service desk analyst. Joe informs the analyst that Tommy is having trouble connecting to the wireless network.

Shall we break this scenario down? Absolutely, glad you asked! Joe Student is a self service user, Tommy is a self service user, which is the caller of the incident. Does it really matter which is the caller? No, either way the problem is going to be resolved but we need to consider situations where users submit incidents on behalf of others if this type of metric is of interest. Some set of resources are required to assist with resolving this issue. The resources providing support to end users are the facilitators of multiple avenues of self service interaction. The dialog began with a live chat, it very well may continue via e-mail or phone call. Next it may require follow up with dispatching a technician to the location to ensure connectivity and wireless coverage. It all depends on how the interaction unfolds and each interaction is usually never identical.

What if Joe Student is a service desk agent working an honest job to financially support his educational pursuit? Does the above context change? It may. Joe Student may bypass self service and submit an incident through the service desk interface. Does this skew metrics that rely on where records derive from? It can unless you build in capacity to handle these scenarios. What if Joe Student's father was president of the university? Does this change the way this interaction is handled?

This brings me back to the original point, assume you don't know what type of user will interact with a given ITSM process and the odds are in your favor of addressing the multiple facets.

To continue, in Higher Education these lines between what role a resource plays become blurred easily. Our service desk at The Ohio State University employs students; students working our service desk see both sides of this coin. We employ student developers as well, they also see multiple sides of ITSM. Remember, you cannot assume you know who your user is and under this assumption we will enable ourselves to design from all angles or approach.

"But what about our process, do we have to design our process to address all combinations of interaction?" Not entirely, though it is worth discussing and brainstorming various scenarios during process design. Instead of ironclad processes, view them as guardrails on the ITSM highway. They are merely defined for structure and protection. Processes should remain flexible to accommodate all the interaction vectors of your user base. The process is a means to the end, the application is a vehicle to reach the end. Your users and resources are cruising the ITSM highway mile by mile until they reach their destination: resolution, fulfillment, knowledge, change.

The idea is to understand user expectations and assume all avenues a user can approach your ITSM services from. A student, professor, faculty member, regardless of who, they are not concerned with what platform powers ITSM; these users are concerned with incident resolution, request fulfillment and awareness of change to the organization's infrastructure when relevant. (When relevant is important.) Sally Professor will be extremely upset when the VPN is down an hour before his research proposal is due; Sally Professor could not care less about maintenance your operation team is performing on a redundant piece of infrastructure which has no impact on her.

Again, understanding who your user is in context of situations is extremely vital to proper ITSM. Remember our assumption. By not assuming what door your user approaches from you can hopefully consider all the "what if" scenarios. You will never address all use cases, it is unrealistic. By approaching your support services under our established assumption it becomes easier to handle the majority of arisen situations. This becomes especially important in institutions where IT is decentralized. Centralized versus decentralized ITSM is another discussion in itself.

Lastly, I want to conclude with the following sentiment: understanding how you solve a user's ticket is the least of their concerns. Their only concern is IT resources are available when they desire. What it takes to get from an initial ticket to resolution is not their issue, nor should it be. It becomes their issue when your ticket is bounced from department to department, it becomes their issue when they call for a follow up on TICK123456 and you cannot locate it. Was it deleted, did it get passed to another service desk? There exist many possibilities. If we design under our assumption we can hopefully avoid many scenarios that otherwise will become catastrophic to successful IT Service management for end users.

At the end of the day we only exist because of our abusers. I mean users.