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:
A project is generally defined by the following criteria:
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.
Between projects and daily work lies this no man’s land called service requests, which can be categorized as follows:
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.
It is important that banks acknowledge the problem and the conundrum. Here are three suggestions on ways to begin the conversation:
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.