IT usually runs lean for a reason

Many IT departments spend a huge percentage of their times reacting to problems and simply keeping the lights on. The reason? Because you (and your IT team) aren’t effectively communicating the value you are bringing and/or could bring to the business.

And because you’re not doing that, the business is running your team as lean as they possibly can. Because, as a business, why should I hire another IT person when I can’t see the value you bring me?

What’s in it for you?

In a nutshell, showing the business the value the IT team are bringing could unlock many benefits, including:

  1. Kudos from management now see you as valuable members of the organisation, and not a cost “sink”
  2. A better relationship with the business; who now consider IT when starting projects.
  3. Enable management to justify additional resources (e.g. people, or money for training)
  4. Salary increase/promotion

How can you demonstrate value?

  1. Become more intimate with the business (often referred to as a Business Partner)
  2. Demonstrate and show the value that the business partnership, and IT, is bringing to the organisation.

I covered step 1 in the linked blog post above. This post will focus on step 2.

Out with the tickets, in with the value

Some IT teams measure performance based on number of IT tickets handled. While it’s a useful barometer and can help show trends, it doesn’t show value, so we need to focus on what does.

Assuming that you’re now meeting regularly with key employees and departments, you should have a good grasp on business needs, wants, and overall priorities.

Finding the value

Value is everywhere, you just have to measure it. You can capture and measure it in terms of:

Money:

  • Up-front costs – Capital expenditure (CapEx)
    • IT equipment
  • Running costs – Operational expenditure (OpEx)
    • Power, cooling, floor space (rent), salaries

Efficiency (Hours saved):

  • Improving the efficiency with which an employee or team acheive a task or workflow (could be IT itself or another department)

Satisfaction:

  • Improvements in IT service satisfaction are important to the business. You should care that you’re offering a good service. Capture it, measure it. Ask for and gather feedback in your IT discussions that you have with your departments.

IT support volumes:

  • Reduction in IT tickets related to the project (for example, implementing solution has reduced tickets about previous solution by n number or y percent.)

Enabling the business/meeting business needs:

  • There’s value in enabling the business.
    • It sounds silly, but keeping an email server running effectively is a business enabler. It may not be practical to show how much money it makes or saves, but it forms a key part of what businesses *must* have in order to operate, and so it is valuable.
    • Does the Business need a Disaster Recovery plan? Have you got one of those? Does it work? If yes, then you’re adding value.

Measuring and reporting value

Hopefully the items above provide some good hints to where you can define the value.

To measure value, you need to define it and then measure the delta between the baseline (how things were), with how they are.

Below, I’ll try to cover some examples which show value.

Example 1: Improving employee workflows (Efficiency)

The entire finance team have to go through a process daily. While it is semi-automated, there’s still room for human error and it’s very tedious. The process often breaks halfway through, and this results in IT needing to be called roughly once a week to assist. After this was raised with IT in a regular meeting, IT analysed the workflow and created a fully automated solution which reduced the time it takes to action the process by 10 minutes each day, and reduced the failure rate to only one support call every six months.

Where’s the value?

  1. Hours saved. Time is money. If your work saves 10 employees in a team 10 minutes each per day, over 200 working days a year, that’s 332 hours you’ve saved the team. This can be measured in money, if you figure out rough costs of an employee’s time (usually gross salary divided by working hours in a year)
  2. The Team is more productive, and can focus on adding further value instead of working on menial tasks (you just enabled the business).
  3. Less support calls. Support calls were reduced from around 50 calls a year, to only 2. That’s a 96% reduction in IT calls!

Example 2: Reduction in required disk storage space

Your data center is close to capacity, and the company is expecting a tight quarter in sales, but the business still needs storage for files and documents. Thanks to your good relationship with multiple departments, you’ve managed to negotiate and reduce the amount of storage required for the next quarter by 50% by deleting unneeded data and archiving old data to offline storage. In doing so, you’ve also managed to reduce the physical footprint of the additional storage such that it will now fit into the existing data center without requiring expansion (because you need to order less of it).

Where’s the value?

  1. Saved on capital costs. Enterprise-grade file storage systems are expensive, and you’ve halved the amount of storage you need to buy.
  2. Saved on operational costs. It costs money to install, power and cool disk storage systems
  3. Enabled the business to post a healthy quarter result. Because you delayed data center expansion by reducing the amount of storage needed (both capacity of physical size) and thus the Data Center didn’t need to be expanded to fit the new storage.

How do you measure your team’s value?

I’ve only covered a few of the many ways that we as IT people can measure value. I’d love to hear how you and your IT teams measure the value you bring to the business! 🙂

Written by Phil Wiffen

Phil is an IT Professional working in Cambridge, England. He generally blogs about useful solutions that he comes across in his work/play.

1 Comment

Rob M

Agree that high-level metrics such as those tracking tickets opened/close/MTTR are pointless, it’s equivalent to tracking the number of commits in development and give anywhere near a true value of effort or individual work-ethic.

Tracking tickets becomes slightly more useful if the internal issue tracking system is (a) architected correctly with correct specific categories down to the minutae of detail which requires significant planning and foresight and (b) used correctly. You only get out what you put in.

In most organisations flippant requests such as “we’re too busy”, “we need more people” fall on deaf ears. I have found a better approach is to collect information on the request and put it forward in the form of a proposal that has real-world proof of things slipping through the system and/or the ball being dropped due to lack of resources, whilst verifying that correct process and procedures are in place so that lack thereof cannot be blamed. This gives the powers that be buy-in to the problem, and they’ll be more inclined to actually seek to understand.

Leave a Reply

Your email address will not be published. Required fields are marked *