IT Policies

Four attributes of a successful IT organization

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.

Flexibility

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!

Communication

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."

Summary

These are just four attributes that I believe are critical to success. What else would you include?

About

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

8 comments
uberlist
uberlist

I think one of the things successful IT organizations also do is promote learning and growth of their employees. Companies can't always give raises and promotions, but they can give learning opportunities to their IT folks to cross-training, training reimbursement, shadowing, etc. One of the things that many employees look for today in place of raising ranks in the company is raising their 'employability' through learning opportunities. It gives them reassurance that you understand their interests, there is a trust factor there, and in general employees will be more loyal. My take. RM Globalbench Inc. Get the Job. Get the Raise. Get the Promotion. www.globalbench.com

JMasiwe
JMasiwe

This is a good and insightful article. I am particularly interested in some of the ways you have come up with to manage equipment request process. I work for a research organization. Recently we installed mounted projectors in addition to procuring several portable ones. As you can imagine in an environment like ours with several weekly workshops, seminars, conferences etc, the demand is quite high and it is very hectic managing the requets. We are working on policies but are also keen on having a tool through which our users can book these projectors.

ceso_softdev
ceso_softdev

Good leadership will energize people into becoming a change agent rather than just preserving the status-quo. Poor leadership will hinder most efforts from people in the lower ranks of the organization. I have seen this happen way to many times. Good or great leadership its in my opinion, the missing 5th attribute in every successful IT organization.

BradTD
BradTD

This article is spot on in a lot of its conclusions. I've had the same types of issues in my environment, including having to change culture in getting the end users to call a centralized help desk vice calling us directly. It was painful at first but in the long run has definitely increased productivity.

blarman
blarman

This is a great article: concise yet informative. Thanks.

Dereckonline
Dereckonline

How would remain anonymous in your ticketing system survey in a small organization? We have two techs and 80 staff and we are all like family. Wouldn't an end user feel afriad to criticize in this environment? I really want this feature but fear people would be afraid to submit feedback. Thoughts?

davist@childrensfactory.
davist@childrensfactory.

In my organization there is a disconnect between those who actually provide the services and those "sell" the services to the people on the floor which frequently results in missed deadlines (due to promising a date prior to speaking with the developer) or promising certain features whose ROI makes them unfeasible at best. In the end failing to deliver on a high expectation does significantly more damage than downplaying possible features until they have been proven cost effective. I think a mark of an excellent IT organization is one that is willing to delivery what they have promised while walking the fine line of not promising the moon in a vain attempt to look good. We are in a service industry where there are no points for trying, only delivering, so stick to delivering what you are capable of and strive to expand your capabilities prior to selling them. My father had a saying, "don't let your mouth write a check your butt can't cash". Seems like fair advice. There are my two cents...now I'm broke

blarman
blarman

What is the purpose of anonymity? To avoid conflict of ideas and personalization of negative feedback. This is a cultural issue where both sides have to be mature enough to point out _what_ the issue is without getting into _who_ is to blame and work together to improve things. Being anonymous really puts a kink on the whole process listed above. How are you going to get more detail (if needed) about an issue? How are you going to communicate or work with that individual on resolution? How are you going to establish/manage expectations? While I understand your concern, again, anonymity is in and of itself a crutch underlying a bigger problem.

Editor's Picks