Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
IT Technology

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."
This discussion has been archived. No new comments can be posted.

Evaluating the Performance of an IT Department?

Comments Filter:
  • by mswope ( 242988 ) on Friday January 13, 2006 @11:40PM (#14469439) Journal
    Tom Demarco, et. al, covered this in, "Peopleware"

    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.
  • by clambake ( 37702 ) on Saturday January 14, 2006 @12:10AM (#14469518) Homepage
    ...noone will be quite sure you've done anything at all. Good IT, I mean really good IT, will be a whole lot of nothing. You can value an IT department by just how little they have to do, because if they have done it right, there will very very little, beyond patching now and then, for them to actually do durning the day. Of course this isn't true when you upgrade systems, but in general, you should measure them not by how much they did, but by how much they didn't do.

    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!"
    • And I guess I should also add.... no matter how tempting it looks to remove that guy who does nothing all day, don't do it. Finding those kinds of guys is HARD, and when it comes time to make a change to your infrastucture, you'll hire somone who will have a LOT more to do every day, but you will find yourselves paying the price for it.
    • Thats if you consider IT only system administration. What about application development, most companies need custom apps to meet business needs.
      • Thats if you consider IT only system administration. What about application development, most companies need custom apps to meet business needs.

        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.
    • 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. How can you relate money saved on graders or hours of guys driving in a truck to good IT (both system and software development, which we outsource the development of, but I architect myself with our management team)?

      For example, one of our great successes last year was not getting better server
      • 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. How can you relate money saved on graders or hours of guys driving in a truck to good IT (both system and software development, which we outsource the development of, but I architect myself with our management team)?

        For example, one of our great successes last year was not getting better server

      • 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
        • Ah, indeed. About the 2-day Access app, it was most appreciated by our operations manager (which doesn't look at or decide about IT), while the rest of our "generic" work was good and appreciated by other people (my boss, director of MIS and the company president as well). I also made many "2 day fixes" to many other applications in virtually every department, so they are all like "I suffered about this (bug, whatever) for years, but I told you and two days later my job is so much better!".

          You have a good p
  • by toddbu ( 748790 ) on Saturday January 14, 2006 @12:24AM (#14469557)
    Nothing damages the credibility of an IT department more than insisting that everything be done through them. We're an ASP, and we often get calls from users who are doing an end-run around their IT departments so that they don't have to wait forever to get the job done. If an IT department takes some work and outsources other work based on experience and cost, they'll be respected and even sought out for their knowledge. If they get in the way and do everything they can to protect their jobs, then they become the "black hole" that you refer to.

    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.

    • by blincoln ( 592401 ) on Saturday January 14, 2006 @02:32AM (#14469908) Homepage Journal
      We're an ASP, and we often get calls from users who are doing an end-run around their IT departments so that they don't have to wait forever to get the job done... If they get in the way and do everything they can to protect their jobs, then they become the "black hole" that you refer to.

      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.
      • I don't intend you any personal offence

        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

        • We have software in place that allows our clients to import and export their data. Any good ASP should have a system like that in place. We'll manage your data for you, but at the end of the day it's their data and they should be able to take it elsewhere. Anyone who hires an ASP who doesn't have this policy should find a new vendor.

          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
          • but the data is stored in such a proprietary format (particularly WRT database normalization) that it would require a supreme effort to use it with another product.

            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

      • As a contractor, you don't have to worry about whether your solution will still be working in a year.

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

          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
    • Besides the obvious limitations in our little budgets, outsourcing is in place and will be in the future. We are architecting new software, but outsourcing the development (I'm the only programmer in the whole company), and we'll be outsourcing things like risk analysis (for disaster recovery plans) and security evaluation, as well as occasional very techincal issues we can't figure out (did I mention we're 100% Windows-based?). But most of the work is quite manageable (little coding in my spare time and st
    • I hear ya, and there's a lot to the point you're making. In fact, your central premise that the departmental image is damaged by either a bad perception or bad performance is spot-on.

      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
  • Its a real easy 4 step process...
    • First make sure everyone knows the rating schedule. 10% of your organisation are Leaders, 70% are performing at an acceptable level and 20% are not good enough. Doesn't matter if you hire the best of the best or not - its always going to be like that. After all, you're management and know better :-)
    • Next make sure that you motivate your troups. Constant layoffs are a good way. Make sure though that you send out emails stating that the layoffs a
  • The one thing that stood out for me is education of your employers. Get them to know the value of what you do by...teaching them..somehow.

    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..
  • Just pull the plug on IT and see how much the business looses. Maybe then they'll appreciate you more.
    • Just pull the plug on IT and see how much the business looses. Maybe then they'll appreciate you more

      You should write a textbook about benchmarking. Contact McGraw Hill or some other publisher.

  • By Comparison (Score:3, Informative)

    by Planesdragon ( 210349 ) <slashdot@nospaM.castlesteelstone.us> on Saturday January 14, 2006 @02:11AM (#14469848) Homepage Journal
    So one question that arises is: how do we actually value our work?

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

  • by 1369IC ( 935113 ) on Saturday January 14, 2006 @03:47AM (#14470077)

    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

    • That has to be some of the best advice I've ever read online.

      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
      • Baselining and measurement are key to the day-to-day operational management of any group, not just IT, and while it can become a very difficult task to define those measurements, it can build major credibility with other managers in the company if you can provide a clear picture on how the department is functioning and where improvements are being made.

        Another challenge altogether is how to prioritize the IT department's request backlog. Do you have senior management prioritize tasks above a certain level
    • Nice post but for the love of God drop the PR bullshit. I know it's your job but this is slashdot, we can read through it and it just gets our backs up.

      "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.
      • Yeah, you're right of course. I don't talk that way in real life, but like any other specialist, I lapse into the lingo when I get going. But considering this is Slashdot, a favorite of geeks, who are known to use as much jargon and lingo as anybody, I'm only going to own up to the weakness, not apologize for it. It's karma, after all, to get back some of what you give.
  • You COULD lok at industry metrics for efficiency and look at why you have a higher efficiency with senior management, and discuss how that fits into IT's contribution.

    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
  • When the users are satisfied with the job done by ITD you are about ~80% from a successful goal. The other 20% are value for money or $ goals met. imho.

  • Schedule a day (or a few) where all computers will be shut off. No, really - you'd be amazed at how cooperative some companies would be with a Disaster Recovery Drill. If they're not willing to go that far, you probably shouldn't have to go any further.

    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
  • I run a small IT department at a construction company.
    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
  • 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?

    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

  • I, too, work for a construction company, specifically, a roofing company with over 200 employees. As you are aware, we have about 25% of these employees actually in the office while the other 75% are out on the roofs. I run a one-man IT department, but have also attempted to get myself included in some aspect of every part of the organization. This makes me a valuable commodity and ensures job security. I agree with postings that reference how the IT department could be valuated on the amount of actual d
  • I hate to document more then the next guy. Documentation is my least favorite thing to do in IT. But... It is the only way that we have proof that we actually did something. Every time there is a problem have some method of keeping track of it. Either via a bug track program or what ever else. After you hot swap out a drive before the other one dies, document it. If all the other business units get infected with a virus except for yours, Document it. For the next year compare the previous years documen
  • Have everyone in IT take a sick day on the same day.

    They'll understand immediately what value you bring.
  • The best way to get people to appreciate the value of an IT department is to keep everything working perfectly. People don't want lots of fancy features and knick knacks. They want to check their email and get online with no hassles.
    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

The system was down for backups from 5am to 10am last Saturday.

Working...