Amidst technological advancements, we are literally living in the information age, and the IT sector is increasingly present in large, medium, and even small corporations. And regardless of the economic climate, the sector plays a very important role within companies.
That said, it is clear that the IT department cannot be just a black box that keeps the corporation running; it needs to be managed, regardless of whether it is part of the company’s core business or acts as a support function. As the saying goes, “you cannot manage what you do not measure,” or alternatively, what you do not measure, you manage arbitrarily.
In today’s post, we will talk about IT metrics so that you know how to measure your performance and what to do when making decisions. Check it out!
Best Practices
The good news is that best practices regarding IT processes already exist in the market, and consequently, so do some metrics to understand them. The idea is simple: the goal is for you to view and analyze some charts and be sure that things are going well or that action needs to be taken.
But how do you do that? Well, the truth is there is no ready-made recipe, which is why they are called best practices. And you don’t necessarily need to implement all of them. If you are familiar with ITIL, BSC, or Prince2, you will already be familiar with what we will discuss next, but if not, you are welcome to be introduced to the subject.
First Steps
Arriving at a set of reliable charts in a results presentation meeting is laborious and requires investment. That is the first point, because measuring costs money. In some cases, you may already have all the necessary data, but in others, process and tool adaptations are required to start collecting the correct information.
It is necessary to define objectives, goals, data collection methods, and most importantly, there must be individuals responsible for measuring and presenting the data, regardless of whether it is good or not. Define a time period for these results to be presented to you—typically 1 month, but again, this is not a strict rule. Extreme cases require more frequent monitoring (weekly), and calm cases can be extended to bimonthly or quarterly.
Objectives, Goals, and Indicators
An objective is where and when you intend to arrive, and it must have a deadline. There is a methodology for defining objectives called SMART. Its literal meaning is: Specific, Measurable, Attainable, Relevant, and Time-bound.
Example: increase the customer satisfaction rate to 90%, measured through a survey on each ticket, within 1 year. It is ideal to have both short-term and long-term objectives.
- S: customer satisfaction rate;
- M: measured through a survey upon ticket closure;
- A: if you already have an 80% or 70% satisfaction rate, it is an attainable objective;
- R: customer satisfaction decreases the cancellation rate, so it is relevant;
- T: in 1 year.
Objectives are broken down into goals, which help you evaluate the halfway points. They are smaller measurements that, when tracked, help you reach the objective. When missed, you know you need to take action; when beaten, it generally means things are going well.
Examples:
- Increase customer satisfaction by 2% per month;
- Audit 100% of tickets with a poor satisfaction level;
- Increase server availability by 0.05%;
- Decrease the bug rate per release by 5%.
Indicators are what will tell you the situation at a glance, usually based on a range of values. Good, medium, and bad values are generally defined for each goal. When plotted on a chart along with the measurements, this quickly tells you whether things are going well or not.
Examples:
- If the goal is a 2% increase, 2% and above is a good range;
- Between 2% and 1% is a medium range, which requires mild attention;
- Below 1% is a critical range and requires attention, otherwise the objective will be far from being met.
With objectives, goals, indicators, and responsibilities defined, the work of measurement and monitoring begins, which is the icing on the cake. Stay alert to strategy changes, update objectives, and communicate with those responsible—don’t let them waste time measuring data that will no longer be used.
With the concepts defined, the particularities of each area within the IT sector will be addressed to serve as a basis and suggestion for your objectives and goals.
Development
In the software development area, pay attention to release delivery deadlines and the number of critical bugs per delivery. Knowing that your deadlines are being met and that the critical bug index is low or zero is a good sign. Start by measuring in the first months and then develop your objectives.
Examples of metrics:
- Versions released on time;
- Number of bugs per released version;
- Number of critical bugs per released version;
- Hours to fix a bug;
- Hours to fix critical bugs;
- Number of *release candidates per released version.
*Closed versions sent to the quality assurance sector for approval.
Quality Assurance
The function of a quality assurance sector is to try its utmost to prevent software from being released with defects. There can be various types of defects, called bugs, such as something simple that does not work, a critical defect that prevents the use of the software, usability issues, among others.
Examples of metrics:
- Bugs identified per release candidate;
- Critical bugs identified per release candidate;
- Bugs reported in published versions;
- Critical bugs in published versions;
- Ratio of testing hours to development hours;
Service Desk
As the name implies, it is the service counter. It is the common way to request IT services, whether for repairs or new installations. It is very important to define which services are available and their SLAs (Service Level Agreements). Each service can have different characteristics that together form an SLA. The main ones are response time and resolution time.
Response time and resolution time are usually counted in business hours, but can also be counted in calendar days. Response time is super important to keep the customer informed with managed expectations—meaning they know the company is aware of the request, or ticket, and that service will be performed within a certain timeframe.
Examples of metrics:
- Index of tickets closed within the SLA;
- Average hours per ticket;
- Average cost per ticket;
- Average tickets handled per agent;
- Average idle time per agent.
Remember that this is a sector where idleness can occur, but it is necessary if you want to be prepared for peak service times. Monitor them frequently and determine an acceptable value.
During a period of idleness, you can define secondary tasks so that problems are resolved proactively, such as writing suggestions for other sectors, for example.
Infrastructure
This sector is responsible for keeping computer systems running, whether they are computers, printers, servers, routers, telephone exchanges, among others. It also plays a crucial role in expansions, capacity management, and disaster management. Much of the labor is spent on measurements and configuration of automated alerts.
Examples of metrics:
- Service uptime (internet link uptime, e-mail server uptime);
- Service capacity (users per server, disk usage on the backup server, etc.);
- Number of service failures (how many times the link dropped or a service needed to be restarted).
It may seem simple, but it has a major influence on the corporation. A well-planned infrastructure can tell you in advance whether the e-mail server needs more space, if the ERP server needs more processing power, or if the database server needs improved input/output capacity.
These studies and plans can prevent the company from stopping operations due to a simple incident that could have been foreseen.
