Evaluating the Performance of an IT Department? 46
Daniele Pagano asks: "I have just been promoted from code monkey to manager of the IT department of a construction subcontractor. As far as this industry goes, we are relatively high-tech (and getting better), but like many IT departments we are often considered a necessary money 'black hole' (i.e. they just notice the outages). So one question that arises is: how do we actually value our work? That is, how much money are we actually saving the company, and how do we demonstrate it to them? How do we value the contributions of each IT staff member (say, for a bonus or raise) in an objective, quantifiable manner? I know there is no one correct answer, and I have many ideas, but I thought we could pull our thoughts together for the betterment of small IT departments everywhere."
Suggestion, if you have the time (Score:4, Insightful)
You need to figure out what benefits you bring to your company vs. what costs
your company would bear w/o you.
If you have the time, read "Peopleware." (it's not a very long read) If not, figure out what it would cost to outsource you. Keep in mind that a lot of outsourced support ends up under "capital or recurring expenditures" rather than "personnel costs."
In our industry, it seems that on the average of 6-8 years, some bean-counter in the company says, "we're an XYZ-company, not a communications/high-tech/software/ technology company." Then, cut-backs start, out-sourcing starts, costs soar and after a very painful 4-6 years, they start hiring people back to run the soft underside of the company.
Re:Construction? Hope you aren't in California. (Score:1)
If you do it right... (Score:5, Insightful)
So, instead of saying "Joe fixed three server meltdowns this week, good job, here is a raise!" go with "Joe's machines haven't needed maintenence for three years, here is your raise!"
Re:If you do it right... (Score:2)
Re:If you do it right... (Score:1)
Re:If you do it right... (Score:2)
That's simple, don't attempt to measure them with the same stick. Internal application development should be measured with the same bar that you would measure app development for outside customers. System administration, however, should not be a part of that calculation, that is it's own ball fo wax.
Re:If you do it right... (Score:1)
Re:If you do it right... (Score:3, Interesting)
For example, one of our great successes last year was not getting better server
Re:If you do it right... (Score:3, Interesting)
For example, one of our great successes last year was not getting better server
Be prepared to face an ugly truth... (Score:2)
This is definitevely good as far as IT goes, but as a construction company only a fraction of our business is in the office (450 field people, 50 office, 3 IT), the rest is guys digging trenches and pouring concrete... For example, one of our great successes last year was not getting better servers and dramatically increase uptime and all kinds of good IT things, but was spending a couple of days writing a small Access app to import budgets from one system to another via ODBC so we can tell if we are losin
Re:Be prepared to face an ugly truth... (Score:1)
You have a good p
Make sure to outsource (Score:5, Insightful)
If you want my advice (and why wouldn't you? ;-), I'd do a poll of other departments to see what they think of IT. Talk to everyone from the office grunt to the VP of department X, and take the temperature of your department. Don't be afraid to get beat up, and then go back and do some soul searching on the stuff that people don't like about you. Then go back out to these same folks and let them know what you're doing to solve their problems, and be sure to point out that you know your mission is to help them get their jobs done.
Re:Make sure to outsource (Score:5, Insightful)
I don't intend you any personal offence, but this kind of mentality is one of the main causes of headaches for me - someone who works in the IT department at a fairly large corporation.
Obviously there are some exceptions, but if we make someone "wait forever," it's usually because it will take "forever" to do it in a way that is supportable in the long term. As a contractor, you don't have to worry about whether your solution will still be working in a year.
There are many, many times that people in other parts of the company have gone off on their own and hired contractors to do something because they wanted it quickly. Usually what they've gotten is a rush-job that is barely stable to begin with, let alone a year or three in the future. Excel macro "applications" that can only run on Office 2000. Thrown-together server apps that can't handle anything other than the JRE they were originally written for, let alone an OS upgrade like Windows 2000 -> 2003. Web apps that have strict dependencies on outdated and unsupported versions of multiple products - each from a different company.
These things go on to become critical parts of the business, with years of data stored in them. Then they break. Who do the users blame? IT. Because they don't understand why we can't make their undocumented, nonstandard, proprietary software work on a modern OS.
We do use contractors for a lot of things - when they're hired by IT, and work with IT employees, they can be great. But non-IT workers hiring contractors on their own isn't necessarily a sign of a problem in IT. Sometimes it's a sign of a lack of understanding of IT, and why sometimes it takes a little longer to do things the right way.
Re:Make sure to outsource (Score:3, Interesting)
Just as long as you don't tell me that my mother wears Army boots. :-)
As a contractor, you don't have to worry about whether your solution will still be working in a year.
As an ASP that charges a monthly fee, if we screw up then our business goes away. That's the "service" part of the term ASP. We tell our customers that they should hold us accountable not only for getting them up and running but for making sure stuff works on a continuous basis. We listen to
Re:Make sure to outsource (Score:2)
If your software allows you clients to import and export data in a neutral format, that's awesome. Obviously it's not like we don't have access to our own databases (or in the c
Re:Make sure to outsource (Score:2)
I understand your point, but then do you want your vendors all writing to a lowest common denominator just because some other vendor doesn't support a specific feature? In our case there is no standard to write to any, but if there was then we'd be careful to ensure that it was extensible so that we could push all of the data instead of just s
Re:Make sure to outsource (Score:2)
You left out a word. "As a bad contractor you don't have to worry...". The rest of use get work by repeat business and references from satisfied prior clients.
Re:Make sure to outsource (Score:2)
That is generally true, and I don't mean to imply that all contractors are scam artists. However, a lot of the contracted work I've seen was very satisfying to the business users who purchased it (to the point that they had the same people do *more* work for them), but was a nightmare for us. Again, because when it broke, they assumed it was our fault
Re:Make sure to outsource (Score:1)
Re:Make sure to outsource (Score:2)
But...
Outsourcing where you're weak and insourcing where you're strong can work fine. But, lots of the "black hole" bits I've seen happen when I.T. people estimate timelines poorly and executives fail to prioritize what's "business" and what ain't. Or, ever-changing user perceptions lead complex-but-manageable projects into nev
Easy... Follow the lead of the fortune 500 CIOs (Score:2)
Education! (Score:1)
Ok ok, so maybe that's easier said than done. But if they're only looking at the bottom line (money in, money out), you won't get the respect that one deserves..
One way to measure... (Score:2, Funny)
Re:One way to measure... (Score:2)
You should write a textbook about benchmarking. Contact McGraw Hill or some other publisher.
Re:Best Way To Evaluate (Score:2)
Complancency. Your department will work to get everything stable, then stop. They'll never touch those apps/servers/machines again because they know that stability is paramount and any changes are bad. What happens in 5 years when you software is 12 versions behind and your hardware is so old it starts dropping like flies?
The truth is, upgrading/changing/migrating is not something that can be stopped easily and cheaply. One or two years is fine,
By Comparison (Score:3, Informative)
The way you value your work is by expressing how much cost you have kept the company from otherwise spending. If you had unlimited time to evaluate, you could go out and see how many dollars the company would have to spend to have someone come in and support every project you support, with the same level of response that you have.
Demostrating it is less easy, especially if there aren't any renovations you can do to immediately save your company money (that is, the job has been done right already.)
How do we value the contributions of each IT staff member (say, for a bonus or raise) in an objective, quantifiable manner?
Decide on a perfomance metric that you can objectively measure for each task. A web developer should be rated differently than a tech support person, for example. Metrics should preferrably be such that a tech trying to game the numbers will be working more like your ideal employee (i.e., instead of looking at "time to close ticket", look at "time to first response" and "satisfaction of non-IT")
Get to know, then educate the dominant coalition (Score:5, Insightful)
I see parallels between the IT field and my own (communications, as in PR, not telcom) because, while you can come up with certain measurements, they mean very little in the end. This is because most of the people who matter don't understand what you do anyway. What they know is leadership, management and teamwork, and IT and communication departments many times really are black holes in these areas. I've been a couple of places where the only reasons people put up with IT and PR is that they don't understand computers and they're afraid of the media.
On the PR side we have a concept called the dominant coalition. I just means the group of people who dominate the organization (it's usually more than just the boss, and rarely mirrors the organization chart exactly). Do a little strategic communications research on them: figure out what they like, how they talk, what they value and how they do things. Then get on board as much as your field and personal ethics will allow. You don't have to go whole hog sycophant, either. Just find out what's important to them and do the things you feel comfortable doing -- learn their staff work, wear "management" clothes, take a couple business courses to learn the lingo. Just remember that sometimes the leader has to take one (or several) for the team. You might have to buy a couple sport coats to wear to meetings so you can better represent your guys while you're there. And it all counts in the end -- how you work, your personal habits, etc. Yeah, it's not fair, but it's fact.
You're not trying to build up brownie points, either. You're trying to do two things, really: show them you're part of the team, and build up enough credibility so they're open to your education and ideas. If you really, really want to resist becoming a "suit," or whatever you want to call it, you might consider telling them you'd rather go back to being a code monkey. You've taken on a responsibility, and most of earning your money now comes down to two things: taking care of the boss and taking care of your guys. There's nothing wrong with wanting to stay on the technical side. There's only something wrong with taking the management money, sitting in the management seat and keeping your head on the technical side. You're screwing your boss and your guys.
Once you build up some credibility, you can educate them slowly and carefully about what you do and what you can do. For most people, getting down to the nitty gritty with IT guys is like listening to Geordi LaForge. It's all tachyons and sub-space transmissions. And most IT guys, I must say, seem to cultivate that. As I made my personal journey from a Mac user who was happy to fiddle with themes to a Slackware user who built his own boxes, I discovered what bullshitters many IT guys were. Not that they were evil or lazy, just that they had a perfect cover for continuing to do what they preferred to do, or not taking on something they didn't want to, or for getting money they didn't really need. And while they got away with it quite a bit, people knew. They could rarely pin the IT guys down enough to enforce their will, but in the backs of their minds they knew. That also explains a lot of seemingly capricious decisions: the management just doesn't trust you, and can't base denial on a deep understanding of what you do, so it denies things on whim or intuition, which is sometimes quite wrong. But bullshitters bring it on themselves.
Anyway, as you educate, get your guys on board with the rest of the team. Go where they're going, and don't just be the slave standing in the back with the emergency oar repair kit. Row. Figure out a way. If you take the previous poster's advice and start to get noticed for the fact things run so well you're not terribly busy, manage by walking around. Stop by some drone's desk and ask how you could help him more.
And lastly, remember you're in a service industry. Don't let the hardware fool you. You're the guys who keep the computers and the Internet working. T
Re:Get to know, then educate the dominant coalitio (Score:2)
A few things I'd like at add:
First, if you stay in management, read about it. You can't be an effective programmer unless you understand your tools. You can't be an effective manager unless you do the same. Commit to reading at least one hour a day from a management book. Start with "7 Habits" and then progress to "Execution: The Discipline of Getting Things Done". After that, just browse similar areas and try to soak in as much as possible.
S
Re:Get to know, then educate the dominant coalitio (Score:2)
Another challenge altogether is how to prioritize the IT department's request backlog. Do you have senior management prioritize tasks above a certain level
Re:Get to know, then educate the dominant coalitio (Score:2)
"Get to know the people above and below you, it's your job to be a bridge and make it easy for both sides".
No market talk, to the point, no bullshit.
Re:Get to know, then educate the dominant coalitio (Score:1)
Industry Metrics (Score:2)
You could also look at the applications you run and how they contribute to the bottom line (change-order programs, especially). You can TALK to employees and management in the office and find out how you can help. (No frigging surveys!)
But, the most effective approach is going to be to figure out how to help the foremen in the field get their
Happy users + Happy ITD = Success (Score:1)
Show them the costs of not having IT (Score:1)
Drum out the costs of not having organized IT or key computer systems: rampant viruses, spyware, and incompatabilities.
But if that won't fly, start calculating how much time would be lost by not having things fixed or working properly. Take a stroll throu
Let management evaluate you (Score:1)
Every once in a while management decides to evaluate my department by hiring an IT company to have a look at my department.
That way they'll get a thirth party view that they "trust".
And I encourage them to do this! Therefore I always fully cooperate by showing them [the thirth party] everything I have running and how I'm handling things.
In the end, my own way of handling things always tends out to have to best price/value comparison.
After that, they'll a
The answer isn't easy... (Score:2)
The only real way you can do this is to document the hell out of everything you do in the IT department. You can do this on paper, but it is infinitely easier to do this with a customised software suite, consisting of job t
IT Department Valuation (Score:1)
Document - Document - Document. (Score:2)
Show them what happens if you're not there. (Score:2)
They'll understand immediately what value you bring.
Forget all that stuff (Score:1)
The IT department I used to work for had a similiar problem. The powers that be saw IT as a huge waste of money, and everyone else scorned us. So we stopped focusing on adding features, and started focusing on stability and service. After that, our managmen