How To Consolidate A Service Desk

June 2005 Service Desk: Consolidation, Relocation, Status Quo

Contents Foreword So, you are going to consolidate or relocate your Service Desks 2 Foreword 3 Introduction 4 Select the transition date based on business cycles 5 Identify affected resources of all types 6 Plan for timely communications to all stakeholders 7 Measure success through the eyes of the customers 8 Identify any risks for tools, people, process, and data 8 Plan backup as if prepping for major disaster 9 Detail the project task plan and test it frequently 10 Satisfy the sponsor s objective for the project 10 Protect project schedule integrity by securing staffing resources that are dedicated to the project 11 Make mistakes early using tabletop drills 11 Summary how do you propose to perform such a feat without adversely impacting the current level of service? With all the demands on service quality and more effective use of resources, how do you reconfigure your airship while in flight? As issues begin to heat up surrounding Service Desk capabilities, on the list somewhere will be the issue of deciding if consolidation or relocation will provide a return on investment that provides improved customer satisfaction with IT services. It is not uncommon in mergers and acquisitions to meld together existing service desks to ensure there is appropriate balance of service support resources to primary business functions. Oftentimes, there can be heard inside IT the same directive that has affected the entire enterprise, to do more with less, or to improve customer satisfaction without adding to the cost. These mandates are not frivolous but are meant to ensure expenditures are validated for processes, people, tools, and information.

Top decision criteria include: payback period and benefit cost ratio, agent skills distribution, and quality of service to the customer. Introduction As companies grow and acquisitions and mergers occur, it is common for an organization to take stock of their current expense profile for IT support and determine where it would be appropriate to implement cost reduction initiatives. When considering service desk consolidation or even just relocation, the enterprise must calculate the costs, benefits, and risks that accompany this type of activity. While there are other decision criteria that may also be addressed, clearly a few rise to the top: payback period and benefit cost ratio, agent skills distribution, and quality of service to the customer. As each of these is kept in focus, a project plan must be developed encompassing the six primitives of virtually any project: what needs to be done, how will it get done, where and when will the work be accomplished, who will do the project tasks, and, according to the sponsor, why is this project being initiated. Each of these has within it the need to address those processes, tools, data, and organizational implications that facilitate providing quality service to the customers of IT. 10 Tips for Service Desk Consolidation Select transition date based on the business Identify affected resources of all types Plan for timely stakeholder communications Measure success through the customers Identify risks for tools, people, process, data Plan backup as if prepping for major disaster Detail the task plan and test it frequently Satisfy each of the sponsor s objectives Protect schedule with dedicated resources Make mistakes early using tabletop drills

there is no replacement for timing. Select the transition date based on business cycles Early in the cycle of events, there must be some options visited when selecting the timing of the actual consolidation. Much the same as would be done for a major release (Release Management) in terms of addressing business and personnel cycles. Dependent on your business, there are times when a major effort of this sort should not be scheduled if at all possible. There are, however, merger and acquisition implications that sometimes dictate the date irrespective of what is going on in the business at the time. When faced with the requirement to engage in this type of activity and the date has been dictated by a higher level issue, there is greater burden on the project manager (PM) to verify that multiple measurable checkpoints exist that will alert the team when anything is awry. In all cases, the PM should verify that the stakeholders are made aware of identified risks and the proposed steps necessary to mitigate them. Also, that they have specific resources assigned to them as part of the project plan. So remember, when deciding on the date for the activity, the old adage well known by corporate leaders, there is no replacement for timing.

Peregrine Systems and IBM provide significant contribution to the overall project. Identify affected resources of all types Virtually every element of the IT infrastructure can be impacted when a service desk operation is interrupted for whatever reason. Clearly as part of the early planning stages, a decision must be made as to what the agent s workstation and workspace will look like when the effort is complete. Will there be new hardware, will the agent images be the same (how many images are there really), how will physical access be addressed, and are there any special ergonomic requirements? Are there specific agent security or authorization implications associated with the physical relocation of personnel that could have an adverse impact on their ability to provide quality customer service? Once these physical location and organization elements have been planned for, attention can be turned to the tools, process, and data requirements of the consolidation activity. Each of these, as stated earlier, must have the six primitives dealt with as part of the plan. Verify that decisions regarding MAC (move, add, change hardware / software) of agent workstations is reflected in the existing Change Management System and the CMDB (Configuration Management Data Base). In the case of mergers and acquisitions, there may also be a training component for personnel new to the infrastructure elements and IT s management processes. Clearly there is significant work that must be accomplished by resources not attached to the day-to-day provision of service to the customer. In this space, Peregrine Systems and IBM provide significant contribution to the overall project through methods and experience to help ensure that the infrastructure meets all the various requirements of the consolidation work plan.

Timely and detailed communication is key. The entire team must be unified. Plan for timely communications to all stakeholders It is extremely important to verify that all stakeholders are kept apprised of project/milestone status as the project progresses. When planning a consolidation activity within an existing company, and few if any personnel are relocated, it may be possible to have an open communications style to help eliminate surprises. In the case of multiple business entities coming together, whether through merger and acquisition or simply restructuring activities, an orchestrated approach to helping ensure that communications are timely and contain sufficient detail to be viable is key. There are regulatory implications that often gate corporate news if it can in any way effect stock value. Given that, the PM must, with the stakeholders, plan well in advance the distribution of what details will be made available to which resource groups. The entire team must be unified in its direction. However, when businesses merge, the resulting head count is sometimes less than the sum of the originating organizations. Looking again at the primitives, a determination must be made as to who will remain as a service desk agent, where will their workstation be located, and when are they expected to be ready to engage once again as a fullfunctioning Level-X service desk agent.

One of the best indicators of success is when, the business unit manager asks, Didn t IT make that service desk consolidation this weekend? Measure success through the eyes of the customers As the criteria by which success will be measured are defined, it is imperative that at least some perspective is kept on keeping the trains running. If, for instance, your service desk may be a link in the chain of restoring service to an operating room attempting to retrieve drug interaction data from a corporate database, and normal service is constrained due to a consolidation/relocation activity, well let s just say that business must still operate and agreed to levels of service must be provided as best as possible. All the standard PM metrics still apply, but it is the business that must continue to operate. This then should be the focus of the stakeholders in any consolidation project. Once again, that disaster recovery plan may need to be brought out and dusted off to help ensure no time is lost in delivering service it s okay, it needed to be updated anyway. Throughout the course of the project, as risks are identified, anything that can have an adverse effect on Service Level Agreements (SLAs) must be noted and a decision made as to what will be acceptable for the time period when there may be a negative impact. If, during the actual physical consolidation activity, business were to experience a constraint of service condition, it may be in the best interest of IT and the business units to discuss mitigation steps prior to the event. One of the best indicators of success is when, following your physical consolidation/relocation, the business unit manager asks, Didn t IT make that service desk consolidation this weekend we didn t experience any change at all?

It is critical to identify risks for each of the processes, tools, resource groups, and data exchanges. Some risk situations will, most likely, show a strong resemblance to disaster-like conditions. Identify any risks for tools, people, process, and data Each element of the plan has an inherent risk associated with it as the day-today flow of service is exposed to interruption. Therefore, it is critical that the PM and the Subject Matter Experts (SMEs) leading their respective areas of focus identify risks for each of the processes, tools, resource (people) groups, and data exchanges that is to be impacted by the project. As process owners are brought together and they walk through tabletop exercises using their respective process flows, each must validate that sub-process interfaces and data exchanges stay intact throughout the project. This is best accomplished using existing process flows and documentation. Should there be gaps in the flows or documentation, they can be addressed as a parallel or follow-on activity to the consolidation project. Any tool consolidation, upgrade, or replacement must then take the validated flows/documentation and verify that the refreshed tools do not create conflicts or voids in the service flow. Also, this is a good time to note any enhancements or updates that should be made to the disaster recovery (business continuity) plan. Caution sometimes it is the little things that can cause the greatest difficulty. For instance, it is not enough just to verify that the new phone numbers are posted on the Web site, there must also be sufficient effort applied to this activity to verify the numbers rollover from the old to the new location. Also, verification must be made that lines will take the call load of a combined service desk. Plan backup as if prepping for major disaster When the risks have been identified and decisions have been made as to how service support interruptions will be addressed, some risk situations will, most likely, show a strong resemblance to disaster-like conditions. That is to say, the same task sequence used to mitigate a disaster affecting IT services and service support, may be employed for service support recovery during the project. These risk conditions can be identified throughout the project and start as early as defining the scope and as part of task verification during work breakdown structure (WBS) activities. Do not lose sight of the SLAs that are to be supported throughout the project or the sponsor s objectives of the overall effort. Should achievement of SLAs be compromised as a result of project activities, be prepared to engage in recovery actions for the current tasks and somewhat closer scrutiny for the remainder of the project.

The Risk/Frequency matrix that dictates the amount of focus a specific task or project should receive. Make sure the tasks connect and that outputs support inputs. Detail the project task plan and test it frequently In many service provider environments where things can sometimes go wrong, there is the Risk/Frequency matrix (as shown below) that dictates the amount of focus a specific task or project should receive. For instance category C activities that are Low Risk and Low Frequency are those activities we perform regularly that have limited impact associated with them. Activities such as volume name changes, calendar updates, address changes, server upgrades, etc. Category D activities are those that are low risk and high frequency, in other words, tasks that are not risky and are done all the time. At the service desk, that may be the regular barrage of password resets that sometimes plague an organization. Category B activities are high risk and high frequency. These are the tasks we perform regularly but know to watch very closely. Security authorizations, for example, to access new repositories require significant scrutiny as they should. And category A activities are those that are high risk and low frequency. This is where significant attention must be focused. It is here that we must plan well and test the plan often. When we consolidate multiple service desks, an activity we don t do very often, it can have a major adverse impact. Hence, the need to connect the dots. As the WBS is created, and tasks are prioritized, make sure the tasks connect and that outputs support inputs. High A B Risk Degree of impact if activities do not complete as planned C D Low Frequency Number of times this activity has been performed High

Doing things right is good, but we must also do the right things. Satisfy the sponsor s objectives for the project A key role the PM plays is to ensure the team is made aware of the sponsor s and the stakeholder s project objectives. Knowledge of these targets is what makes for effective decisions, by all team members, throughout the course of the project. As has been proven repeatedly in IT projects, doing things right is good, but we must also do the right things. It is appropriate when documenting the project objectives, to assign an individual the responsibility of validating that the objective can be realized given the defined project tasks. Additionally, as the assigned resource, they ll maintain a perspective of ultimate achievement, throughout the project. This will allow the PM to minimize surprises. Also, there is a much better chance of course correction being of value if executed early enough in the process. At project closure time these defined objectives become major communication points in articulating the value of both planning and project management. Reassigning resources to other tasks is distracting and harmful to a project. Protect project schedule integrity by securing staffing resources that are dedicated to the project Those individuals with architect and technical skills who have well established business unit relationships are always in high demand. What is distracting and harmful to a project is to have assigned resources reassigned to other tasks. Reassignment of resources should also be part of the risk and the associated mitigation plans. It may be more appropriate to engage contracted resources to join the project team to complete specific tasks and have high demand resources engage in a role that is consistent with the amount of time they can dedicate to the project. The potential that they can be pulled from the project, either temporarily or for the duration is real and necessary in any organization. Their wealth of expertise is often best used in an oversight role where they can see multiple tasks and the associated interactions and exposures.

There really is no replacement for testing or practice. Make mistakes early using table-top drills Practice, practice, practice. It is true for entertainment performance as well as service support. The elements of performance and the theater in which it takes place is not relegated to entertainment alone. We sometimes use the analogy of the orchestra to articulate the intricacies associated with task relationships. Well, just like a good orchestra, it takes practice. That means with each other and with the score (for us that would be the task plan). Dependent on the magnitude of the effort it may start out with sections practicing together before the whole orchestra ever comes together to run through the music. For a service desk consolidation effort, this means that it is imperative for the PM and SMEleads, at a minimum, to go through table-top exercises and execute all the steps to help ensure, as best as possible, that nothing is left out and that the sequence is correct. There really is no replacement for testing or practice. Summary All the tools, examples and analogies in the world will not take the place of effective planning when it comes to completing a series of tasks. However, tools allow us to work smarter instead of harder. A service desk consolidation or relocation is not without exposure, but the potential of providing better customer service is worth the effort. For more information To learn more about IBM Global Services and our service desk, please contact your IBM sales representative or visit: ibm.com/service

Copyright IBM Corporation 2005 IBM Global Services Route 100 Somers, NY 10589 U.S.A. Produced in the United States of America 06-05 All Rights Reserved IBM, the IBM logo and the On Demand Business logo are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. Other company, product and service names may be trademarks or service marks of others. References in this publication to IBM products or services do not imply that IBM intends to make them available in all countries in which IBM operates. G510-6476-00