As banks look at efficiency and expenses and ask what all those people down in the technology dungeon are doing with their time, the conversation about technology staff levels once again raises its head.
Something is happening here. The growing number of jobs with titles like “Project Manager,” “Analyst,” “Specialist,” “Coordinator” and “Liaison” are adding to the discomfort (or frustration) banks already feel about staff additions.
In broad terms, IT groups deal with three types of work:
1. Projects
A project is generally defined by the following criteria:
- A project has a large scope – dollars, time, or both.
- A formal analysis, cost justification, approval, and estimate of time to complete are scrutinized and published.
- The IT Steering Committee or an equivalent group typically determines a project’s priority. A high priority project gets going fast while a low priority goes to the back of the line to languish like a drunken dog.
- The total of projects determines the amount of IT people allocated.
- Staff time is tracked, and these resource requirements are recognized by management.
- Accountability (usually) exists for spending too much time or money.
2. Daily work
At the other end of the spectrum is daily work. Jobs are well defined (e.g. computer operations, network support, PC break/fix). Work is largely recurring, and what’s not is prioritized by the supervisor. Staffing levels are determined by some industry metric (e.g. terminals supported per network FTE), and service levels (e.g. up time, system availability) are fairly understood.
3. Service requests
Between projects and daily work lies this no man’s land called service requests, which can be categorized as follows:
- Service requests are non-routine.
- They are not big enough for any formal scrutiny or write-up.
- There is no real estimate of cost or time required by IT to complete them.
- They are often prioritized by the people receiving them, or their supervisors, based on some ambiguously assigned criteria (I think the top one is who’s yelling most).
- Time spent on these is not tracked or reported.
- They are not generally covered by any service level agreements.
Here’s the thing. Service requests are growing in number like weeds, and the time and focus they require is killing IT staffs.
To add to the issue, service requests are the source of most of the frustration users and managers have with IT. A bank I was at recently refers to service requests as “gotchas” because the IT people know that one of these will get them sometime during the day.
Hasn’t this been an issue in IT forever? The answer is no. So why is it an issue now? For the answer, let’s look at the sheer number of server-based applications that have been purchased and installed in recent years.
Just five years ago, banks ran many applications on mainframes as part of an overall core vendor solution. Other processes were manual and therefore involved no systems. Few applications needed tracking and support.
Now, even in the simplest banks it is easy to count 20-30 discreet systems. In more complicated mid-size banks, there can be 150-200. Lines of business run many of these on PCs or servers. Many are purchased and installed with little or no IT involvement.
Every one of these systems will have 1-2 releases a year that need to be installed and tested. Even if each only took, on average, 1-2 days (which is likely), count the number of days somebody has to be involved with the system. Many have unplanned but necessary patches or fixes. Some report-writing tools may be hard for a line of business to use, so IT is called for help. There may be interfaces to other systems. Following deployment of a new operating system, such as Windows XP, the system requires re-testing. Systems crash. They need to be backed up.
In many banks, some of these systems were custom-written by consultants hired by a line of business. To put it mildly, the finest of programming, testing, and documentation principles are not always employed in these efforts. These systems often require enhancements to beef up security. Or they are growing too big for the database they use. Or they need major re-writes. Or they don’t work on the new version of network software. Or they don’t meet reporting needs, and new ones have to be designed.
Get the picture? Who is getting more and more of the calls about all this? Right – the IT department. Most of the time, they don’t staff correctly for it because there’s no metric or formula to use to do it. This has caused a growing problem for IT managers who are also dealing with users who judge them on how well service level issues are addressed.
Let’s acknowledge some realities about this situation.
- These issues will continue to grow. There are valid business reasons for deploying server applications, and the number of local, server-based systems will increase over time. As will service requests.
- Banks need a way to measure the IT time required to support service requests and allocate staff to do it. This means we somehow have to start counting or listing the work.
- We must not create a bureaucratic mess to accomplish this. The whole point of a service request is that it is, by nature, fast and informal. Creating project-level processes would be like using a howitzer to kill a fly.
It is important that banks acknowledge the problem and the conundrum. Here are three suggestions on ways to begin the conversation:
- Devise a fast and simple way to count these tasks. Some call center/contact systems can accommodate this. Another idea is a simple intranet system that enables support staff to input a call, the caller, what system it involved, and how long it took to resolve it. Four fields.
- Inventory the number of server-based systems in place today and, using past experience, assign a monthly value for required IT support time. Challenge whether IT staff assigned is adequate. Start the conversation about the urgency of issues and how many are critical, “level 1” in nature.
- Assign project status at the right level in terms of money or time required to complete.
This is a topic that won’t go away, and the solution will entail trial and error. The sooner we start, the sooner we can get the Gotchas.
-tr