Slashdot Mirror
Evaluating the Performance of an IT Department?
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 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 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 losing money on the field or not. That's what really matters in the end! But how do you quantify such things?
The cookie told me to.
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 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 losing money on the field or not. That's what really matters in the end! But how do you quantify such things?
Well, one thing ot remember is that you should only quantify the ends, not the means. Meaning, you should measure the quality of the final product, and not spend too much time attpting to measure the ingredients that went into that. Of course, if the final product is crap, then you will want to start measuring on finer and finer grained levels, but if you are being successful, then be VERY careful how deeply you look into your process.
Look too deep and you will feel the natural inclination to "fiddle" with things, only to find that it's a game of Jenga, and every thing you touch has the potential of bringing your entire development process down around your head in a way that you won't be able to recover from.
Not all "inefficiency" is as bad as some management classes/books will lead you to believe. In fact, more often than not, the percieved inefficiency is actually a vital component that you just can't see as such because you failed to notice some subtle element of the complete system.
Read studies on the incredible problems, for example, that plauged the park services in the early 1900's as a good analogy of what happens when you fiddle with carefully balanced systems. Maybe people wanted to protect the elk from becoming extinct in the park, so they killed most of the wolves that hunted them... so the elk population exploded, ate the forest clean and ended up extincting themselves, but not before extincting the beavers who also needed the same shrubs that they ate, which caused the salmon to die, which caused the river-grasses to overgrow, which caused... etc, on and on. Each step of the way the rangers would tweak one bit, then another then another, all trying to bring everything back into balance, and eventually the whole thing would collapse around them, taking decades to recover naturally.
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 our customers and implement new features based on their requests because it helps us grow our business and gives them less reason to go to another solution.
These things go on to become critical parts of the business, with years of data stored in them. Then they break.
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.
Having worked in a large IT department in the past, I can tell you that it's not uncommon for them to horde data as a means of protecting their jobs. I once worked on a project where we offloaded the data from our IBM mainframe onto a PC and manipulated it there, and we got way better results. The only one who stood to lose was the guy in the IT department who was trying to rewrite Excel on the IBM system.
Sadly, many IT departments have earned themselves a reputation of caring more about their own skin than that of their fellow employees. If you don't see them as your customer then you're doomed to failure because few IT departments are revenue generators. For what it's worth, I don't disagree with your point about managing data or wanting to keep the system alive. As a responsible engineer you should definitely point out the pitfalls. But these are your customers, and you ulitmately have to do things the way that they want. I guarantee that if you follow this path that everyone will be happier.
If you don't want crime to pay, let the government run it.