Staffing

The service desk will use a service management tool and other technical resources to enable it to carry out its tasks and will follow defined processes (especially incident management and request fulfilment). Although these tools and processes are important, the people aspect of the service desk is critical. The interactions with the customers and users require good communication skills in addition to technical knowledge. Knowing the answer is only part of the job; explaining it in terms that users understand is essential.

Recruiting and retaining good service desk staff members is the key to customer satisfaction. This function often acts as an entry level to the other functions, providing staff members with an understanding of all the services, the technology that supports them, and the business impact of failure. This provides an excellent basis for future technical specialization.

Service desk staff members require a mix of technical knowledge and interpersonal skills. The technical knowledge may not be in depth, but it covers all the services provided by the IT service provider. The service desk analyst can be said to know a little about a lot of services rather than a lot about a few.

The ability to correctly prioritize incidents based on business impact and urgency requires that the service desk analyst has a good level of awareness about the business processes. Added to this knowledge is the requirement to be patient, helpful, assertive when dealing with support teams or third parties who are failing to meet targets, well organized, and calm under pressure.

Service desks are organized differently dependent upon the particular requirements of the organization. We cover various service desk structures later in the chapter in the section “Service Desk Organizational Structures.” The skill level required may also vary; the service desk may be tasked with resolving a high proportion (75 percent to 80 percent) of incidents, or it may be limited to logging and escalating them for resolution by another team. Service desks are often outsourced to specialist providers; the decision to do this will be based on the overall IT strategy. If the decision is made to outsource, the third-party supplier’s performance must be monitored and managed closely to ensure that this essential service is being provided to the highest standard.

Role

The provision of a single point of contact is accepted in many industries as being central to good customer service. Without a service desk, users would have to try to identify which IT support team they should approach. This could be confusing for users, leading to a delay in having their issue resolved. Technical staff members would waste time dealing with issues outside their specialist area or issues that could be dealt with by more junior staff members.

Providing a good service desk leads to a number of benefits:

• Increased focus of customer service
• Increased customer satisfaction
• Easier provision of support through the single point of contact
• Faster resolution of incidents and fulfilment of requests at the service desk, without the need for further escalation
• Reduced business impact of failures because of faster resolution
• More effective use of specialist IT staff members
• Accurate data (taken from the service desk tool) regarding the numbers and nature of incidents

Objective

As we have said already, the main objective of the service desk is to provide a single point of contact. The next most important objective is to restore service in the event of a failure. This may not mean a complete resolution of the incident; it may mean instead the provision of a workaround, to enable the user to continue working. Fulfilling a request, resetting a password, or answering a “How do I ….?” query all help the user get back to work as soon as possible.

The service desk also has the following responsibilities:

• Logging all incidents and requests with the appropriate level of detail
• Categorizing incidents and requests for future analysis
• Agreeing on the correct priority with the user based on impact and urgency (utilizing SLAs wherever possible for consistency)
• Investigating, diagnosing, and resolving incidents whenever possible
• Deciding upon the correct support team to escalate the incident to should the service desk be unable to resolve it
• Monitoring progress of the incident by support teams
• Communicating progress to the users
• Confirming closure of resolved incidents with the user
• Owning the incident on behalf of the user to ensure that it is progressed to resolution
• Carrying out surveys to ascertain the level of customer satisfaction

These are covered in more depth in the chapters on the incident (Chapter 34, “Service Operation Processes: Incident and Problem Management”) and request (Chapter 35, “Service Operation Processes: Request Fulfilment”) processes.

Local Service Desk

This option provides a service desk colocated with the users it serves; an organization with three offices would have three local service desks. There are advantages with this approach in that the service desk is local, so it understands the local business priorities. Where the offices are spread across different countries, local service desks provide support in the language of the local users, work in the same time zone, have the same public holidays, and so on. This structure can also be useful when different locations have specialized support needs. The basic principle of a single point of contact is retained because, from the user perspective, they have only one number to call and are unaware of any other desks that may exist.

This is an expensive option because each new office location would require a new service desk too. Each desk needs sufficient staff to allow for annual leave, training, and sickness. At quiet times, there would be several service desk staff members spread across the various desks waiting for calls. There are potential issues with incidents and requests being logged in different languages; this makes incident analysis and problem identification difficult. Sharing knowledge is also more difficult: an incident that could be resolved by one service desk might be escalated by another because the resolution has not been shared between the desks. Resilience may be another issue. With local distributed desks, there may be the option of each desk providing cover for the others, but in reality this may be difficult to achieve.

To overcome these issues, IT management must ensure that information is shared effectively. Procedures need to be put in place to ensure that issues affecting more than one location are managed effectively without duplication of effort, each service desk assuming that another desk is responsible. Figure 39.1 shows the local structure.

Centralized Service Desk

A more common structure for service desks is that of a centralized service desk. In this model, all users contact the same service desk. This has the benefit of providing economies of scale because there is no duplication of provision. Specialist technology, such as intelligent call distribution or an integrated service management tool, may be justified for a centralized service desk but not when implementing this technology across many sites. There are no issues with confusion regarding ownership of major incidents, and knowledge sharing becomes much more straightforward. Offering a service at times of low demand is more cost-effective when only one service desk needs to be staffed.

Staff members on a centralized desk will gain more experience with particular incidents, which a local service desk may encounter only occasionally, leading to an increased ability to resolve these issues immediately. Where the centralized desk is supporting users in many countries, the language issue may be resolved by the following:

• Employing staff members with language skills and using technology to allocate calls requiring support in a particular language to staff members who have that language ability. Staff members would then log the call in the main language.
• Standardizing on one language; callers would need to report incidents in that language, and support would be provided in it. This option depends on the type of organization and whether its users may reasonably be expected to be able to converse in the language.
• Local super users may be required to support users without the necessary language ability and to log calls on their behalf.

To provide support to a global organization, a 24/7 service may be required. Where the resolution requires a physical intervention (unjamming a printer, for example), the service desk would require local support staff who could be assigned calls and be responsible for updating the incident records or could assist in the resolution of an issue at a remote site.

Consideration should also be given to maintaining service continuity because an event that affects a centralized service desk would impact support across the entire organization. A plan to provide the service from another location, possibly using different staff members, in the event of a disaster must be developed and tested in conjunction with IT service continuity management. There should also be plans in place to ensure the service desk’s tool resilience in the event of disruption to the network or a power failure. This centralized structure is shown in Figure 39.2.

Virtual Service Desk

The third organizational option described by ITIL is that of a virtual service desk. This option consists of two or more service desk locations that operate as one desk. Calls and emails are distributed across the staff members as if they were in one centralized location. This ensures that the workload is balanced across all the desks. To the user, the virtual service desk appears as a single entity; the users may be completely unaware that this is not the case in reality. The virtual service desk retains the single point of contact principle.

The considerations we discussed earlier regarding knowledge sharing and clear ownership apply even more in this scenario, as does the need for all calls to be logged immediately. Users will become very frustrated if they call the service desk and explain an issue in detail only to find when they call for a second time that the service desk analyst can find no record of their first call. This is, of course, true for all service desks, but the difficulty of locating a “lost call” is increased in the virtual environment, where team members are not located together.

The ability to route calls to analysts with particular language knowledge or to adopt one language for all users can be considered, as with a centralized desk. Calls must be logged on one common system, using one language, because the next analyst to handle the incident may be in another location.

The virtual service desk structure allows for a variety of ways of working. Many call centers use home-based staff members, who log on to the service desk telephone system and are allocated calls. Extra staff members from other teams can supplement the core service desk staff members at busy times, without the users being aware. Many of us have had the experience of calling a local company, only to have the call answered offshore outside of normal hours or during busy times.

Offshoring support (providing support from another geographical location where staff members’ costs may be lower) can be cost-effective but requires careful management to ensure consistency of service. Managers need to be culturally sensitive because users may become irritated by staff members behaving in a way in which they find unfamiliar.

One benefit of a virtual structure is that it has built-in resilience; should one location go offline because of a major disruption affecting that location, the service would continue with little or no impact.

Figure 39.3 shows the virtual service desk structure.

Follow the Sun

The fourth structure described within ITIL is known as follow the sun. This is a form of virtual service desk, but with this structure, the allocation of calls across the various desks is based on time of day rather than workload.

Follow the sun enables a global organization to provide support around the clock, without needing to employ staff members at night to work on the service desk. A number of service desks will each work standard office hours. The calls will be allocated to whichever desk or desks are open at the time the calls are made. Typically, this might mean a European service desk will handle calls until the end of the European working day, when calls will then be allocated to a desk or desks in North America. When the working day in North America finishes, calls are directed to another desk or desks in the Asia-Pacific region before being directed back to the European desk at the start of the next European working day.

This option is an attractive one for many global organizations, providing 24-hour coverage without the need for shift or on-call payments. The requirements for effective call logging, a centralized database, and a common language for data entry referred to earlier for the virtual structure apply equally here. Procedures for handoff between desks are also required to ensure that the desk that is taking over knows, for example, the status of any major incidents.

To the user, the single point of contact still applies; they have one number to call, no matter who answers it or where the service desk analyst may be located.

Specialized Service Desk Groups

Another possible variant on the previous structures is to provide specialist support for particular services. In this structure, a user may call the usual service desk number and then choose an option depending on the issue they have. Typically, the message would say, “Press 1 if the call is regarding system X, press 2 if it is regarding system Y, or hold for a service desk analyst if your call is in regard to anything else.”

Although this approach can be useful, especially where in-depth knowledge is required to resolve a call, it is not popular with users when it expands to numerous options to choose from followed by yet more options.

There is a danger that the user does not always know what support they need and may choose the wrong option, leading to delay and frustration. For example, a printer may not print because of a hardware fault, a network issue, an application malfunction, or a user error. The user will not know which option to choose.

This specialist support option works best for a small number of complex services that require a level of both business and technical knowledge beyond what can reasonably be expected of a service desk analyst. Another possible reason to use this option is when the service contains confidential data. In this situation, the organization may wish to limit access to a small number of specialist support staff.

Service Desk Single Point of Contact

Building a single point of contact is an important part of the service desk communication. Regardless of the combination of options chosen to fulfil an organization’s overall service desk structure, individual users should be in no doubt about who to contact if they need assistance or where they can access self-help support. A single telephone number (or a single number for each group if separate desks are chosen) should be provided and well publicized, as well as a single email address and a single web service desk contact page.

There are several ways to help publicize the service desk telephone number and email address and make them easily available when users are likely to need them, such as including the service desk telephone number on hardware CI labels attached to the components the user is likely to be calling about and printing service desk contact details on telephones. For PCs and laptops, there could be a customized background or desktop with the service desk contact details together with information such as IP address and OS build number in one corner.

Printing the service desk number on giveaway materials (pens, pencils, mugs, mouse pads, etc.) and prominently placing it on service desk Internet/intranet sites, as well as including it on calling cards or satisfaction survey cards left with users when a desk visit has been necessary are other ways to promote the service desk number. Repeating the details on all correspondence sent to users (together with call reference numbers) and placing the details on notice boards or physical locations that users are likely to regularly visit (entrances, canteens, refreshment areas, etc.) are important ways of maintaining the corporate presence of the service desk.

Service Desk Staffing

An organization must ensure that the correct number of staff are available at any given time to match the demand being placed upon the desk by the business. There is often a variety in the volumes of calls received by the service desk. An organization planning a new desk should attempt to predict the call arrival rate and profile and staff accordingly. Statistical analysis of call arrival rates of the current volumes or similar volumes will provide a good basis for understanding the requirements.

A common pattern of calls will be a peak in the mornings, with maybe another peak later in the day, around the early part of the afternoon. Each organization will be different, but it is common to find that there will be a recurring pattern. Staffing can then be adjusted to meet the demand.

A number of factors should be considered when choosing staffing levels, including customer service expectations and business requirements such as budget and call response times.

Self-help tools and automation of service request handling (e.g., password resets) will also have an impact on staffing levels, as will the size, relative age, design, and complexity of the IT infrastructure and service catalog. For example, staffing may be influenced by the number and type of incidents or the extent of customized software deployed instead of standard off-the-shelf software.

There are clearly some factors that have a direct impact on the staffing levels of the service desk, such as the number of customers and users speaking a different language and the technical skill levels of the staff and the types of calls handled. The duration of time required for call types (e.g., simple queries, specialist application queries, hardware, etc.) and whether or not local or external expertise is required for the volume and types of incidents and service requests are also factors.

Other factors will be the hours the service desk is taking calls, the after-hours support requirements, time zones to be covered, and locations to be supported (particularly if service desk staff also conduct desk-side support, given the travel time between locations). Understanding the pattern of requests (e.g., daily, end of the month) and the service level targets in place (response levels) will also have an impact, as will the type of responses required. There are a variety of contact mechanisms in use: telephone, email/voicemail/video, online chat, texting, and online access/control. The skill levels and the level of training required for staff to support the processes and procedures will identify the requirements for development of the service desk.

These are factors to be considered before making any decision on staffing levels. These factors should also be reflected in the levels of documentation required. Service desks are often victims of their own success because the better the service, the more the business will use it.

A number of tools are available to help determine the appropriate number of staff for the service desk. These workload modeling tools are dependent on detailed local knowledge of the organization, such as call volumes and patterns and service and user profiles. Industry standards suggest 1,000 users equals 104 calls/day, but this may not fit all organizations.

The skill levels for the service desk will be dependent on the nature of the requirements of the business. A range of skill options is possible, starting from a call logging service only, where staff need only very basic technical skills, right through to a technical service desk where the organization’s most technically skilled staff members are used. In the case of the former, there will be a high volume of calls to handle but a low resolution rate, while in the latter case this will be reversed.

The required skills level will often depend on target resolution times (agreed with the business and captured in service level targets), the complexity of the systems supported, and the business budget. There is a strong correlation between response and resolution targets and costs. Generally speaking, the shorter the target times, the higher the cost because more resources are required.

There is no rule about the way a service desk should be set up, but often organizations will start with a call logging approach, with technical skills in second-line and third-line support teams, and build up expertise at the service desk over time. Obviously, if there is an immediate requirement for highly skilled technical support at the first point of contact, this should be provided.

A way of improving the first-line skill set is to consider the physical location of the second- and third-line support teams. Closer proximity will enable and foster information exchange and enable the utilization of the more technical support personnel to provide support and backup for peak periods for the service desk.

However, second-line staff often have duties outside of the service desk, resulting in rosters having to be managed or second-line staff positions being duplicated. In addition, having to deal with routine calls may be demotivating for more experienced staff. A further potential drawback is that the service desk becomes really good at resolving incidents, whereas second-line staff should be focused on removing the root cause of incidents instead.

It is worth noting that although successful problem management will improve service desk performance by providing known error resolutions, in the longer term it may lead to a reduced first-time fix rate at the service desk. This is because, as recurrent faults are permanently fixed, the service desk is dealing with more complex and individual calls. A falling fix rate therefore does not necessarily mean that the service desk service is deteriorating.

Once the required skill levels have been identified, it is important to ensure that personnel with the correct balance of skills are on duty so that consistency is maintained.

Service desks will need necessary ongoing training and awareness programs to cover interpersonal skills, such as telephony, communication, active listening, and customer care skills. Business awareness and specific knowledge of the organization’s business areas, drivers, structure, and priorities are critical for effective support.

Service awareness of all the organization’s key IT services for which support is being provided is also essential for the effective support of the organization. Depending on the level of support provided, some diagnostic skills may be required, and the ability to use support tools and techniques will be important. All service desk staff are required to be trained on new systems and technologies prior to their introduction.

The service desk will need to be aware of the processes and procedures in the IT department, most particularly incident, request, change, and service asset and configuration management, but an overview of all ITSM processes and procedures is also valuable. Another useful skill is typing to ensure quick and accurate entry of incident or service request details.

To ensure that the service desk continues to perform as required, skill requirements and levels should be evaluated periodically and training records maintained. Careful formulation of staffing rotations or schedules should be maintained so that a consistent balance of staff experience and appropriate skill levels are present during all critical operational periods. It is important to have the correct blend of skills available.

Training

It is vital that all service desk staff are adequately trained before they are called upon to staff the service desk. This should include organizational induction and business awareness programs to ensure the staff are conversant with the organization they will support.

When starting on the service desk, new staff should initially “shadow” experienced staff (that is, sit with them and listen in on calls) before starting to take calls themselves with a mentor listening in and able to intervene and provide support where necessary. Mentoring is a useful technique to maintain training as the service desk personnel gain experience, and a mentor can be allocated for each service desk person as they progress through their career.

Service desk staff need training to keep their knowledge up-to-date and stay aware of new developments, services, and technologies. The timing of such events is critical so normal duties are not disrupted.

It is important to invest in the service desk to maintain a professional team. Traditionally, the service desk suffers from a high turnover of staff, but this can be mitigated by having staff progress into the organization rather than taking their knowledge away to a new company.

Staff Retention

It is very important that all IT managers recognize the importance of the service desk and the staff who work on it. High staff turnover is expensive because new staff have to be recruited and trained before they are fully effective. It is one of the common challenges in running a service desk. Any significant loss of staff can be disruptive and lead to inconsistency of service, so efforts should be made to make the service desk an attractive place to work.

Recognition of the importance of the service desk is vital, with reward packages, team-building exercises, and staff rotation to other activities (projects, second-line support, etc.). Good documentation and cross-training can support this approach.

The service desk can often be used as a stepping stone into other, more technical or supervisory/managerial roles. However, care is needed to ensure that proper succession planning takes place so that the desk does not lose key expertise in any area at one time.

Super Users

The introduction of super users throughout the user community to act as liaison points with IT in general and the service desk in particular can be beneficial, particularly for specific application expertise.

Super users can be given some additional training and used as a conduit for communications in both directions. It is important to note that super users should log all calls they deal with and not just those they pass on to IT. They will need access to, and training on how to use, the incident logging tools. This will ensure that valuable history regarding incidents and service quality is not lost.

They can also be used to cascade information from the service desk outward throughout their local user community, which can be useful in disseminating service details to all users very quickly.

It is important to ensure that the super users have the time and interest to perform the role. This will require commitment and support from their management.

Measuring Service Desk Performance

Metrics should be established so that service desk performance can be evaluated at regular intervals. This is important to assess the health, maturity, efficiency, and effectiveness of the service desk and recognize opportunities to improve its operations.

Metrics should not be viewed in isolation, and it is important to remember that metrics may drive behavior, for example isolated measures of call closure may result in poor quality of customer/user satisfaction, because the driver for the support analyst is to close the call, not ensure that the customer is satisfied with the result.

Typical service desk metrics include call-handling statistics and first-line resolution rates. The first-line resolution rate is the figure often quoted by organizations as the primary measure of the service desk’s performance. It’s also used for comparison with the performance of other service desks, but care is needed when making any comparisons to ensure that there is a “like-for-like” comparison in terms of the nature of the support delivered and the technical capability of the desk.

Other service desk metrics include average times to achieve a particular target, for example, the average time to resolve an incident (when resolved at first line).

It may be important to understand the average time to escalate an incident (where first-line resolution is not possible). This will show that the service desk staff are efficient and recognize their limitations, and it will identify where the user will be best served by the escalation of a call to more expert resources.

Service desks are bound by service targets. The user experience of IT is often only based on their contact with the service desk and measured with the service desk service targets. So the percentage of customer or user updates conducted within target times, as defined in SLA targets, may be the only measure on which the users base their perception of the whole IT department.

The average time to review and close a resolved call will demonstrate the efficiency of the service desk in handling their workload.

The number of calls broken down by time of day and day of week, combined with the average call-time metric, is critical in determining the staff required. There are no hard and fast rules about staffing levels for a service desk, so this analysis is vital to understand each organization’s individual requirements.

Further general details on metrics and how they should be used to improve the quality of service is included in ITIL Continual Service Improvement core volume.

Customer/User Satisfaction Surveys

As well as tracking the “hard” measures of the service desk’s performance, it is important to assess “soft” measures. These are expressed by how well the customers and users feel their calls have been answered, whether they feel the service desk operator was courteous and professional, and whether they instilled confidence in the user.

The only successful approach to soft measures is to obtain them from the users themselves. A common method for understanding the service desk issues is through a call-back telephone survey, in which an independent service desk operator or supervisor calls back a small percentage of users shortly after their incident has been resolved to ask their opinion of the support they have received.

This can be done as part of a wider customer/user satisfaction survey covering all of IT, or it can be specifically targeted at the service desk issues alone.

Care should be taken to keep the number of questions to a minimum so that users will have the time to cooperate. Survey questions should be designed so that the user or customer knows what area or topic the questions address and which incident or service they are referring to. To allow adequate comparisons of service over a given time period, the same percentage of calls should be selected in each period, and they should be rigorously carried out despite any other time pressures.

The service desk must act on low satisfaction levels and any feedback received.

Surveys are a complex and specialized area, requiring a good understanding of statistics and survey techniques, but it is not necessary to understand these as part of your studies of the ITIL Service Operation core volume.

Table 39.1 lists some typical examples of surveys.

Service Desk Environment

The environment where the service desk is to be located should be carefully chosen. It is important to remember that the staff will often be expected to remain in a single location for long periods of time, and so, where possible, the facilities should be provided to take the working conditions into consideration.

If the organization can provide a location where the entire function can be positioned with sufficient natural light and overall space to allow adequate desk and storage space and room to move around if necessary, this will make the working environment much more acceptable.

Service desk staff should have easy access to the correct equipment to support their responsibilities, such as consoles, monitoring displays, and message boards to quickly gain a picture of any key operating or service events or issues that may be taking place. Because the service desk is often busy, potentially handling many different conversations at once, a quiet environment with adequate acoustic control so that one telephone conversation is not disrupted by another is essential.

The service desk can be a very stressful place to work, and thoughtful use of space, furniture, and assistive technology can be beneficial. Many organizations have discovered that the provision of pleasant surroundings and comfortable furniture to lighten the mood helps with the management of stress. Consider the use of a separate restroom and refreshment area nearby so that staff can take short breaks when necessary, without being away for too long. Breakout areas that encourage relaxation can be very helpful in maintaining service desk morale.

Placing the service desk at the heart of the department, not hidden away, will encourage collaborative working with second- and third-line colleagues.

Outsourcing the Service Desk

Outsourcing the service desk is a business decision, and the organization is ultimately responsible for the outcomes of the decision. There are some safeguards that are needed to ensure that the outsourced service desk works effectively and efficiently with the organization’s other IT teams and departments and that end-to-end service management control is maintained.

Role

The technical management function has a number of responsibilities:

• It is responsible for managing the IT infrastructure. This would include ensuring that the staff members performing this function have the necessary technical knowledge to design, test, manage, and improve IT services.
• Although we discuss this function under service operation, the function provides appropriately skilled staff members to support the entire lifecycle. Technical management staff members would be involved in drawing up the technical strategy and ensuring that the infrastructure can support the overall service strategy. Technical management staff members would also carry out the technical design of new or changed services and would be involved in planning and implementing their transition to the operational environment.
• Once the service is live, technical management provides technical support, resolving incidents, investigating problems, responding to alerts, and specifying any changes or updates required to have the service operate efficiently. Technical management staff members will identify service improvements and work with the CSI manager to design, test, and implement these improvements.

It is the responsibility of the manager or managers of this function to ensure the correct number of staff members, with the correct skills to carry out the required tasks. Specifying the numbers and skill levels required is discussed as part of the lifecycle stage strategy and detailed as part of the lifecycle stage of service design. Transition tests that the staff members are able to support the service as designed, and CSI identifies any improvements or training requirements. The technical manager must decide whether to employ new staff members with the correct skills, to train existing staff members, or to use short-term contract resources to meet a particular requirement. Larger organizations may have a team of subject-matter experts that can be called upon when required by subsidiary departments, without the need for those skills to be developed across the organization.

Most of the everyday operational support activities will be undertaken by the operations support staff members, but it is the responsibility of technical management, as the experts in the technology, to guide and support the operations staff members.

Objectives

The objectives of technical management are as follows:

• Providing the appropriate technical infrastructure to support the business processes. This should take account of the availability and capacity requirements, providing a stable resilient infrastructure at an affordable cost.
• Planning and designing the technical aspects of any new or changed service.
• Implementing these technical aspects and supporting them in the live environment, using the technical expertise that the function possesses to ensure that any issues that arise are swiftly resolved.

Generic Technical Management Activities

Technical management is involved in two types of activity. This includes activities that are generic to the technical management function as a whole. The other type of activity is linked to the processes that are performed by all three of the functions (technical, application, and IT operations management). We explored these as part of the review of operational activities in the previous chapter, which included activities such as monitoring, control and reporting, and the engagement of operational functions in the execution of other lifecycle processes (e.g., change management).

In this section, we will explore the activities that enable technical management to execute its role.

Technical management is responsible for identifying the knowledge and expertise required to manage and operate the IT infrastructure and to deliver IT services. This process starts during the service strategy stage, is expanded in detail in service design, and is executed in service transition and service operation. Ongoing assessment and updating of these skills is done during CSI. In this way, technical management operates throughout the service lifecycle.

This function is also responsible for documenting the skills that exist in the organization as well as skills that need to be developed. This will include the development of skills inventories and the performance of training needs analyses. Following this, it will be technical management that initiates training programs to develop and refine the skills in the appropriate technical resources and maintains training records for all technical resources.

The technical management function should have the appropriate skills to design and deliver training for users, the service desk, and other groups. Although training requirements must be defined in service design, they are executed in service operation. If there is no capability to actually deliver training, technical management will be responsible for identifying organizations that can provide it.

Technical management takes responsibility for managing the acquisition of skills that cannot be developed internally, for example, by recruiting or contracting additional resources. They also are responsible for acquisition of additional skills where there are insufficient people to perform the required technical management activities.

This function will also be involved in procuring skills for specific activities when the required skills are not available internally or in the open market or when it is more cost efficient to hire specialists.

During the service strategy and design stages, technical management will define the standards to be used in the design of new architectures and participate in the definition of technology architectures. As the repository of technical expertise, the function will also be responsible for research and development solutions that can help expand the service portfolio or be used to simplify or automate IT operations, reduce costs, or increase levels of IT service.

Additional activities for technical management include involvement in the design and build of new services. Technical management will contribute to the design of the technical architecture and performance standards for IT services. In addition, it will be responsible for specifying the operational activities required to manage the IT infrastructure on an ongoing basis.

Technical management will be participating in projects, not only during service design and service transition, but also for CSI or operational projects, such as operating system upgrades, server consolidation projects, and physical moves.

Modeling and workload forecasting are often done with technical management resources so that availability and capacity management for IT services meet the levels of service required by the business. This will also require assessing risk, identifying critical service and system dependencies, and defining and implementing countermeasures.

Technical management activities should include designing and performing tests for the functionality, performance, and manageability of IT services to support service transition activities. The function may also be engaged in managing suppliers; many technical management departments or groups are the only ones who know exactly what is required of a supplier and how to measure and manage them. For this reason, many organizations rely on technical management departments to manage contracts with suppliers of specific CIs. If this is the case, it is important to ensure that these relationships are managed as part of the SLM and supplier management processes.

It is obvious that as a function with service operation responsibilities, technical management will play a large role in the operational processes. For example, it will take the lead in defining and managing event management standards and tools. Technical management should also test event mechanisms during service transition and will also monitor and respond to many categories of events during service operation.

It is crucial that technical management departments or groups are integral to the performance of incident management. They receive incidents through functional escalation and provide second- and higher-level support. They are also involved in maintaining categories and defining the escalation procedures that are executed in incident management. They can provide scripts to ensure that correct incident details are captured and workarounds to assist the service desk in first-line resolution.

Technical management as a function provides resources that contribute to the execution of the problem management process. It provides technical expertise and knowledge that is used to diagnose and resolve problems. It also maintains relationships with the suppliers and their support teams that are used to escalate and follow up on technical issues, changes, incidents, and problems. They play an important part in defining coding systems that are used in incident and problem management (e.g., incident categories) and supporting problem management in validating and maintaining the known error database.

But as you have already seen, it is not only operational processes that gain value from this function; other lifecycle stages, such as service transition, will also benefit. Technical management will support the change management process where reliance on technical knowledge and expertise may be needed to evaluate changes and will assist with the deployment of releases.

In cooperation with application management, technical management will provide information for, and operationally maintain, the CMS and its data. This will be done to ensure that the correct CI attributes and relationships are created from the deployment of services and the ongoing maintenance over the life of CIs.

Technical management is involved in the CSI activities, identifying opportunities for improvement, particularly in highlighting areas for improvement and then helping to evaluate alternative solutions.

System and operating documentation needs to be maintained and kept up-to-date and properly utilized. This includes ensuring that all management, administration, and user manuals are up-to-date and complete and that technical staff are familiar with their contents. This needs to be done by those who have sufficient technical expertise, and the resources will often be provided through technical management.

Technical management will also be responsible for updating and maintaining data used for reporting on technical and service capabilities (for example, capacity and performance management, availability management, problem management) as well as for assisting financial management for IT services to identify the cost of technology and IT human resources used to manage IT services.

Many technical management departments, groups, or teams define the operational activities performed as part of IT operations management as well as performing the operational activities as part of an organization’s IT operations management function.

Technical Management Organization

Technical management is not normally provided by a single department or group. It is usual to find one or more technical support teams or departments providing technical management and support for the IT infrastructure. In all but the smallest organizations, where a single combined team or department may have to cover everything, separate teams or departments may be needed for each type of infrastructure being used.

Because technical management consists of a number of technological areas, each of which may require a specific set of skills to manage and operate it, there may be a number of teams. Some skill sets are related and can be performed by generalists, whereas others are specific to a component, system, or platform.

The principle of technical management organizational structure is that people are grouped according to their technical skill sets and that these skill sets are determined by the technology that needs to be managed.

Technical Design and Technical Maintenance and Support

In the ITIL framework, technical management teams include both specialist technical architects and designers (who are primarily involved during service design) and specialist maintenance and support staff (who are primarily involved during service operation).

Many organizations see them as two separate teams or even departments. The challenge of a separated approach is that good design needs input from the people who are required to manage the solution, and good operation requires involvement from the people who designed the solution. In other words, support staff should be involved during the design or architecture of a solution.

If possible, it is advisable to introduce measures to support the technical function approach, so designers should be held accountable for their portion of the design flaws that create operational outages, and support staff should be held accountable for their contribution to the technical architecture.

Measuring Technical Management Performance

The performance metrics for technical management will largely depend on which technology is being managed, but some generic metrics are listed next.

Technical Management Documentation

Technical management is involved in drafting and maintaining several documents as part of other processes (e.g., capacity planning, change management, and problem management). There will be some documents that are specific to the technical management groups or teams, such as technical documentation for CIs (e.g., technical manuals and administration manuals).

During the design lifecycle phase, technical management will be part of the creation of maintenance schedules for the infrastructure. They will also maintain a skills inventory in line with the processes, architectures, and performance standards, which will enable the identification of training requirements. It is important to remember that skills inventories provide information about the capability of the department for the delivery of service as well as identifying training needs.

IT Operations Control

This part of operations management oversees the IT infrastructure. In larger organizations, this may be carried out as part of an operations bridge or network operations center (NOC). In these organizations, there are dedicated staff members monitoring operational events on consoles and reacting to them as necessary, often in a separate area from the rest of IT. In smaller organizations, the line between technical management and operations control may be more blurred, with operations control being carried out by the technical management team, who monitor the systems from their desks, perhaps with one or two wall-mounted plasma screens. Whichever arrangement is chosen depends upon what suits the organization, but it is important that there are clearly defined expectations to ensure that the operations control tasks are carried out to the level required.

The operations control tasks are as follows:

• The centralized monitoring and management of system events, as discussed, sometimes referred to as console management.
• The scheduling and management of batch jobs to carry out routine tasks such as database updates.
• Carrying out backups of data and ensuring that this data can be restored if and when required. This may include the backup of entire systems or the restoration of individual files that a user may have corrupted.
• Although most printing is now carried out directly by the users, there may be certain requirements for centralized printing; pay slips will need to be printed in a secure environment to ensure confidentiality, and large print volumes may make centralized printing more efficient. The printing and distribution of these and other electronic output is an operations control task.
• Management of the output from any control activities should also be undertaken, such as distribution.
• Operations control may also undertake maintenance activities, under the guidance of the technical or application management functions; this could include archiving data, applying system packs, updating virus signatures, and so on.

Facilities Management

The other part of operations management is facilities management. Staff members involved in this will be responsible for the physical IT environment. This would include the following:

• Ensuring that the necessary power is supplied (including any requirements for its quality, such as the prevention of power spikes) at operational and recovery sites.
• Operating and maintaining uninterruptible power supply (UPS) devices and generators. Facilities management is responsible for ensuring that these are available and for testing to ensure that they will work as designed in the event of a power failure. This role may cover just a server room in a smaller organization or one or more data centers for larger ones.
• Ensuring the maintenance of satisfactory air-conditioning/cooling for rooms housing IT equipment, whether this is a server room or a complete data center for either operational or recovery sites.

Many organizations have undertaken data center or server consolidation projects in recent years to take advantage of technical advances. The facilities management function would be responsible for managing any such projects. In the case where the data center management is carried out by a third party, it would be the responsibility of facilities management to ensure that the external service provider was carrying out the required tasks to the agreed standard and managing any exceptions utilizing the supplier management process.

To be effective, operations management needs to understand the technology and how it supports the services provided, although this level of knowledge will be less than that provided by the technical and application management functions. There is a risk that operations staff members do not interact with the business as part of their work and so may fail to appreciate the business impact of failures or to understand the business importance of services, thinking of them in purely technical terms. It is essential that they have adequate understanding of the business aspect; the information showing how technology supports the business is available in the SKMS, but specific training may be required to ensure that they have the necessary appreciation of the impact technology has on the business.

The importance of stability of services has been already mentioned; one way of maintaining that stability is to ensure that routine tasks are carried out consistently, no matter which staff members are on shift. This requires that properly documented procedures and technical manuals are available to operations staff members.

The performance of the operations management function should be measured against clear objectives based on the performance of the service, not merely of the technology. Delivering the service to the required level, within the agreed cost, is essential, so operations management should be able to demonstrate the effectiveness of what they do but also prove that they are operating at maximum efficiency. Operations management should always strive to optimize the use of existing technology and exploit new technical advances to provide the required level of service at the best cost.

Measuring IT Operations Management Performance

As with all lifecycle processes and functions, measurement plays an important part in understanding and maintaining effectiveness and efficiency. IT operations management performance is measured in terms of its effective execution of specified activities and procedures as well as its execution of process activities. This is an area in which there are numerous examples of measures that might be applied, but they should be tailored to the needs of the individual organization in measuring the true value that operations provides in business terms.

Examples of key metrics used to measure the performance of the IT operations function can include the percentage of scheduled jobs completed successfully on time or the number of exceptions to scheduled activities and jobs. Quantification of the number of data or system restores required will help understand the workload of the function, as will equipment installation statistics, including number of items installed by type, successful installations, and so on. This in turn will be used to identify and report on the cost of operational activities.

IT operations management executes many service management process activities. Its ability to do so will be measured as part of the process metrics where appropriate, and some examples are response times, resolution times, implementation timescales for changes and releases, and their success or failure. There will be financial process measures and measures relating to availability and capacity, all based on activities carried out by the IT operations function. The details of these measures are best considered as part of the processes and are covered in more detail in the relevant process areas across the lifecycle.

IT Operations Management Documentation

A number of documents are produced and used during IT operations management. In this section we provide a summary of some of the most important and do not include reports that are produced by IT operations management on behalf of other processes or functions.

The first set of documents are the standard operating procedures (SOPs). These documents represent the routine work for every device, system, or procedure. SOPs should also include specific security administration procedures covering all operational aspects of service, system, data, and physical security. They also outline the procedures to be followed if an exception is detected or if a change is required. SOP documents could also be used to define standard levels of performance for devices or procedures.

In some organizations, instead of listing detailed performance measures, the SOP documents are referred to in the OLA. A clause is inserted to refer to the performance standards in the SOP and how they will be measured and reported.

Any activity that is conducted as part of IT operations should be recorded in an operations log because they can be used to confirm the successful completion of specific jobs or activities or that an IT service was delivered as agreed. They are the basis for reports on the performance of the IT operations management teams and departments. The format of these logs is as varied as the number of systems and operations management teams or departments. They may also be used to support problem management, enabling research into the root cause of incidents.

Where required, IT operations will be responsible for managing shift patterns. Not all organizations will have a 24-hour operation, but where one does exist, shift schedules are used to outline the exact activities that need to be carried out during the shift. They will also list all dependencies and activity sequences. There will probably be more than one shift schedule; each team will have a version for its own systems. It is important that all schedules are coordinated before the start of the shift. This is usually done with the help of scheduling tools by a person who specializes in shift scheduling.

Shift reports are similar to operations logs, but they have additional functions to record major events and actions that occurred during the shift and to form part of the handover between shift leaders. They will be used to report exceptions to service maintenance objectives and identify uncompleted activity that might impact performance in the next service hours.

Operations schedules are similar to shift schedules but cover all aspects of IT operations at a high level. This schedule can include reviews of the forward schedule of change document and an overview of all planned change actions as well as information about maintenance, routine jobs, and additional work. It can also include information about upcoming business or vendor events. The operations schedule may be used as the basis for a daily operations meeting. It may also be used for IT operations managers to track progress and detect exceptions.

Role

The application management function is involved in all applications. Even when the function has recommended purchase of the application from an external supplier, there is still a requirement for management activities to take place. These activities are very similar to those of the technical management function:

• It is responsible for managing the IT applications. This would include ensuring that the staff members performing this function have the necessary technical knowledge to design, test, manage, and improve IT services.
• It is the custodian of technical knowledge and expertise related to managing applications.
• Although we discuss this function under service operation, it provides appropriately skilled staff members to support the entire lifecycle. Application management staff members would be involved in drawing up the application strategy. They would carry out the design of new or changed applications and would be involved in planning and implementing their transition to the operational environment. Once the service is live, application management provides support, resolving incidents, investigating problems, and specifying changes or updates required to have the service operate efficiently. Application management staff members will identify service improvements and work with the CSI manager to design, test, and implement them.

Application management staffing and training responsibilities are the same as those identified for technical management, and the function similarly interacts with the other stages of the lifecycle.

Application management also performs other specific roles:

• Application support ensures that the operations management staff members are given the correct training to enable the applications to be run efficiently. They also contribute to the training for users so that the users can competently use the new or changed applications to support their business functions.
• As part of service design, application management may carry out a training needs analysis covering the service operation staff members and provide the required training, but this role is a continuous one, providing day-to-day support to the operations staff members.

Objectives

The objectives of application management are to do the following:

• Identify functional and manageability requirements for application software
• Help in the design of applications
• Assist in their deployment
• Support the applications in the live environment
• Identify and implement improvements

To be successful, application management must ensure that applications are well designed, taking account of both the utility and warranty aspects of service design. They must be able to deliver the right functionality at a reasonable cost if the business benefit is to be realized. The provision of the correct numbers of appropriately skilled staff members is essential so that these skills may be applied to resolve any application failures.

Application Management Principles

Application management is responsible for choosing whether to buy an application that supports the required business functionality or build the application specifically for the organization’s requirements. The decisions are often made at a senior management level, perhaps by a chief technical officer (CTO) or steering committee, but they are dependent on information from a number of sources. This is covered as part of service design, but from an application management function perspective, there are a number of considerations that will require application management expertise and input.

Application management will explore the capability of existing technology to deliver the required functionality and, if it requires customization, consider the implications and cost to the organization. They will assist by providing application sizing and workload forecasts and specifying manageability requirements, ongoing operational costs, and the requirements for reporting or integration into other applications.

Another important aspect is identifying what skills will be required to support the solution and the impact of administration and security requirements.

Once a decision has been made to build, then a further decision has to be made on whether the development will be outsourced or built using employees. To achieve this, there must be recognition of the management of the requirements, the acceptance criteria, and management of the operational environment.

This will require a clear understanding of the operational model, which is the specification of the operational environment in which the application will eventually run when it goes live. The operational model should be used for testing and transition prior to live operation.

Application Management Lifecycle

There are many names for the lifecycle in which applications are developed and managed, including the software lifecycle (SLC) and software development lifecycle (SDLC), both of which are used by application development teams and their project managers. Examples of these lifecycle approaches are structured systems analysis and design methodology (SSADM), dynamic systems development method (DSDM), and rapid application development (RAD).

Although these are important for any organization, ITIL is primarily interested in the overall management of applications as part of IT services, whether the applications are developed in-house or purchased from a third party.

In Figure 39.5, you can see the six steps in the lifecycle, which applies to both developed and purchased software.

The software development lifecycle is a valid approach used by developers, especially third-party software companies. So there should be alignment between the development view of applications and the ongoing lifecycle management of those applications.

The basic lifecycle is used even for large third-party applications, like email, in that whatever the size of the application, it will need requirements, design, customization, operation, and deployment. Optimization is achieved through better management, improvements to customization, and upgrades.

The application management lifecycle is not an alternative to the service management lifecycle. Applications are part of services and have to be managed as such. Applications require a specialized focus at each stage of the service management lifecycle.

In the next sections, we’ll review each step of the application management lifecycle.

Requirements

Obviously, as the name suggests, the requirements stage is the stage during which the requirements for a new application are gathered, based on the business needs of the organization. As you would expect, this stage is active primarily during the service design stage of the service lifecycle.

There are six types of requirements for any application, whether it is developed in-house, outsourced, or purchased.

The first is the functional requirements, which are specifically required to support a particular business function. Then we have the manageability requirements; the application is looked at from a service management perspective, and these requirements address the need for a responsive, available, and secure service and deal with issues such as deployment, operations, system management, and security. Next come the usability requirements that address the needs of the end user and result in features of the system that facilitate its ease of use. Architectural requirements are needed if a change to existing architecture standards is required.

Most applications will not be stand alone, so an important factor is to identify the interface requirements. These are needed where there are dependencies between existing applications or tools and the new application.

Finally, but not because they are less important, there are service level requirements. These specify how the service should perform, the quality of its output, and any other qualitative aspects measured by the user or customer.

Design

The design stage includes the design of the application itself and the design of the environment, or the operational model that the application has to run on, as the requirements are translated into specifications.

Architectural considerations for the application (design of the application architecture) and architectural considerations for the operation model (design of the system architecture) are strongly related and need to be aligned. Architectural considerations are the most important aspect of this stage because they can have an impact on the structure and content of both the application and the operational model.

In the case of purchased software, it is unlikely that an organization will be allowed direct input to the design of the software because it has already been built. However, it is important that application management is able to provide feedback to the software vendor about the functionality, manageability, and performance of the software. This should be part of the continual improvement of the software. A good vendor will be responsive to improvements but should ensure that there is a balance between being responsive and changing the software so much that it is disruptive or that it changes some basic functionality.

The design stage for purchased software should include the design of any customization that is required. It is important to evaluate the capability of future versions of the software to support importing and maintaining the customization. It is common to discover that with each successive upgrade, the actual time for release gets longer in order to reapply existing customization to the product.

Build

In this stage, both the application and the operational model are made ready for deployment. Application components are coded or acquired and then integrated and tested.

Testing is an integral component of both the build and deploy stages because it is a validation of the activity and output of those stages, even if different environments and staff are used. Testing in the build stage focuses on whether the application meets its functionality and manageability specifications. The test environment allows for testing the combination of application and operational models.

For purchased software, this will involve the actual purchase of the application, any required middleware, and the related hardware and networking equipment. If customization is required, a pilot implementation by the relevant application management team or department will need to be done here because the creation of tables, categories, and so on that will be used should be tested for success prior to full implementation.

Deploy

In the deploy stage, both the operational model and the application are deployed. The operational model is incorporated into the existing IT environment, and the application is installed on top of the operational model using the release and deployment management process, as described in ITIL Service Transition.

There is testing during this stage as well, although here the emphasis is on ensuring that the deployment process and mechanisms work effectively—for example, testing whether the application still performs to specification after it has been downloaded and installed. Specialized support for a new or changed IT service for a period of time after it is released is known as early life support (ELS). Support activities during this period can include review of KPIs, service levels, and monitoring thresholds and provision of additional resources for incident and problem management. ELS is covered in detail in ITIL Service Transition.

Operate

In the operate stage, the IT services organization operates the application as part of delivering a service required by the business.

It is important to understand that applications are not a service. It is common in many organizations to refer to applications as services, but applications are only one component of many needed to provide a business service. The performance of the application in relation to the overall service is measured continually against the service levels and key business drivers.

The operate stage is not exclusive to applications but exists for any product, technology, or service provision.

Optimize

During this stage, the results of the service level performance measurements are analyzed and acted upon. This is when possible improvements are discussed and developments are initiated if necessary. The two main strategies in this stage are to maintain and/or improve the service levels and to lower cost. This could lead to a repeat of the lifecycle or to justified retirement of an application.

An important thing to remember about the application management lifecycle is that the same application can reside in different stages of the lifecycle at the same time. This obviously requires strong version, configuration, and release control; for example, when the next version of an application is being designed and the current version is being deployed, the previous version might still be in operation in parts of the organization.

Some stages might take longer or seem more significant than others, but they are all crucial.

It is critical that information is passed along by those handling the application in one stage of its existence to those handling it in the next stage. Good communication is key as an application works its way through the stages of the lifecycle. It is also important that an organization monitors the quality of the application management lifecycle. Understanding the characteristics of every stage in the application management lifecycle is critical to improving the quality of the whole. Methods and tools used in one stage might have an impact on others, while optimization of one stage might have a negative impact on the whole.

Application Management Generic Activities

The exact nature of the role will vary depending upon the applications being supported, but application management teams or departments will be needed for all key applications. There are a number of generic activities, which we will briefly explore in this section.

Similar to technical management, the generic activities include the identification and provision of knowledge and expertise to manage and support the application and management of training to use or support the application.

Further activities will include recruiting or contracting resources with skills that cannot be developed internally. Resources will also need to be recruited when there are not enough people to perform the required application management activities.

Application management is responsible for designing and delivering end-user training. Training may be developed and delivered by either the application development or application management groups or by a third party, but application management is responsible for ensuring that training is conducted as appropriate. It is important to understand the staffing requirements and the most cost-effective way to provide them. This may include outsourcing for specific activities where the required skills are not available internally or in the open market or where it is more cost-efficient to do so.

During the definition of application architectures (as part of the service strategy processes), application management should help to define standards used in the design of new architectures. They should also play a major part in researching and developing solutions that can help expand the service portfolio or can be used to simplify or automate IT operations, reduce costs, or increase levels of IT service.

Application management should participate in the design and building of new services. All application management teams or departments will contribute to the design of the technical architecture and performance standards for IT services. They will also be responsible for specifying the operational activities required to manage applications on an ongoing basis.

In addition, application management may be used to participate in projects, not only during the service design process, but also for CSI or operational projects.

They will have responsibility for designing and performing tests for the functionality, performance, and manageability of IT services (bearing in mind that testing should be controlled and performed by an independent tester).

The design activity will include designing applications to meet the levels of service required by the business. Availability and capacity management are dependent on application management for design expertise and guidance to assess the appropriate level of resources that will meet business demand for applications. This means that modeling and workload forecasting are often done together by technical and application management resources.

Application management, like technical management, will be key in providing assistance in assessing risk, identifying critical service and system dependencies, and defining and implementing countermeasures.

Many application management departments or groups are relied on to manage contracts with suppliers of specific applications because they will have the required understanding and knowledge. If this is the case, it is important to ensure that these relationships are managed as part of the SLM and supplier management processes.

The application management function will be heavily involved in all of the operational processes, and they should be involved in the definition of event management standards and especially in the instrumentation of applications for the generation of meaningful events. The function will also be expected to provide resources that contribute to the execution of the problem management process. It is their technical expertise and knowledge that is used to diagnose and resolve problems. It is also their relationship with the vendors that is used to escalate and follow up with vendor support teams or departments. Other activities relating to incident and problem management include defining coding systems that are used in incident and problem management (e.g., incident categories) and providing resources to support problem management and the application development teams in validating and maintaining the known error database. Application management also provides scripts to the service desk to ensure good-quality incident capture and workarounds to facilitate first-time fixes.

Service transition will also make use of application management to support change management with technical application knowledge and expertise to evaluate changes. Many changes may be built by application management teams. They will also participate in release and deployment management activities. Application management is frequently the driver of the release and deployment management process for the applications they manage.

An important part of the function is assistance in defining, managing, and maintaining attributes and relationships of application CIs in the CMS and ensuring that they provide input into, and maintenance of, software configuration policies. They will also help in identifying opportunities for improvement and assist in the evaluation of alternative solutions.

Application management will be responsible for coordinating with development teams to ensure that a mechanism is in place to store and maintain documentation related to applications. This includes ensuring that all design, management, and user manuals as well as SOPs are up-to-date and complete and properly utilized on an ongoing basis. Application management also ensures that application management staff and users are aware of application documentation and familiar with its contents.

Another key area for this function is collaborating with technical management on performing training needs analysis and maintaining skills inventories.

The application management function is involved throughout the service lifecycle. They will assist financial management for IT services to identify the cost of the ongoing management of applications.

Many application management departments, groups, or teams also perform operational activities as part of an organization’s IT operations management function, and they will be involved in defining the operational activities related to applications that will be performed as part of IT operations management.

Application bug tracking and patch management (coding fixes for in-house code, transports/patches for third-party code) are also part of the role, as is involvement in application operability and supportability issues such as error code design, error messaging, and event management hooks.

As part of service design, and in support of capacity and availability management processes, the function will be engaged in application sizing and performance, volume metrics, and load testing.

They will be involved in developing release policies and, of course, identification of enhancements to existing software, from both a functionality and manageability perspective.

Although all application management departments, groups, or teams perform similar activities, each application or set of applications has a different set of management and operational requirements. Each application was developed to meet a specific set of objectives, usually business objectives. For effective support and improvement, the group that manages an application needs to have a comprehensive understanding of the business context and how the application is used to meet the business objectives. The business objectives will be dependent on a number of factors, such as the purpose of the application. The understanding of the business objectives is often achieved by business analysts who are close to the business and responsible for ensuring that business requirements are effectively translated into application specifications. Business analysts should recognize that business requirements must be translated into both functional and manageability specifications. Another consideration is the functionality of the application. Each application is designed to work in a different way and to perform different functions at different times.

Not all applications run on the same platform, so technical management and application management will need to work together as they support the environment and the applications. Even applications that have similar functionality operate differently on different databases or platforms. Similarly, the type or brand of technology used will have an impact. These differences have to be understood to manage the application effectively.

Even though the activities to manage these applications are generic, the specific schedule of activities and the way they are performed will be different. For this reason, application management teams and departments tend to be organized according to the categories of applications they support.

For example, in larger organizations where a number of different applications are used for different aspects of financial management, there may be several departments, groups, or teams managing these applications (e.g., applications for debtors and creditors and age analysis, general ledger).

This approach can be used for a number of different applications, such as messaging and collaboration applications, human resources applications, manufacturing support applications, and applications for business functions such as sales and marketing, call centers, web portals, and online shopping.

Application Development vs. Application Management

As discussed earlier, application management and application development have separate aims and responsibilities. These two groups may work closely together or they may be quite separate, with different reporting structures and a different interface with the business. Application development, as we said earlier, is normally a finite activity to develop an application, and the team moves on to the next requirement when finished. Application management, on the other hand, remains involved throughout the lifecycle of the application. Here is a summary of the differences between them:

• Development focuses on the utility aspects, and most of its work is carried out on applications developed in-house. Management activities consider both warranty and utility and are carried out whether the application is internally developed or purchased.
• Development is concerned with functionality and does not consider how the application is to be operated or managed, whereas application management is concerned with how this functionality is to be delivered consistently.
• Development is often carried out as part of a project, with defined deliverables, costs, and handoff dates. This differs from application management, whose activities are ongoing throughout the service lifecycle and whose costs may not be separately identified.
• Developers may not have an understanding of what is required to manage and operate an application because they do not support the applications they have developed, instead moving on to the next development project. Similarly, application management staff members may have little involvement in development and therefore have less understanding of how applications are developed.
• Development staff members work to software development lifecycles. Application management staff members are often involved only in the operation and improvement stages of the service lifecycle.

Figure 39.6 shows the different roles of the application management and application development teams; the application development team is primarily concerned with the functionality of the application, whereas the application management team considers how the application infrastructure will support the application and how it will be built, deployed, and monitored in operation.

There is a growing tendency to end the division between the two teams because it is confusing for the business to understand. Ideally, this will mean a broadening of the development role to include considering how applications will operate, and it will mean more involvement in development for staff members who will be managing the application, as shown in Table 39.2.

Measuring Application Management Performance

Performance metrics for application management will largely depend on which applications are being managed, but some generic metrics are included here.

Application Management Documentation

As you would expect, there are a number of documents produced and used during application management. The following sections provide a summary of some of the most important but do not include reports or documents produced by application management on behalf of other processes or functions.

Service Owner

Because every service interacts with so many processes, there is a danger that a service itself may no longer receive the required attention. To avoid this, ITIL recommends that each service should have a single service owner. This clarifies who is accountable for the service and ensures that there is a focus on the business processes that the service supports.

Whatever technology is used to deliver the service and regardless of whether aspects of the technology are provided in-house or are outsourced, the service owner remains accountable for delivering the service. This role is responsible to the customer for the service being developed, implemented, and maintained, but it is also accountable to the IT director or service management director for its delivery.

As we will examine, ITIL recommends that each process have an identifiable owner. Each process may affect many services, and it is the service owner of each who will ensure the service is delivered effectively and efficiently, whatever process is being carried out. Service owners will often own more than one service. For each service, they will carry out the following responsibilities:

• Ensuring that the service is delivered and supported to the required standards by working with all IT groups and process owners
• Ensuring that the customer’s requirements are understood and that the tasks required to deliver them are implemented by working with the business relationship manager
• Communicating with the customer as required on all issues regarding the delivery of the service
• Using the service portfolio management process to define new service models and to evaluate the impact of any changes to existing services
• Ensuring that the service undergoes continual service improvement by identifying possible improvements and, with the customer’s agreement, putting these forward as requests for change
• Ensuring that appropriate monitoring and reporting is taking place to enable an accurate view of the level of service being delivered
• Ensuring that the required levels of performance and availability are delivered
• Developing a thorough understanding of the components that make up the service and ensuring that the potential impact of their failure is realized
• Representing the service across the organization and attending service review meetings with the business
• Representing the service within IT and at change advisory board meetings and internal service reviews
• Being the escalation (notification) point for major incidents affecting the service
• Working with service level management to negotiate service level agreements that meet the customer requirements and operational level agreements that support the service provision at the agreed level
• Maintaining the service catalog entry
• Working with the CSI manager to identify improvements to be added to the CSI register and participating in the review and prioritization of these and their eventual implementation

As the owner of the service, this role is concerned with the impact of any process affecting the service. This means service owners should be considered stakeholders in these processes, with whatever level of involvement is appropriate.

For example, the service owner plays a major part in the major incident process and will attend or possibly run any crisis meetings. They will also be involved in investigating the root cause of problems affecting their service. The service owner will represent the service at CAB meetings and will be involved in discussions regarding if and when a release should go ahead. They will want to ensure that the service portfolio and catalog entries and configuration data held on their service is accurate.

As explained earlier, there will be a close relationship between the service level management process and the service owner who acts as the contact point for the service. The service owner will also liaise with the owners of the more technical processes, such as availability and capacity, to ensure that the data collected by these processes indicates that the performance and reliability of the services meets the agreed standard.

The service owner is responsible for ensuring that the IT service continuity management plan for their service is practical and that every element of the plan is in place. They will work with the ITSCM manager to make sure all aspects are considered. They will often attend rehearsals of the plan to observe it in action to confirm that nothing has been forgotten.

The service owner understands the costs involved in delivering the service and will work with the supplier manager and other managers to ensure that costs are controlled and value for money is achieved. In organizations where the business is charged for IT services, they will ensure that the recovery of costs takes place as agreed.

Finally, the service owner ensures that the service follows the information security management policies.

Process Owner

As you have seen, the service owner is the focus for one particular service, across all process areas. The process owner, in contrast, is accountable for a single process, whatever service it affects.

The process owner must ensure that the process works efficiently and effectively. Although the role may often be carried out by the same person who fulfils the process manager role, in larger organizations this is less likely. A global company may have a change management process owner and a number of process managers carrying out the process in different countries, for example. The process owner is accountable for ensuring that the process is fit for its purpose and is being carried out correctly by the process managers and practitioners. The role therefore has both a design and an enforcement aspect.

The process owner is accountable for the following:

• Developing the process strategy, policies, and standards
• Designing the process and amending it as required to implement improvements that make it more effective or efficient
• Designing the metrics for the process and ensuring that they provide the necessary information to judge the effectiveness and efficiency of the process
• Ensuring that the process is documented, that this documentation is available to those that require it, and that it is updated as needed
• Where the process has changed, ensuring that the process documentation is updated and the changes communicated to the process practitioners (those who actually carry out the process steps)
• Auditing the process activities to ensure adherence to the correct process
• Ensuring that the required resources are available to carry out the process and that the staff members involved have been trained to carry it out
• Communicating to the process technicians the importance of adhering to the documented process and explaining the implications for IT and the business of nonadherence
• As part of continual service improvement, reviewing the process strategy and the effectiveness of the process itself to identify possible improvements
• Where improvements to effectiveness or efficiency are identified, having these included in the CSI register and working with the CSI manager to review, prioritize, and implement them as appropriate

The process owner role is critical to the success of the process. In organizations where no such single point of ownership exists, those carrying out the process may decide to drop or amend steps in the process, and there is no one with the overall authority to prevent this. In global organizations, this can mean the process might develop regional variations. In addition to the danger of losing focus on the purpose of the process, this may invalidate the reporting from the process because each area may be inputting data differently.

Earlier in this volume, we discussed a generic process model. Without a process owner, there is no one with the responsibility of ensuring consistency in applying the process, and there is no one to ensure that the process output still matches the process objectives. Process documentation may not be updated because the responsibility for its upkeep would be unclear. Finally, there would be no one to assess the process and identify improvements.

Process Manager

The process owner is accountable for the success of the process but may often not be responsible for actually carrying it out. The responsibility for managing the day-to-day implementation of a process belongs to the process manager. In large or geographically spread-out organizations, there may be several process managers responsible for managing the implementation of the same process, each with a regional or infrastructure responsibility.

The process manager is accountable for the following:

• Liaising with the process owner to ensure that the process is implemented across all lifecycle stages as the process owner intended
• Ensuring that the right number of staff are assigned to the various roles within the process and that they understand what is required of them
• Working with other process managers and service owners to ensure that services are delivered as required
• Monitoring the process metrics to confirm that the process is working as designed
• As part of continual service improvement, reviewing the process performance to identify possible improvements
• Where improvements are identified, having them included in the CSI register and working with the CSI manager and process owner to review, prioritize, and implement them as appropriate

The role of process manager is important because it is the process manager who ensures that the process is carried out correctly day to day. The process manager may be distant from where the process actually occurs (working in the head office, while the process takes place in branch offices, for example). The process manager, or managers, will ensure that the staff members understand what is required of them and have been provided with the right resources and training to carry out the tasks. Because process managers are close to the process execution, they are in an ideal position to identify issues and possible improvements. The success of any improvement initiatives will depend heavily on the enthusiastic involvement of the process manager in ensuring that staff members adopt the improved process.

Process Practitioner

Depending on the process, there may be one or more people carrying out the process activities. In a small organization or for a simple process, this may be a single person, who is also likely to be the process manager. For a large organization or for a complex process, there may be many people, each carrying out parts of the process. The people involved in carrying out the process activities are the process practitioners.

The process practitioner is usually responsible for the following:

• Completing process activities to the required standard
• Understanding the importance of the process and their role within it and how they contribute to delivering the service
• Working with all the process stakeholders to ensure that the process inputs, outputs, and interfaces are working properly so that the process delivers the desired result
• Producing evidence, in the form of records that the process activities have been carried out correctly
• Identifying necessary improvements to the process or supporting tools

The process practitioner role is responsible for actually delivering the process activities. Under the guidance of the process manager (unless these roles are combined), the practitioner is responsible for carrying out the process as designed, consistently and efficiently. It may be tempting to believe that the practitioner has nothing to contribute other than carrying out the activities; this is far from the truth. As a practitioner, the staff member will experience firsthand any issues with the process, such as tools that do not support the process effectively, bottlenecks in the process flow, or ambiguities in the documentation. The process manager and process owner should therefore seek out the views of practitioners when attempting to identify possible improvements.

Each role has its own purpose. Even where the roles are carried out by the same person, that person should attempt to consider each aspect of the roles. The practitioner has the advantage of daily interaction with the process but may be too close to it to see it objectively; the process manager is judged on the outcome of the process and so has a particular focus on the resources required to deliver these outcomes effectively and efficiently. They will monitor the process metrics closely to ensure that the outputs are being delivered on time and within budget. The manager will see only their own part of the process delivery, however. The process owner has the advantage of seeing the overall picture, comparing the delivery of the process in different locations and under different process managers. When the strengths and weaknesses of each perspective are understood, a complete picture of the process delivery can be achieved, and improvement initiatives can be gathered from each level.

Incident Management/Request Fulfilment

For incident management there are three practitioner roles: first-, second-, and third-line analyst. The first-line analyst role is usually combined with the service desk analyst role. The others correspond to the levels of functional escalation, which means they reflect the levels of skill and seniority or experience in the supported technologies. Third-line analysts are often associated with the technical or application management functions.

For request fulfilment, it is not uncommon to have a specialized team supporting the process, but this will depend very much on the number and type of requests identified and managed under this process. Each organization will have to determine the most appropriate structure for dealing with requests, whether this is a dedicated team or part of the service desk function.

Remember, each process will have an owner carrying out generic ownership responsibilities and a manager focused on the management of the activities of the practitioners.

Problem Management

For problem management, there is one practitioner role, but this can be undertaken by any member of the organization that is involved in the investigation and resolution of problems. The problem analyst role is often undertaken by the functions of technical and application management due to the level of skill and understanding that is required to identify and correct the root cause of a failure.

Remember, each process will have an owner carrying out those generic responsibilities and a manager focused on the management of the activities of the practitioners.

Event Management

Event management is a process that makes use of the functional teams for the management of the process activity. Each organization will have to establish the structure it wishes to adopt to manage events.

The role of the service desk may be to receive and act on alerts generated by event management. If the enterprise has an operations bridge, it will usually receive these alerts.

Technical and application management participate in the design and implementation of monitoring facilities and the event handling tool, including automation. They might also respond to some alerts if there is no operations bridge.

If an operations bridge exists, it is usually the first responder to any alerts as part of the function of IT operations management.

Access Management

The service desk is the single point of contact, and it may be used by the users in the organization to request access and be kept informed of progress. In some cases, it is appropriate for the service desk to change access rights.

Technical and application management design and test the access mechanism and may be needed to change rights as necessary.

IT operations management in the form of an operations bridge may configure rights as necessary and will also respond to any alerts relating to misuse of rights.

Again, the structure of the support mechanism for the process will be specific to the organizational needs. In an organization with very high security controls around access, it is entirely possible that technical and application management will be the only areas with rights to grant or change access. In a less controlled environment, password resets may be carried out by service desk analysts or the request fulfilment team.

Technical and Application Management Roles

The technical and application management roles defined in ITIL Service Operation carry out the activities of these functions. If you understand what these functions do, then we don’t think that the manager and analyst roles need any explanation.

A technical operator is a person who carries out routine day-to-day tasks related to the management of the infrastructure. If IT operations management exists as an organizational unit, then this role is carried out there.

IT Operations Management and Service Desk Roles

Many IT operations groups work some sort of shift system, often providing 24-hour coverage. The staff are organized into shifts, each with a shift leader who has a supervisory role.

IT operations analysts are skilled, experienced staff who are able to determine the best way of carrying out operational duties. For example, they would determine the best way to schedule the batch work.

The IT operator carries out the tasks defined for IT operations management.

The same considerations apply to the service desk, and there may also be a requirement for shift support patterns. Even when service desks are not based on a 24-hour shift pattern, they may still have a shift system to allow them to cover changing call volumes during the working day.

In addition to the dedicated staff at the service desk, super users based in the organizational business community can provide an element of functional support to the business. These individuals will need to receive appropriate training and will be required to log calls in the service management toolset, otherwise the health of the service in the business units may not be properly understood.

Many organizations will have the role of the duty manager to take responsibility during off-peak hours. These individuals will also require training and be required to log calls.

Organization by Technical Specialization

In this type of structure, departments are created according to technology and the skills and activities needed to manage that technology. This structure can work well, provided these groups are fully represented in the service design, testing, and improvement processes. It is shown in Figure 39.7.

This structure also assumes that all technical and application management departments have clearly distinguished between their management activity and operations activity. It also requires that they have standardized these operational activities to maximize efficiency. This type of structure requires a significant level of maturity to manage effective communication, but there are a number of advantages to this structure:

• It is easier to set internal performance objectives because all staff in a single department have a similar set of tasks on a similar technology.
• Individual devices, systems, or platforms can be managed more effectively.
• Managing training programs is easier because skill sets are clearly defined.

There are also some disadvantages to this type of organizational structure:

• When people are divided into separate departments, the priorities of their own group tend to override the priorities of other departments and a “silo mentality” or “blame culture” can quickly grow.
• Knowledge about the infrastructure and relationships between components is fragmented and difficult to collect.
• Each technology managed by a group is seen as a separate entity. If a change is made by one team or department without consulting the others, this could be disastrous for the service.
• Work requiring knowledge of multiple technologies is difficult because most resources are trained for and concerned with the management of only a single technology.

Projects therefore have to include cross-training, which is time consuming and expensive.

Organization by Activity

The activity-based organizational structure focuses on the fact that similar activities have to be performed on all technologies in the organization. This means that people who perform similar activities, regardless of the technology, should be grouped together, although within each department there may be teams focusing on a specific technology, application, and so on. The activity-based structure is shown in Figure 39.8.

In this type of organization, there is no clear distinction between the different technical and application management areas. Similar activities from many different areas can be grouped into a single department.

The advantages of this type of organizational structure are as follows:

• It is easier to manage groups of related activities because all the people involved in these activities report to the same manager.
• Measurement of teams or departments is based more on output than on isolated activities. This helps to build higher levels of assurance that a service can be delivered.

The activity-based structure has the following disadvantages:

• Resources with similar skills might be duplicated across different functions, which results in higher costs.
• Although measurement is based on output, it is still focused on the performance of internal activities rather than driven by the experience of the customer or end user.

Organizing to Manage Processes

Processes are used to overcome the “silo effect” of departments, not to create silos. However, it is not necessarily a good idea to structure the whole organization according to processes. There are a number of processes that may need a dedicated organizational structure for support and management. In process-based organizations, people are organized into groups or departments that perform or manage a specific process. This is similar to the activity-based structure, except that its departments focus on end-to-end sets of activities rather than on one individual type of activity.

If IT operations management is responsible for more than just IT operations, then this type of organizational structure may be used effectively. Process-based departments are really effective only when they are able to coordinate the execution of the process through the entire organization, not just in one department.

The advantage of this type of organizational structure is that processes are easier to define. Metrics of team or department performance and process performance are the same, effectively aligning internal and external metrics.

This type of organizational structure does have some disadvantages:

• When processes are used as a basis for organizational design, additional processes may need to be defined to ensure that the departments work together because there will still be external dependencies.
• While some aspects of a process can be centralized, there will always be a number of activities that will have to be performed by other groups.
• The relationship between the dedicated team or department and the people performing the decentralized activities is often difficult to define and manage.

Organizing IT Operations by Geography

Organizations can have physically distributed IT operations, and in some cases, each location needs to be organized according to its own particular context.

This type of structure is used when there are different regions or countries that use different technologies or provide a different set of services. A geography-based structure is shown in Figure 39.9.

Global organizations may have to organize according to regional variations in business models or organizational structures, in legislative regulations or standards, or in cultures and language.

The advantages of this type of organizational structure are as follows:

• Organizational structure can be customized to meet local conditions.
• IT operations can be customized to meet differing levels of IT service from region to region.

This type of organizational structure has the following disadvantages:

• Reporting lines and authority structures can be confusing. For example, does network operations report to the local data center manager or to a centralized network operations manager?
• Operational standards are difficult to impose, resulting in inconsistent and duplicated activities and tools. This can cause reduced economies of scale, which in turn increases the overall cost of operations.
• Duplication of roles, activities, tools, and facilities across multiple locations could be costly.
• Shared services, such as email, are more difficult to deliver because each regional organization operates differently.
• Communication with customers and inside IT will be more difficult because they are not colocated and it may be difficult for staff in one location to understand the priorities of customers or staff in another location.

Hybrid Organization Structures

It is unlikely that IT operations management will be organized using only one type of organizational structure. Some organizations use a technical specialization structure combined with some additional activity- or process-based structures.

The type of structure used will depend on a number of organizational variables, which may include the nature of the business and its requirements and expectations. Technology and architecture may be significant factors, as well as the stability of the current IT infrastructure and the availability of skills to manage it. Another factor may be the governance of the organization, which may be driven by external legislation.

Further considerations include the political and socioeconomic environment of the organization and its size, age, and maturity and the type and level of skills available to the organization. The organization’s dependence on IT for business-critical activities, processes, and functions will have an effect, as will the participation of IT in the value chain and the relationship between IT and vendors.

Combined Functions

One final type of organization should be discussed. This structure incorporates IT operations, technical, and application management departments into a single structure. In this structure, the IT operations manager takes responsibility for all technical, application, and IT operations management. The centralized structure is shown in Figure 39.10.

The advantages of this organization structure are as follows:

• There is greater consistency and control between the more tactical and more operational technical management activities.
• It is easier to enforce the performance standards and technical architectures that are created in service design because the people who were involved in design are managing the activities of the people who are executing those activities.
• Because there is no duplication between location or activity, this structure is often more cost-effective.

The disadvantage of this organizational structure is that its scope makes it difficult to manage effectively in large organizations or in organizations with multiple data or operational centers.

Organizing Application and Technical Management

Technical and application management organizations tend to be fairly straightforward. Technical management departments are usually based on the technology they manage, and application management departments are usually based on the applications and sets of applications they manage.

But there are alternatives, and they can be arranged in structures similar to those we have just considered. For example, they can be organized through a geographical approach, where the locations require local functional capability, or through a systems-based approach, linking the technical and application teams for the system.

The advantages of a geographical structure are that the organizational structure can be customized to meet local conditions and technical and application management can be customized to meet differing levels of IT service from region to region.

The disadvantages of this type of organizational structure are as follows:

• Reporting lines and authority structures can be confusing.
• Standards are difficult to impose, resulting in inconsistent and duplicated activities and tools, causing reduced economies of scale, which in turn increases the overall cost of operations.
• Duplication of roles, activities, tools, and facilities across multiple locations could be very costly.

The advantage of a system-based organization structure is that department members are focused on the success of the system as a whole rather than the performance of an individual technology component or application.

The disadvantages of this organizational structure are as follows:

• Duplication of skills and resources across several departments will increase the cost of the organization.
• Communication between staff who are managing similar technology is reduced, and this in turn reduces the amount of learning by experience and increases reliance on collaborative knowledge management tools.