Tag Archives: troubleshooting

An IT manager must be a teacher

Let me share a personal story that goes far back into the dark  ages of time, , , the mid-1980’s.

I was with a company and we reorganized the company to place more focus on our clients. In this reorganization I was assigned the IT support manager position to support 25 hospital clients using software applications our company developed.

I inherited 25 or so IT employees, , , mostly programmers with a few Business Analysts, Help Desk and Infrastructure people. Most of my new staff had 3-5 years experience in supporting these clients. It was a young group but very smart and high energy, , , one of the best IT organizations I’ve worked with.

They knew the software application inside out, , , knew a lot about client service, , , and were very conscientious about doing a good job for our clients.

Experienced, smart, and conscientious, , , seems like we would have been very successful without the new manager (me) having to do very much.

WRONG!!

What the team was missing was processes and insight about what it actually takes to take care of your client. I would learn the hard way over the first few months that I would need to teach them some of the basics in:

  • Troubleshooting problems
  • Follow-up
  • Communication, , , especially listening
  • “The client is always right”

Let’s take just the first one, , , troubleshooting.
We had a very large client who had apparently always had problems, , , people from this large hospital were difficult to deal with, demanding, and could even be rude.

If you step back for just a moment and think about these things, there is usually a reason why people act this way. In this case, it stemmed from a recurring problem the client had every month end. It was a real problem for them and my staff either discounted the issue or did not fully understand the problem, , , so the same issue came up every month.

After getting hit with this issue myself, I decide to take a small group to the client to observe what was taking place. To resolve a problem, you have to know what the specific issues are, so that’s what we set out to do, , , troubleshoot the problem.

The issues were immediately apparent because we were there and “heard” what the client was saying, , , we experienced it with the client so we understood what was actually taking place.

Here is where it gets important:

  • We quantified the specific issues
  • Got the client’s agreement these were the issues
  • Recommended a solution
  • Gained client agreement again to support our recommendation
  • Implemented the solution

This solved our client’s issues, , , and guess what!

They became less demanding and more pleasant to work with. Interesting how this works.

The point
Even though my team had tremendous knowledge and experience and they were very intelligent people, , , they were not troubleshooting the issues with this client very well. They could not quantify the issues for me when I asked about the problems the first time I received a phone call from our “unhappy client”.

It was a great teaching opportunity that helped the team develop into a more capable organization.

Inspect and be sure your people know how to troubleshoot a client issue.

Does the right hand know what the left hand is doing?

Early in my management career I inherited a small IT support group of programmers and business analysts. It was a very bright and capable staff although they were pretty young.

We had a client who always had problems during their month-end process. I had heard about these problems before I joined the group. Sure enough, at the end of the very first month I’m the manager, the client had problems and I take a call from their CFO.

I asked several questions but did not receive any feedback that told me what the problem was. I discounted the issue and thought that maybe it was an anomaly. This would prove to be a mistake.

At the end of the 2nd month, guess what happened. Yes, , , they have problems again. This time I call the client and we decide to have a couple of people visit their office during the next month’s process.

I took two of my most capable people, , , a BA and a programmer to the client to observe the End of Month process during the 3rd month I was the support manager. Our mission, , , identify what the problem is and why it is happening. Once we know what the situation is, we can fix the problem.

The key problem was identified quickly. What was happening was that the client had to run several large detail reports prior to their month end backups every month. Because these reports were not completing in time, several people were kicking off the same report, , , in other words, the same report was being run three or four times simultaneously.

This level of systems activity was slowing the system down significantly, , , so much so that before the reports could finish they had to be cancelled so the client could run their month end backup processes.

We recommended the client put into place a “Month End Jobs Coordinator” to insure only one request of a job could be run at any given time. This improved systems performance and these large reports now had plenty of time to finish running in the months ahead. This simple management supervision corrected the problem completely.

This issue of the “right hand not knowing what the left hand is doing” can cause a lot of problems. Often, the pain is significant and the remedy is something that’s very simple.