The second important people issue to address after acquiring executive support is organizing your IT infrastructure for optimal efficiency and effectiveness of systems management processes. This chapter presents several alternative scenarios for structuring the various groups that comprise an infrastructure. If an infrastructure is organized improperly, it can lead to stifling inaction between departments. We begin by discussing why IT departments need to evolve their organizational structures to succeed; then we examine three factors used in determining these structures. We go on to propose alternative organizational structures for several common scenarios within an IT infrastructure.

We next develop a table of desired attributes for the eventual owner of each of the 12 system management processes. The intent is to provide a technique that any infrastructure manager can use to identify those attributes most desirable for each process. This methodology also shows how some traits may compliment or conflict with others should a process owner assume responsibility for more than one process at a time. Identifying the optimal attributes for each process owner can then become a factor in organizing the overall infrastructure.

Few employees enjoy departmental restructuring, and IT professionals are no exception. Although IT professionals are involved in one of the most rapidly changing technical industries, they still tend to be creatures of habit that, like everyone else, prefer stable and unchanging environments. Newly assigned executives and managers are notorious for proposing a partial or total reorganization of their entire department as one of their first official acts.

But, in the case of IT, restructuring is often necessary to support company growth, increased customer demand, changing business requirements, acquisitions, mergers, buyouts, or other industry changes. The question then becomes: on which factors should we base the restructuring of IT organizations, particularly infrastructures? In my experience there are three key factors on which to base these decisions: departmental responsibilities, planning orientation, and infrastructure processes. These factors tend to follow the normal evolution of an IT organization from company start-up to full corporate maturity.

For example, most start-up companies initially structure their IT departments with a very basic organization such as that shown in Figure 2-1. As the company grows and IT begins expanding its services, an administrative department is added to the base structure as shown in Figure 2-2. The administrative department is responsible for billing, invoices, asset management, procurement, human resources, and other tactically oriented support activities. During a corporation’s early building years, IT usually structures its organization by departmental responsibilities. As the departmental responsibilities in each of the three groups reporting to the CIO continue to grow, they will likely evolve into an organization similar to that shown in Figure 2-3. The applications department is split out between application development and application maintenance. The infrastructure department is organized between technical and network services and computer operations. The administration department has added planning to its charter of responsibilities. This is a key event—it marks the first formal initiation of a planning responsibility within IT, although much of its early emphasis is on tactical, short-term planning.

Figure 2-1. Basic IT Organization

Figure 2-2. Basic IT Organization with Administration

Figure 2-3. IT Organization with Dual Management Levels

As the company and the IT organization both continue to grow, the planning orientation within the IT group gradually shifts from that of tactical to strategic planning.

Eventually, all strategic planning activities can be centralized in a separate department. Over time this department will likely subdivide into two groups along the lines of business requirements planning and IT architecture planning. The ongoing growth of the company and its customers would cause the applications, infrastructure, and administration departments to similarly subdivide into dedicated groups. This further evolution of the IT organization is shown in Figure 2-4. A final modification to the IT organizational structure is the alignment of the applications areas along business units as shown in Figure 2-5. The intent of this increasingly popular refinement is to foster greater empathy between end-users and developers, as well as to increase their understanding of user requirements. At this stage of a company’s maturity, the IT organizational structure is based on the two factors of departmental responsibilities as well as planning orientation. A third factor that influences IT departmental design is how the responsibility for infrastructure processes is integrated into the organizational structure. We will examine key elements of this design in the next several sections.

Figure 2-4. IT Organization with Three Management Levels

Figure 2-5. IT OrganizationThree Management Levels with Business Units

There are various ways to organize an infrastructure, but there is no single structure that applies optimally to all situations. This is due, in part, to factors such as size, maturity, and orientation of a firm and its IT organization. These factors vary widely from company to company and directly influence how best to design the IT infrastructure.

Where some enterprises may combine the voice and data network groups, others may keep them totally separate. Some firms incorporate IT-wide functions such as security, planning, quality assurance, procurement, and asset management directly into the infrastructure organization; others keep these functions outside of the infrastructure.

Locating Departments in the Infrastructure

Sometimes the organizational position of a department can play an important role in distinguishing a world-class infrastructure from a mediocre one. Four departments where this is particularly the case are the service desk, database administration, network operations, and systems management.

Alternative Locations for the Service Desk

The proper location of the service desk is critical to the success of almost any IT infrastructure. There are many reasons for this. Paramount among these is that the level 1 service desk is the first encounter most users have with an IT organization. Placing the service desk higher in the organization or merging it with other service desks can increase its effectiveness, visibility, and stature. The initial impression that customers form when they first dial the service desk number is often long lasting. Service desk specialists refer to this critical interaction as the moment of truth: the point at which customers form their initial, and—in the case of poor encounters—often irreversible opinions about the quality of IT services. The number of rings before answering, the setup of the menu system, and especially the attitude of the service desk agent responding to the caller are all factors that influence a user’s perception of the effectiveness of a service desk. The following lists in order of preference 10 things users want when they call a service desk.

1. Answer incoming calls within two rings.
2. Whenever possible, a service desk agent answers the call; users don’t want an automated telephone menu to select from.
3. If you must use automated telephone menus, design them to be as simple to understand and use as possible.
4. Sequence most commonly used automated telephone menu items first.
5. Allow for the bypass of some or all automated telephone menu items.
6. Calculate and report to callers average hold times in real time.
7. Practice good telephone etiquette by being polite, patient, courteous, and helpful to callers.
8. When handing a call off to level 2 support, give the caller a reliable time estimate for follow-up and resolution.
9. Follow up with level 2 support to ensure the problem is being worked.
10. Follow up with callers to ensure problems are resolved to their satisfaction.

Another reason the location of the service desk is so important is that it defines to what degree multiple service desks may eventually integrate into fewer service desks or into one fully integrated service desk usually referred to as a Customer Service Center (CSC). During periods of initial growth, many IT organizations increase the number of service desks in response to expanding services and a growing user base. Several clients of mine would institute a new service desk number whenever they implemented a new, major application. Eventually, a large number of service desks—or service desk numbers—becomes unwieldy and unmanageable. Sooner or later, most shops realize that a consolidated service desk is the most efficient way to structure a customer service department. Many shops today fold their desktop support unit into the customer services department as a peer to the service desk. This configuration often facilitates handing off of desktop problems from the service desk directly to desktop support. The organization of this type of infrastructure is shown in Figure 2-6.

Figure 2-6. IT Organization Highlighting Service Desk

Real Life Experience—Where Service is its Middle Name

One of my prior clients had no less than seven service desks: applications, operations, desktop support, technical services, database administration, data network services, and voice network services. The client asked me to assess the feasibility of integrating some, if not all, of the multiple help desks into a much smaller quantity. After assembling a cross-functional team, I worked with team members to design and implement a single, totally integrated help desk, or customer service center (CSC). Much discussion centered on where to locate this new centralized service desk. Some thought it best to have it outside of the infrastructure, or to outsource it, but the majority saw there were more benefits in regard to control, staffing, and measurement by keeping it within the infrastructure.

Some of the team members suggested that it go under computer operations in the structure. The strongest argument for this alternative was that computer operations was the only other group at the time being staffed 24/7 and this was the direction we wanted to take the CSC. But most of the calls coming into the CSC were desktop oriented rather than computer operations oriented. In the end we elected to locate the CSC of the infrastructure as a peer to the desktop support department. A major advantage of this configuration was that it put the level 1 (CSC) and level 2 (desktop support) support groups both in the same organization. This facilitated handoffs between levels 1 and 2, drastically cut down on the finger pointing between these two groups, and held each of them to higher levels of accountability.

Alternative Locations for Database Administration

Many IT shops locate their database administration group in the applications development department. The argument here is that the structure and design of the database is more closely aligned to the requirements of the users with whom the applications group works directly. But once the database is designed, most of the ongoing maintenance involves performance and tuning issues; these issues are more closely aligned with the technical services group in the infrastructure.

Some IT organizations have the database administration group reporting directly to the head of the infrastructure group, but I have seen this work successfully only when the database unit is unusually large and most all mission-critical applications are running on sophisticated databases. Another alternative I have seen work well with large database administration groups is to put the architecture portion of the group, which is primarily strategic and user oriented, in the applications development group, and to put the administration portion, which is primarily tactical and technically oriented, in the infrastructure’s technical services group. See Figure 2-7 for an example of database administration location.

Figure 2-7. IT Organization Highlighting Database Administration

Alternative Locations for Network Operations

To many it would seem obvious that the network operations group belongs in the network services department. After all, both groups are involved with providing reliable, responsive, real-time network services. It makes perfect sense to initiate this type of network organization during the start-up of an IT department. But as the network operations group grows, and particularly as network and computer operations assume critical 24/7 responsibilities, a compelling case can be made to have network operations report to computer operations. Both groups have around-the-clock monitoring and troubleshooting responsibilities, both can benefit technically from cross-training each other, and both could give each other more backup support. I recommend that IT organizations with mature infrastructures locate their network operations group within computer operations (see Figure 2-8).

Figure 2-8. IT Organization Highlighting Network Operations

Alternative Locations for Systems Management

The existence and location of a systems management group is one of the key characteristics that make an infrastructure world class. Many shops do not include such a dedicated process group within their infrastructure, but those that do usually benefit from more effective management of their key processes. The systems management group is a separate department solely responsible for those infrastructure processes determined to be most critical to a particular IT environment. At a minimum, these processes include change management, problem management, configuration management, and production acceptance. Depending on the maturity and orientation of the infrastructure, additional systems management processes—such as capacity management, storage management, security, and disaster recovery—may be a part of this department.

Real Life Experience—Mirror, Mirror On the Wall

One of my responsibilities at a major defense contractor was to upgrade the quality of service on the IT help desk. Telephone etiquette by the call takers needed improvement, so I brought in a highly-regarded company that specialized in this type of training. The instructors were very helpful and within weeks we were all enjoying numerous accolades on the quality of our help desk personnel.

One of the methods these trainers used to invoke empathy with callers sounded a bit peculiar but ended up being extremely effective. Their technique involved presenting each call-taker with a facial mirror that they were to look at while answering the phone. On the bottom of the mirror was the inscription: What You See Is What They Hear. A few thought it sounded a bit lame, but in reality it totally changed the tone and demeanor of the call takers as they answered the phones. The expressions reflected back to them in the facial mirror completely mirrored the mood of their voice. They quickly realized the more pleasant they looked, the more pleasant they sounded.

This department usually reports to one of three infrastructure groups, depending on the processes receiving the most emphasis. When change management or production acceptance is the key process, this group often reports to computer operations. In a traditional mainframe environment, this department would have been called production support and could have included batch scheduling, batch processing, and output processing. When problem management is the key process, this group usually reports to the customer services or help desk department. In a world-class infrastructure, all of the key processes are managed out of a single systems management group that reports directly to the head of the infrastructure. This arrangement gives systems management the visibility and executive support needed to emphasize integrated process management. This optimal organization scheme is shown in Figure 2-9.

Figure 2-9. IT Organization Highlighting Systems Management

This chapter covered the second important people issue of organizing an infrastructure for optimal systems management. We began with a look at how an IT environment evolves and matures from a basic reporting structure into a more expansive, sophisticated organization. We next identified three key factors by which infrastructures can be organized: departmental responsibilities, planning orientation, and systems management processes.

We then discussed alternative locations of four departments that greatly influence the effectiveness of an infrastructure. These departments are the help desk, database administration, network operations, and systems management. Finally, we listed the key attributes of process owners for each of the 12 systems management disciplines.