work effort of internal IT department [duplicate]

So there is an IT company: foo

In this IT company sysadmins work via a ticketing system. Everything is OK, but for one thing:

The management wants to track what is the dispersion in workload. So sysadmins need to open a ticket (X), for their original ticket (Y) by hand (for non-ticketing work too), so with the ticket (X) management can track that how many ticketing, and non-ticketing work has been done.

Q: are there better solutions to track a sysadmins work? Doing it by hand just isn't logical. (and no, they cannot automate it.)

If I'm asking at a wrong forum, then please advise by a comment where to ask it, but I think this is a UNIX sysadmin related Q, because I think most of us on the serverfault.stackexchange.com are related to this world.


Is your job closing tickets or working as a sysadmin?

I'm of the opinion that a sysadmin does more then handling tickets and using the ticketing system as primary time accounting and job justification would be the wrong tool for the job.

As a manager or team lead you should already know what consumes most resources/time/money/effort. If you have some "fat on the bones" you can do a little bit more with the same team or do the same with slightly fewer people but typically if you need to save money you're simply going to do less.

Save 30% and you're not going to get after hours support even when your CEO drops his blackberry in the loo.

Typically there's routine work, incidents, project work and overhead and you use tickets for only incidents and if you can't avoid it; routine work.

Routine work scales more or less linearly with the number of systems/clients/applications i.e. for every # number of .... we need one additional sysadmin. By spending effort in automation and "expectation management" you can often increase that # number of ... significantly. Regardless keeping things up and running takes time and effort. Doing routine work well prevents tickets being raised in the first place.

Creating tickets for routine work often introduces more overhead and delays and while it gives you accounting you won't get ahead.

Example: each new server takes e.g. 16 hours of work to unpack, rack, cable, install OS, burn in, configure OS/monitoring/backup/SAN/deal with DOA's/ etc. 20 new and replacement servers each month equals two junior sysadmins. Buy a complete cabinet with those 20 servers and their switch loaded and pre-wired and get that shipped to your datacenter instead and engineer an imaging server and you could do the same easily within a single workweek or less.

Logging of incidents is typically a good thing, because by definition they're not planned. Common/recurring incidents can be found and engineered away but you need some justification to make that effort. Incicents and the more complex problems can take serious effort and time to resolve and some accounting of time spent isn't a bad thing.

For project work you don't need tickets, you work with a predefined budget after you have given a quote based on e.g the high level design or a requirements document. After the project has been approved and budget allocated you use common project planning and accounting techniques and not a ticketing system.

Overhead is team meetings, talking to your management about the usefulness of ticketing etc. It doesn't close tickets but is still important.


Since I don't have enough rep to answer in the comment section, I'm going to drop it as a solution.

The solution requires the admins and management to actually talk. Management should have some insight as to what a sysadmin does - regardless of platform. A sysadmin should have some professionalism and insight as to what problems are using up his time and is that a good thing.

Help-desk systems are great for management because the scope is often homogeneous i.e. tier 1 and 2 issues that impact a small department. A (good) sysadmins work will cover a wide range of impacts that are not always measurable and if they are, often require more than a ticket to quantify. Management has an issue and decided on a tool to measure something that they are unfamiliar with. I recommend having management sit down and talk to the sysadmins about what parts of their job having a significant or ROI in management speak, what parts of their job are an inefficient use of their time and agreeing on a way to measure that. Alternatively, management could talk the sysadmins and actually come up with a solution to the problem together.

I propose that a professional sysadmin would welcome the opportunity to unload scut work and work on things that have a significant impact. If their work truly does have an impact, then some sort of metric can be used - besides the almighty uptime - and management can have a greater insight into what a sysadmin does. If the sysadmin just wants to play firefighter and lifeguard all day and/or can't clearly communicate their importance to the organization, then that's a different conversation.


I don't know if this question will stay open as "good subjective" because it is heavily opinion-based. Or is it?

  1. There might be exceptions, but it's pretty much a given that tracking what you work on is a good idea. (*see below)
  2. A lot of what you work on as a SysAdmin is in response to what other people need - support, requests for new services, etc.
    • You'll probably use some sort of ticketing system to handle those requests
    • And hopefully it has some ability to track how much time you spend on each request
  3. So if you're already using a ticketing system, why not use it to track your other time? Or at least most of it.

e.g. our ERP system knows about issues (requests/tickets), it can also handle tasks, which can be linked to an issue or not, and tasks can automatically capture time and feed it into our timesheets. For things I work on that aren't directly in response to a request, I can still create an issue and/or a task to keep track of the time I spend. There's only a small %age of my time that's "left over" and entered into our timesheet system without being linked to a ticket.

I'm not sure exactly what you mean by:

Doing it by hand just isn't logical.

But there are certainly many ways to increase the automation... get a tablet, access the ticketing system by wireless as you go; get a tablet and use an app to track your time, I'm sure there's something that would let you just pick what you're doing from a menu, e.g. Now I'm having coffee, now I'm checking ServerFault, now I'm telling @Wesley to get a damned bike, now I'm doing work.

(*)

enter image description here