What makes an IT department awful or excellent is dependent on a variety of factors as well as the company culture. But there are some things that are pretty universal when it comes to a successful IT department.
If you read a lot of articles, you've read about IT departments that run the spectrum from awful to excellent. Obviously, what makes an IT department awful or excellent is dependent on a variety of factors as well as the company culture. For example, while a toxic organizational culture might result in perceived excellence, as the layers are peeled back, it might be discovered that the "excellence" comes from questionable tactics. That said, there are some things that are pretty universal when it comes to considering the success of an IT department.
Since everyone defines success differently and there are a lot of ideas out there about what creates success, I'm going to provide you with a few of my own thoughts on this topic and ask the TechRepublic community to chime in with their own. First, some caveats — do I do all these perfectly at Westminster? No. However, these are some attributes that I keep in mind as I work on improving and adjusting the IT Team.
Ongoing feedback mechanisms and action
At Westminster, we're a small team and our front-line help desk is more than just a triage point. It is through this mechanism that all requests are (in theory anyway) collected and distributed to other members of the IT team for action. Our ticketing system, like many out there, automatically sends a survey to requestors asking them to rate their experience in a couple of different ways.
More importantly, both my Help Desk manager and I read each and every survey, good and bad. For negative feedback, we personally follow up with the requestor to see what we can do better. If we see something systemic that we can reasonably fix, we do so.
Annually, the college as a whole has what we call "Assessment Day," during which students rate many different aspects of their Westminster experience, including the services provided by IT. Through this feedback mechanism, we receive critical information that may not have been identified during the year or we learn the true scope of a problem that has been lingering.
Are we perfect? Nah. We're human, and we serve more than 1,300 people with more than 1,300 individual personalities, but we do take the feedback to heart and do everything reasonable to get it right.
Clear parameters (aka managing expectations)
At first, moving from pure chaos — people can ask for anything, anytime, and anywhere — to a more structured system was pretty unpopular, but the "chaos method" was creating a lot of, well, chaos, including:
- Requests for staffing events well outside normal business hours that was placing a major burden on IT staff and affecting overall ability to carry out primary duties.
- Requests to borrow equipment that were last minute (as in, "Oh my God! I need this delivered right now!" at 5:00 PM on a Friday) and overlapping, making it difficult for us to adequately respond and help people set things up.
- IT staff being cornered in the hallway, at lunch, or in other areas and provided with a verbal list of 20 requests... all forgotten by the time the staffer got back to his desk to enter them into the ticketing system.
So, we ended the chaos and introduced some discipline, which included:
- A requirement that all faculty, staff, and students submit help desk requests via email, phone, or walk-in rather than cornering someone in the hall or catching them while they're on their way to another job.
- A more formal equipment request process that provides reasonable lead time so that IT staff can make sure equipment is in functioning order. This also solved a fairness issue; at times, someone might request something a week ahead of time only to discover that the person who walked in 10 minutes before they needed something got the same equipment, leaving the original requestor without their needs met.
- A delineation of the kinds of events that would be staffed by full-time professional staff. We can't be all things to all people, particularly given significant staffing resource constraints, so we worked with stakeholders to provide guidelines as to what we could and could not do. I won't say that this was a perfect agreement since everyone wants us to be all things to all people, but, over time, the restructuring has lost its contentious nature and is now accepted as SOP.
Again, this was a contentious but necessary change that has forced everyone to think — including us — a bit more in advance of needs to make sure things are lined up. Not everyone is always happy with it, but we have far fewer errors and an overall better experience as a result.
I mentioned above that we introduced discipline to chaos, but we're not jerks. We understand that sometimes, "stuff happens" and we need to maintain some semblance of flexibility. After all, we are a service organization. So, if someone comes in at the last minute and really needs something, we make a best effort to help them, but we don't make a guarantee. At the same time, we remind the person that we need the lead time we've requested and, most times, we get that on future visits. Of course, there comes a point at which we simply have to say no and force a behavior change so that we can appropriately plan our work.
Some events are simply not foreseeable, and we will pretty much drop everything to support them. Recently, Westminster lost a student in a terrible accident and everyone on campus came together to support the various activities that went along with the celebration of that student's life. No one could have planned for such an event.
Of course, this also comes down to human nature and moods. There are times when we should be flexible and we aren't or we shouldn't be flexible and we are. I never said we were perfect!
This is probably our biggest weakness, but it's a hallmark trait of a successful IT organization. As a writer and as someone who understands how to write for a particular audience, when I send a note to campus, I try to keep user technical level in mind. Again, this only comes to me because I've been writing for a really long time and have had an opportunity to hone this skill. Not everyone has had such a great opportunity.
I still sometimes cringe when I see a note go to the campus that contains buzzwords, jargon, technical terms, and the like. I don't want people to "dumb down" communication, but I do want there to be real communication! When I see such a note, I gently point out to the person ways that the message could have been crafted to ensure better communication.
Example of a bad message: "A bad port caused the Internet router storage to fill up with logs and crash. We cleared the logs, and the Internet is back up now."
Recrafted: "An error on one of the devices that connects the College to the Internet resulted in that device failing, which severed our connection to the Internet. IT staff corrected the issue, and service has been restored."
These are just four attributes that I believe are critical to success. What else would you include?