Operational Lessons from a Strategic Sourcing Project

Good Ideas
Operational Lessons from a Strategic Sourcing Project
© 2008 Adam Krob. The text of this article is licensed under the Creative Commons Attribution-NonCommercial-No Derivative Works 3.0 license (http://creativecommons.org/licenses/by-nc-nd/3.0/).
EDUCAUSE Quarterly, vol. 31, no. 1 (January–March 2008), pp. 66–70
Tulane University found partnering for help desk support both necessary and satisfactory, with the added benefit of operational lessons learned through the process

Sourcing decisions for information services departments have become an integral part of every school's IT strategy. Much has been written on what areas to outsource, which partner to select, and how to negotiate contracts and service agreements. This account focuses on a different area: the operational lessons we learned at Tulane University during the first few months of our partnership with a company providing first-level technical support for the campus community.

Why We Partnered

It is important to explain Tulane's goals in establishing this partnership. The decision to find a firm to handle our first-level help desk support was based on two very different but overlapping reasons, one intensely practical and the other strategic.

Practical Motive for Partnering

One of the most destabilizing effects of Hurricane Katrina (which continues to impede our recovery) was the sudden and massive departure of staff following the storm. After Tulane decided to return its technology support group to New Orleans in November 2005, the help desk lost three of the seven full-time staff members employed before the storm. We moved staff from other areas of the university to the help desk for nearly a year, but when Tulane's medical school returned to New Orleans in June 2006, we lost these staff to their old positions. In the span of two weeks, our help desk staffing level dropped from six full-time staff to two, and call answer rates fell to an all-time low. The week before our technical support partnership launched, Tulane's internal help desk answered fewer than 60percent of incoming calls, and members of the Tulane community reported wait times of more than an hour.

Given the psychological stresses encountered by Tulane community members returning to New Orleans—negotiating with insurance companies, navigating government bureaucracies, and finding daycare for a child or an open grocery store—we felt it was imperative to make technical support as easy as possible. Not only were our faculty, other staff, and students experiencing these stresses, so were our IT staff members. The continued personnel loss left the remaining staff with an increased workload. Unfortunately, the decline in qualified applicants willing to come to (or stay in) New Orleans after Katrina resulted in an extremely tight labor market, hampering the search for new staff to meet our immediate need.

This reason for pursuing a partner to provide first-level technical support is relatively unique, of course. The labor market that Tulane (and New Orleans, more generally) faces today is not representative of markets elsewhere in the United States. If the widely predicted demographic crisis comes to pass, however, many other schools and colleges will face similar labor shortages in the next 10 years.1 Where to focus human resources will become a critical decision, one that Tulane had to face sooner than expected.

Strategic Motive for Partnering

The second reason we decided to partner with a commercial firm to provide first-level technology support was strategic. We have measured customer satisfaction for different services for some time. Data show that our staff has been most successful in providing face-to-face services, scoring nearly 5 out of 5 in three categories of satisfaction: timeliness, knowledge/technical competence, and friendliness. We therefore made the strategic decision to invest our limited staff resources in face-to-face services. We moved the two remaining help desk analysts to positions supporting laptop service and second-level assistance in offices and residence halls.Doing so necessitated finding a partner organization to provide first-level phone, e-mail, and chat support.

The decision to partner was strategic in three ways:

  • First, we allocated staffing resources to enhance a strength while looking for a partner to provide services in an area where we were relatively weaker.
  • Second, we focused our time and effort in providing an excellent face-to-face technical support experience.
  • Third, we partnered with an organization that delivered support 24 hours a day, 7 days a week, providing a better fit for the needs of faculty and students.

Providing an excellent technical support experience has a positive impact on faculty, staff, and students, which aligns with university-wide priorities such as retention. Although partnering with a sourcing firm did increase our post-Katrina costs, we considered the extra expenditure justified in light of the service's strategic value and its potential gains.2

Operational Lessons

In December 2006, Tulane began a partnership with Presidium Learning, a higher education–focused support firm located in Reston, Virginia (http://www.presidiumlearning.com). This venture has been educational for us, as we learned a great deal about our operations and how to best integrate them with a partner's operations. Generally, these operational lessons fall into three categories: measures and incentives, processes, and communications and feedback.

Measures and Incentives

The primary lesson we learned about measures and incentives (in both organizations and in the specific project) was the need to be explicit about the metrics used that reinforce strategic goals and how they link to incentive systems in both organizations.

Making measures explicit requires a two-fold transformation of strategic goals to operational incentives. First comes reinterpreting the strategic goals as measurable outcomes. This task was relatively simple given the large number of metrics available to map to our strategic goals. For example, we mapped the average speed of answer and the call answer percentage to the goal of providing a quick response to users. Second is exploring the incentives in both organizations to determine whether they reinforce good performance on strategic operational measures.

The need for this transformation from strategic goals to operational incentives highlights another lesson we learned: on-the-ground managers must be involved in the creation of a sourcing relationship. Operational staff at Tulane and at Presidium Learning assisted in surfacing and reinforcing the measures employed. Additionally, all of them are aware of the incentives and how they support the university's strategic goals.

We went about this transformation in several ways. First, we sought to determine and understand the incentives in place at our partner organization. We already understood the incentives selected at Tulane and the measures they supported, but we had to educate ourselves on Presidium's organizational rewards. One of the first questions we asked was what they rewarded. We had to begin to understand the measures they considered important and how those measures would affect the quality of service we could deliver, together. We saw this synchronization of incentives as essential to developing the partnership. Combining the knowledge of our partner's incentive (and reward) structures with our key measures of success allowed us to determine how to achieve a high level of service.

We identified mutually supporting incentives driven by mutually accepted measures of success, which we included in the contract. We specified service levels, for example, requiring that Presidium Learning agents answer 90 percent of all calls within 120 seconds during normal periods of operation. Given our experiences after Katrina, the time that a member of our community had to wait for a live person was a critical measure.

After we defined the crucial measures of success linked to our project's strategic goals, we needed an incentive structure to reinforce the importance of these metrics. First, the measures are contractually defined, with specific remedies delineated in the appropriate section of the contract. Second, the critical measures of success had to be front and center in the minds of our operational managers and operations staff. We accomplished this by creating weekly and quarterly reports to highlight several different critical measures of success and benchmark our progress against those measures.

These reports are shared with management and operations staff in both organizations. Each week we highlight several different measures that we find important, reporting on progress and emphasizing them in communications. Our reports highlight

  • Number of incoming requests (calls, chats, and web tickets)
  • Number (and percentage) answered, and average time of each session
  • Length of time it takes to answer requests (for calls only), and longest waiting phone call
  • How many requests receive a ticket (as a percentage)
  • Percentage of requests resolved based on total tickets and those deemed resolvable by our partners3

We succeeded in surfacing the measures and incentives that we could jointly support. Important components of the user experience were not reinforced by these existing measures and incentives, however.

At the beginning of our partnership with Presidium, we recognized areas we wanted to focus on, for example the response to escalated requests. We understood that some requests would be escalated to Tulane staff for resolution, but we needed to devise a quality control system that provided feedback to Presidium staff and an incentive for Tulane staff to strive for constant improvement. In addition to the frequent phone contacts between Presidium and Tulane support agents (later accomplished through chat sessions via a Jabber server), we felt it necessary to establish a more formal daily feedback mechanism. We developed a daily routine in which one of the managers at Tulane reviews each escalated request and provides commentary in a spreadsheet (see Figure 1) shared with the account manager and operations manager at Presidium. They share this information with the call agents assigned to Tulane and use it to provide feedback to individual agents as needed.

Figure 1
Click image for larger view.

The feedback process has worked extremely well. We have seen improvements in the quality of information provided when a request is escalated by the Presidium call agents to Tulane staff. In addition, the number of escalations as a percentage of total requests has declined. This system works for several reasons. First, the Tulane manager has an incentive to reduce the number of escalated requests, as the number of requests needing review has a direct relationship to the manager's workload. If the Tulane manager can provide information or expertise to the Presidium agent before or during the call or chat session, then the request will not be escalated and the end user's problem will be resolved more quickly.

Second, the data provided by a daily review of escalated requests help Tulane managers deploy targeted training for Presidium agents (in areas like Macintosh OS support), provide templates for troubleshooting problems (such as wireless network connectivity), and recognize underlying problems early (such as a spam filter rejecting mail from certain domains). This knowledge has led to improved documentation for responding to requests and an overall reduction in the percentage of requests escalated to Tulane.

Third, Tulane managers have made a concerted effort to incorporate both positive and constructive/adjusting feedback in the escalated-request spreadsheet. The results were a bit surprising: some call agents responded to the positive reinforcement by beginning to sign their names to each ticket they submitted (we can backtrack in our systems to see who created a ticket, but the process is involved). This allowed us to openly praise specific call agents while still offering constructive/adjusting feedback anonymously. This feedback system has had a benefit for Tulane staff, as well. It allows us to demonstrate a continuous improvement process, one that emphasizes regular performance feedback as a means to enhance individual (and team) performance.

Although the feedback system has worked well, it highlighted something we could have handled better. When defining processes and procedures, we should have consulted with other IT staff, the second- and third-level support staff in central IT and in distributed IT organizations. Their deep understanding of specific systems and support processes is important to overall success. For example, the support unit at Tulane's Health Sciences Center must know the IP addresses of machines that need to connect to the hospital's medical records system. It took our partners several iterations in the feedback process to start providing these IP addresses, causing delays in giving approved users access to the medical records system.


Two process areas were critical to sustaining and enhancing service at Tulane. First we needed to create a transparent procedure for problem resolution and escalation for all stakeholders, including IT staff throughout the university. In the beginning, we focused on end users as the primary consumers of the outsourced help desk services. We instituted feedback surveys for end users and sent an e-mail to all faculty, staff, and students describing the service and providing a point of contact for complaints. We did not, however, provide enough feedback opportunities for IT staff throughout the university.

Our network services group, for example, became frustrated when the new call center agents did not provide specific locations for wireless access points reported as not functioning. When the help desk call center was located in the same building as the network services group, one of their staff would walk across the hall and ask the agent to provide more information. This easy give-and-take resulted in personal relationships that greatly facilitated communication. Partnering with Presidium made this feedback mechanism impossible. The number of agents assigned to our account (approximately 30) makes one-on-one relationships more difficult, and communicating with an agent can't be face-to-face. We are still working through these issues but have formalized a feedback and escalation process through regular conference calls where IT staff members meet with our Presidium account manager and agents.

The second process area important to our operational success was integrating our partner into our change management process. Consider the following example: We launched a major initiative to upgrade and expand our existing Blackboard installation to include a portal and content management system (Blackboard's Community and Content systems) and to have Blackboard host our installation. We began discussing the support for this new initiative in March 2007, immediately including our account manager. Involving our partner at the beginning of the project allowed us to tap into their knowledge of Blackboard's support organization to design an effective escalation and resolution process.

We have also begun developing a formal change management process. Together with Presidium, we have developed "20 questions for change management," as follows:

1. What is the product? Please provide a short description of its purpose.
2. Is this an upgrade or a new product/service?
3. If it is an upgrade, have you done similar upgrades in the past? If so, how successful were they?
4. Is any routine maintenance or update needed for the new system? If so, who will inform us when these updates are being done?
5. Will there be downtime of other systems necessary in order to install this new one?
6. Who will use the product? How many users do you expect?
7. When will it go into production?
8. Will users be phased in to the new system, or will everyone go online at once?
9. Will users have to download a client or emulator? If so, please provide a link to download it.
10. Does the client require a license? If so, who holds this license?
11. With which browsers and operating systems is the system compatible?
12. Will there be a separate user ID and password for the system (different from the Tulane e-mail user ID and password)? If so, please describe who creates these and who can change them.
13. Does the product require special network considerations, such as a network drop or static IP address?
14. Whom should we contact if the system does not work? Who is the backup? Is there a systems administrator whom we can contact for assistance?
15. Do you have any documentation for this product? Please attach or provide a link.
16. Do you need documentation created?
17. Do you have or are you providing training? Please describe in detail.
18. Is there a website that users have to go to? Please provide a link if one exists.
19. Will users receive a notice prior to launch? Please provide a copy of the e-mail or notice that will go out.
20. Please provide a short statement of the specific services you expect us to provide, along with any service levels that you expect us to meet (for example, transfer calls within two minutes of identifying the problem).

Communications and Feedback

We felt it was important to provide opportunities for time-based feedback for everyone involved in the partnership. At the beginning, we set up a daily conference call that included Presidium and Tulane staff. This regular conference call is now weekly. Conference calls between second- and third-level support, IT staff from schools and colleges, and Presidium take place on a regular schedule, usually once every six weeks. In addition, weekly and quarterly reports go to all parties involved to gauge progress on the measures we set out in the beginning of the relationship.

We also created opportunities for transaction-based feedback. The primary tool we use is the escalation-feedback spreadsheet described earlier. Stakeholders at Tulane have a direct contact at Presidium for addressing complaints or quality issues on a case-by-case basis. This interaction, besides providing a feedback mechanism for stakeholders, reinforces the expectation that IT staff throughout the university share responsibility for making the end users' experience satisfying. We also keep a log of complaints and send an update to Presidium when we receive a complaint.

Steps for Improvement

Our experiences with Presidium Learning fall into three categories that suggest specific steps for improving our partnership. First, we learned that the operational phase of a strategic sourcing project begins before contracts are signed. Operational staff must be involved early to translate strategic goals into performance measures, and then to design reporting systems and incentives to support these measures. This two-fold translation process should occur before completing contract negotiations, as one of the key incentive systems is the service level agreement in the contract. Operational staff should be involved in contract review and, optimally, in the creation of the RFP. Involving these staff members early has several positive outcomes, including their increased investment in the project and a decrease in the uneasiness that naturally occurs when outsourcing support.

Second, we learned that a well-designed feedback mechanism can support the performance measures set out in the RFP and contract. The feedback system should include two different types of feedback: time-based with specific touch points, and transaction-based. The touch points will vary, but time-based feedback should be provided at least quarterly. Transaction-by-transaction feedback, on the other hand, is crucial to learning. Our daily reviews of escalated issues provide that transaction-based feedback.

Third, we discovered more stakeholders in the strategic sourcing process than we first imagined. We found that the second- and third-level support staff were critical participants in the project's success, and we needed to involve them much earlier. We began by focusing too much on the end user as the sole consumer of our help desk services, designing our metrics, incentives, and processes to support the customer contact. We have had to expend considerable effort reengineering these processes after establishing the partnership than we would have had we involved IT support staff from the beginning.


In retrospect, we learned a number of operational lessons from our partnership with Presidium Learning. The lessons in measures and incentives, processes, and communications and feedback have contributed to the success of this partnership and provide a foundation for continued improvement. They also taught us crucial lessons for establishing strategic sourcing partnerships, lessons that could be instructive to others looking to establish a similar model.

1. See Ira Wolfe's Perfect Labor Storm Web site for an excellent discussion of the coming demographic crisis: http://www.perfectlaborstorm.com.
2. The costs of sourcing our first-level technical support from a partner were higher when compared with post-Katrina spending, but only marginally so when compared with the people, hardware (both desktop and telecommunications hardware), and management costs of our six-person help desk pre-Katrina.
3. The resolvable percentage is generated by adding necessary escalations to the number of tickets resolved by our partner firm. We add back tickets that report network outages, hardware issues, or problems where a member of the community requires an in-person visit. This resolvable percentage is a better measure of the adequacy of our partner's first-level support.
Adam Krob (akrob@tulane.edu) is Director of End User Support at Tulane University.