How Technical Support Is Like a Pain in the Neck

A strategic planning session and a recent injury combine to provide insights into challenges associated with changing negative perception of technical support services.

I don’t know exactly what caused the problem. I may have crashed into a wall harder than usual while playing racquetball. I vaguely remember the hatchback of my car lightly hitting the back of the head while I was unloading something. I may have “slept on it wrong.” All I know is that about a month ago, I woke up with a stiff neck.

I didn’t think much of it. It was a little uncomfortable, and the range of motion was slightly restricted. I had to turn my head slowly to avoid discomfort. But, it was a busy time, and I charged on with my day.

As the day wore on, I became more uncomfortable. I couldn’t turn or elevate my head at all. I learned that taking aspirin or drinking out of a cup without being able to tip my head back was painful (and a little funny). By the evening, I was not a happy camper. It became very difficult to lie down. I was really appreciating the fifty-three prior years I had enjoyed without ever injuring my neck.

Twenty-four hours and a fist full of ibuprofen later, I was fine.

A few days later, fully recovered from my “neck lock” incident, I facilitated a planning session with senior IT staff of a local organization. We reviewed the thirty-year history of the outfit. Many of the people in the room had been there fifteen years or more and had a long-term perspective on some of the challenges.

In this organization, IT mostly consisted of application, desktop, and network support (application development was outsourced), and the past few years had seen a procession of frustrated IT leaders with differing visions. The scope of the support work performed by IT had expanded with the growth of the organization and the addition of new applications, but IT headcount had been frozen and budgets had been shrinking for the past eight years or so. IT wasn’t highly valued, and their budget had languished as a consequence.

The group seemed honest in their assessment: The support organization had earned its spotty reputation for service. As we discussed the kernel of the problem, it became apparent that there was danger of a deadly embrace. Business users were frustrated and skeptical of IT’s ability to deliver and hesitant to allocate more resources. Meanwhile, shrinking budgets and expanding scope were stressing the IT support organization’s ability to recruit and retain staff, and service was continuing to decay. The bottom line was that resource relief was not expected in the near term.

The new CIO had been working to improve governance with the business executives and had succeeded in getting a list of the current IT projects prioritized. The business execs, though skeptical at first, quickly embraced the notion of prioritizing IT’s work when they realized that this might influence the level of service they received.

From a planning perspective, the challenges boiled down to the following questions:

1. How can we successfully address the top ten projects as prioritized by the business executives?
2. How can we improve the level of service we provide to our clients?
3. How can we improve our clients’ perception of the quality of the service we provide?

Several people in the room were initially surprised when I emphasized the distinction between items two and three. Engineers and technical people often leap to the conclusion that the best way to improve the perception of service is to improve service. In reality,