Metrics, metrics and more metrics

Standard

IT always feels a bit behind the corporate 8-ball when it comes to justifying costs.  There’s two main factors for this – the first is that for almost all firms, IT represents the biggest pure overhead money suck (behind labor), with usually zero net income to show for it.  Second, IT workers tend to make more money that other support group functionaries, from entry level to skilled labor.

So for 99% of firms, when the c-levels look at the balance sheets, the IT spend is just seen as a painful cost of doing business, with it appearing a bit like the Pentagon’s Black Ops budget – money going in without a good understanding of *what it all means*.

None of that is going to change anytime soon.  But with Architects and Engineers – who live and die by exact hour calculations, meticulous details, and precise metrics regarding WIP and profitability – it’s an uncomfortable state.  And the default reaction is to try and get IT metrics through a ticketing system.

There’s a bit of built-in conflict here; never, ever do the execs want to force users to open a ticket to get help – but at the same time, they want to see exactly how busy IT is – how responsive it is, how many tickets we did this year compared to last, and more importantly, do we really need that tech in Buffalo?

While this makes perfect sense on the surface, for Architects and Engineers, this is a trap.  And here’s why.

1)  It is not the statistic you should be caring about.  It is very possible that your team does 1000 tickets a year, and the staff hates IT.  You can do 900 tickets a year, and the staff loves IT.  What is it you really want?  Do you want IT to be perceived as responsive, supportive, with excellent customer service?  If so, the number of tickets opened/closed will tell you absolutely nothing in that regard.  What will?  Customer surveys, annually/biannual/quarterly.  Identify what the users think you’re doing right/doing wrong, and adjust accordingly.

2) Your IT staff will focus less on customer service, and more on ticket creation/closing.  Once IT realizes that the metric leadership cares about is tickets, *that* becomes their focus.  User wants a mouse? Ticket.  Forgot the wifi password? Ticket.  Is it ridiculous to imagine that if a tech knows they’re “short” that month on tickets, that they create some?  We all know how police work with their ticket quotas.  Is that really what you want IT focused on?

3) It’s a slippery slope.  The next logical progression to this becomes the “you need to open a ticket” comment.  The phrase users hate hearing.  Once ticketing becomes the be-all, end-all, however, the mandatory ticket comment isn’t far behind, either by de facto or de jure.

And that’s not for design firms.  Architects and Engineers are high-touch professions.  You’re used to getting the same level of service you provide to your clients in turn.  That means that the IT guy is sitting out on the floor with everyone else and not in a call center in India, which would be a hell of a lot cheaper.  When you’re on a deadline and can’t save a file, you don’t want to talk to “Rick in Bangalore”, you want to talk to a guy you know, and you sure don’t want to have to open a ticket to talk to him.

Tickets have their place.  In very large firms, when you have a team or staff who never leave their cubicle, whose only task is to churn through ticket after ticket remotely supporting users, it can help.  But that just doesn’t exist in firms under several thousand staff.  And it certainly isn’t conducive to providing the highest levels of customer service.

It’s easy to understand the desire to try and tie down some aspects of the ethereal IT spending pit.  But it needs to happen in reverse.  What do you truly want from your IT organization?  And is that goal measured by how leadership and staff feel about IT, or about whether Sally opens 8 vs. 10 tickets in a day?

Advertisements