Managers, Metrics and Misanthropy.

When I was a young and naive lad I had firmly set my sights on becoming a project manager. It seemed like a great place to aim towards, the money appeared to be good and you’re not bound to one industry so there’s no end of jobs and new opportunities. I even managed to convince two groups of university students to make me their project manager, with one of them garnering a mild success with the other failing horribly (which I will admit was pretty much all my fault). Still this didn’t deter me and I continued to pursue a career as a project manager, working my way up from low level IT work in the hopes I could make the jump into projects sometime in the future.

Roll forward a couple years and I found myself working for Unisys as part of the outsourcing arrangement with the Department of Immigration and Citizenship here in Canberra. It was a good work environment and I quickly improved my skills over the first 6 months or so. I even thought I had the skills to take a shot at one of the specialist positions, something that I hoped would lead me onto more project work. Talking to the current specialists I was led to believe it was a very client facing position, and I marketed myself as someone who was capable of managing client relationships well and proving to be a valuable project resources. I didn’t get the position however they did offer me a role as a technical lead in the new projects section they were creating, something which sounded pretty cool at the time. Eventually it turned out that this position was really a junior project manager role, and for the first time in a long while I was put in charge of projects. I was in for an awakening of sorts, since the corporate world was nothing like the academic.

My first few months in the position started off well. Our section consisted of 2 other people who were in positions just like me. Our focus was small projects that wouldn’t require the involvement of the solutions architect and could be resourced internally. Most of these were IT projects that weren’t covered in the out-sourcing contract, something which I’ve blogged about previously. We were basically a pure profit centre since all of us were hired as system administrators (fully paid for by DIAC) and were moved to the projects team due to them being able meet SLAs without us. I got to work on some pretty cool projects there with my favourite being the deployment of digital fingerprint scanners and cameras to the detention centres in Australia. The house of cards started to come tumbling down when the higher ups needed a “clearer view” of what we were doing and of course bungled the whole thing.

Since we had come from the administrators team we still used the majority of their systems for all of our daily activities. Requests for new projects would come through the same incident management system and this was the first place management decided to look for to derive some metrics. The problem here was that a typical project can’t be judged under the same SLA as an incident, since one of them is a problem that needs to be resolved ASAP and the other could stretch out over many months depending on the scope. We copped a fair beating over the way the tickets were being handled, so we fought back saying the system was inadequate for accurately tracking our progress. This led to a lengthy battle between us and the Projects Management Office (which at the time was technically the Asset Management area) as they had promised us as system that would allow them to get the metrics they desired. We eventually got our way by not going through the “proper channels” (we called a meeting with them directly without involving our managers) and got a system in place. This happened a few weeks before I left Unisys, and was still suffering from teething problems when I left.

My short time as a project manager taught me many things. The first was that I never wanted to be a project manager ever again. Most of my time was spent either chasing clients for money or asking them whether or not they actually wanted the project they asked for. Also project managers should never be taken from a group of people they will be managing as they need to be at least 1 step removed to avoid any contention issues. There’s nothing more awkward than trying to force your friends or former colleagues to do some work, something I encountered a few times.

The second, and probable one of the most valuable lessons, was that you have to be careful in how you define and apply metrics to anything as improper use of them will skew your vision of what is really happening. One of the often use metrics that I despise is the time taken to close a call when on a help desk. The poor operators were pressured into closing their calls quickly which usually meant that if the problem wasn’t solved there would be a severe lack of information, transferring the load from the call centre to the more costly second level support teams. Closing calls quickly is great and all, but what they what they were really doing is costing the company more to get the same outcome.

It was all summed up pretty succinctly for me in this one quote I came across on Slashdot:

Management gets the behaviour that it rewards, not necessarily the behaviour that it pretends to ask for.

Metrics are supposed to encourage people to achieve goals that align with the company’s vision. However they more often than not reward people for doing something completely different and that’s where the problem lies. I guess it all comes from that culture of wanting to boil everything down to a nice chart for the higher ups, but that’s a story for another day.

2 Comments

Leave a Comment
  1. Heh, I was reading this same thread yesterday. The common theme to come out of it appeared to be the same as Futurama “When you do things right, people won’t be sure you’ve done anything at all”. Because most work in a good IT environment is keeping things stable.

  2. So true, I loved how many of them proposed metrics for things that couldn’t be measured but were things that you’d really need to judge the success of an IT department properly. The best one was “number of calls that were never made”. If only we could measure the amount of calls that were saved, you’d really know how effective a solution you put in was.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.