My IT Department – Why So Much Harder to Manage?

 

My IT Department – Why So Much Harder to Manage Than the Rest?

In the last 5 years PCS has evolved from an IT consultancy to an IT support organization, relying on our people, processes, and controls to achieve our performance objectives. Our focus on service level improvements has, at times, been revealing about how IT personnel prefer to function. Today, I wanted to share a little bit of what we have been learning in the hopes that it can help you continue to improve the usefulness and efficiency of your IT systems.

So, what’s different about your IT department than, say, your Human Resources, Sales, or Finance departments?

If You’re Not Measuring It, You’re Not Managing It
If you are a business executive, you may not be an expert in any of those other departments. However, when circumstances require you to do so, you spend a week or two in and around those departments and get up to speed. You observe the inputs, the outputs, and the performance metrics. Then, you identify performance gaps and inspire new (or revive forsaken) departmental efficiencies. In so doing, you make your staff more accountable for their individual performance levels. Why then, do you not feel that your occasional foray into the IT department seems to harvest similar results?

To measure performance a company requires the use of statistical evidence to determine progress towards that company’s objectives. As it relates to the IT department, most small and mid-sized business executives have trouble setting performance objectives, as they have little way of knowing how much time various technical initiatives and/or tasks ought to take. So why bother measuring performance at all?

Analysts vs. Administrators
Of course, some distinction needs to be made to isolate this performance evaluation challenge. Speaking in broad terms, IT staff of small to mid-sized companies can be broken down into two categories: Analysts and Administrators. It should be noted that in many smaller companies these two roles are embodied within a single employee. Analysts often succeed within such-sized companies, as their role, objectives, and performance are transparent to others within their organizations. Whether independently or at the request of company leadership, Analysts study and make changes to front end systems, process workflows, and managerial reports (all of which are used on a regular basis by managers and co-workers alike). To determine the worth of those improvements a budget of time and resources is usually approved by the company executive in charge of IT. If the Analyst can accomplish those improvements within designated time and resource budget, then evaluating the Analyst’s performance is a cinch. By comparison, the role of IT Administrators often seems opaque.

As setting concrete objectives seems elusive, in my experience, most management teams evaluate their Administrator’s performance based upon a combination of computer systems stability, ad hoc surveying of end users’ satisfaction, and plain, old gut feeling. This informal approach is due to the fact that to truly understand the goings-on of an Administrator, one must him/herself be technical enough to understand those activities. While true, some Administrators can work effectively without technical supervision, more often individual performance suffers without such technical oversight.

The trouble is occasionally perpetuated if Administrators slip into professional isolation. If Administrators do not seek (or are not allowed to seek) access to technical mentors, training, and a technical support community, the continuity of their education is broken (which is particularly dangerous in a field that changes by the minute). The result can often lead to any even sharper decline to his or her contributions to the company’s overall performance.

Ok, If I Need to Measure to Manage, What Should I Begin Measuring?
Time is of the essence. Aside from hardware and software purchases (which typically receive a more than sufficient scrutiny from executives) time must be measured in order to set objectives and evaluate performance. It often helps to think of time in financial terms: the amount of company payroll dollars being invested into a specific task or initiative.

To be successful, unmeasured work must be minimized. Additionally, discrete entries should be opened and tracked for each IT task and/or initiative, so that time can be recorded against them.

Ideas for Classification
The organization can establish a baseline for the amount of resources currently being expended in proactive tasks vs. reactive tasks vs. IT initiatives by coding each record appropriately. Here are some ideas for how to do so:

1. Proactive Tasks, examples include:

►Preventative Maintenance
►Physical Inspections
►Applying Updates
►Configuring Monitoring Sets
►Verifying Backup Jobs
►Checking Log Files

2. Reactive Tasks, examples include:

►Responding to service degradations or outages
►Responding to end users’ requests for support

3. Initiatives examples include:

►Project Planning
i. Evaluating various hardware/software
ii. Budgeting
iii. Training on new technology

►Installations
i. Workstations / Devices
ii. Applications, Servers, Network Gear
iii. Integrating Data Services

Ideas for Reports
1. Percentage of time spent in proactive vs. reactive vs. IT initiatives
2. Time spent on IT initiative x hourly payroll + hardware/software expense = Complete Project Implementation Cost
3. Report on department by department – How much support does each department require?
4. Report on user by user – How much support does each user require?
5. Report on application by application – How much support does this application require?
6. Report on average quantity of open tickets
7. Report on average response time
8. Report on average resolution time

Potential Results
1. Realign IT priorities to that of the company’s strategic development
2. Drive higher utilization of IT personnel
3. Discover opportunity for automation to reduce manual effort costs
4. Prioritize future IT investments based upon costs of supporting existing systems
5. Validate (or disprove) any need for additional IT support resources