IT Employment

General discussion


Support Department Setup

By Becker-2004 ·
Hi all, does anyone have any good links to articles or analysis on Tech Support deparments.

Basically, we are looking at internal re-organization. And I am collecting information on what a proper tech support department is structured like.

informatino like:
- who does what?
- how many people per user/per type of user?
- who should report to whom?
- what titles should they have?
- RIO analysis of spreading IT responsililities amongst tech savvy analysts or keeping dedicated IT staff for the roles.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Reflect on what you support...

by Dilbert-Tom In reply to Support Department Setup

First of all, do not 'overbuild' and do not 'overcommit' (unless you'd like to manage an outsourced function...).
Before your questions can be addressed, there are some questions about what you are supporting...
1) How many functional 'areas' are to be supported (eg; 'Platforms' or 'Applications') ?
2) What is the required level of support and are there any cyclical patterns of usage (24/7 ? M-F 9-5 ? Fix by next day ? - any pecial Periodic requirements like Monthly reporting, etc.)?
3) How does your business/industry typically organize (some have everyone work for 'Sales', some have seperate, 'equal' IT/Marketing/etc. structures, etc.)
4) How sophisticated are the clients using your systems (do they develop ? modify ? or can they barely log on ?)

Once you've figured those out...

- who does what?
IT needs to at least administer and coordinate. An IT structure of 'Specialists by Application' often works well (sometimes one 'Specialist' might manage several Applications, especailly when users do their own development. If substantial development is anticipated to be ongoing, then developers may be needed as full-time 'perm' staff - for sporadic development, Contractors might b beter [they're already "Pre-Fired" so no severance issues, but when they go they may take some knowledge with them if documentation is not a deliverable], for 'Upgrades' or 'New Products' Vendors sould be able to support your "Specialist".
- how many people per user/per type of user?
Depends on anticipated changes, and technical abilities of the user base. For every anticipated ongoing 20-30 hours effort weekly increase headcount. 8 hours will be consumed in Admin and training weekly per headcount.
- who should report to whom?
Although an administrative IT structure (for Payroll, and admin.) may be helpful (also to stay coordinated regarding system changes - so that IT communicates within itself), it can also be useful to have resources assigned by functional area (perhaps application, or if application is large, perhaps broken down additionally by functional area [eg; FOCUS <a 4GL Query/Update 'EndUser language> might be used by Marketing and used in totally different ways by Payroll - if these areas are snall enough, one person might support it - but if Marketing has over 2000 users and Payroll has 12 then questions like "What are they doing with it" need to be examined before finalizing org.
- what titles should they have?
Titles are silly. Someone should be managing the IT Function (Chief Information Officer ? Director of IT ? Manager of IT ? Team Lead ? High Muckity Muck ? End-User IT Liason ? Boss ?), titles really make a lot less difference than who reports to who - and check some surveys to see what is a 'fair' salary (too little and you'll be hiring losers, too much and you'll have no room for raises - and you'll be making it difficult for those workers to think about working elsewhere - and some will benefit everyone by leaving, and might be encouraged by lower raises for lower performance.

The better question is how to measure performance - don't go strictly with meterics that encourage IT to have users constantly calling so that IT 'looks good' - concentrate on eliminating redundancy, and training and leveraging the 'brighter' endusers to be 'primary' area contacts (to solve the really easy stuff, and pass along the stickier problems). Then train about what to do with the tougher problems, document solutions to recurring problems to be easily accessible - the goal should be reducing problem calls and enhancing the IT 'environment', improving response times and assuring data integrity.

For the last 10+ years, this is what I've been doing - making enduser networking so srong that IT can concentrate on improvements rater than stopm out 'fires'. So as to be delivering better IT technology with fewer, smarter staff members.

The hardest part is that when I've reduced monthly problem calls from over 40 to 1, I am often unneeded - so must find another contract. Often the IT manager is all that remains (for user support). Even good System Development can be completed to be very easily maintainable, again putting me out of work (although with my references, I am seldom out of work for long).

Collapse -

by Becker-2004 In reply to Reflect on what you suppo ...

thats a pretty good post. very detailed, to the point and useful.


Related Discussions

Related Forums