[image: McKinsey Quarterly] <http://www.mckinseyquarterly.com/> [image: management] Interview * Building a global IT organization: * An interview with DPWN's managing director for IT
Stephen McGuckin explains how the company consolidated its IT operations and developed a unique model for outsourcing and offshoring. Michael Bloch and Marcus Schaper Web exclusive, May 2006 Few companies have as much on-the-ground familiarity with remote locations around the globe as Deutsche Post World Net, the corporate parent of Deutsche Post and DHL, a logistics and parcel delivery business. So perhaps it was natural that DPWN would emerge as a leader in the creation of a globally connected IT-development and operations model that has consolidated many of the company's once-fragmented application-development and data-processing locations into three supercenters, in Cyberjaya, Malaysia; Prague; and Scottsdale, Arizona, in the United States. Along with some outsourced help in India, these facilities keep DPWN's IT operations and development running around the clock. They are complemented by another application-development center, in Bonn, Germany. Getting to such a high degree of consolidation wasn't easyor fully planned. DPWN's managing director for IT services, Stephen McGuckin, who over the past decade has held a series of senior IT positions at DHL and its parent, didn't set out to create a 24-hour IT-development and operations program when he began consolidating the company's Asian IT centers, back in 1997. His goal then was to reduce costs and to improve the productivity of a host of IT-development locations for specific countries. After a thorough study of the possibilities, he chose Malaysia as the most central and economical. Working with the Indian IT-outsourcing company Infosys Technologies, he consolidated much of DHL's IT staff in Asia at the new location and outsourced many activities previously undertaken in house. The lessons learned from that first offshoring experience, and its demonstrable success in terms of both cost savings and improved productivity, were essential when the program was replicated in other continents. The consolidation of the IT centers led to the current model, with its three large IT centers. In the process, McGuckin overcame deep skepticism from many of the company's other top executives, maintained an unwavering focus on not only the cost but also the business benefits to be gained by consolidation and outsourcing, and learned how best to manage an outsourcing vendor in a complex environment. McGuckin discusses the lessons he learned along the company's path to consolidation and outsourcingfrom the first moves to locate an application-development center in Asia to the current global-development modelin an interview with Michael Bloch, a principal in McKinsey's IT practice in Paris, and Marcus Schaper, an associate principal in the IT practice in Hamburg. The *Quarterly*: Can you explain why IT is so important for the logistics industry and for DHL and Deutsche Post in particular? Stephen McGuckin: It's very simply summarized in one sentence: the information is more important than the package. Customers understand that the physical network can break down. You can have planes delayed, trucks tied up in traffic, or bad weather that delays the physical shipment. But customers won't accept it if the information system breaks down. They won't accept it if you don't tell them that something's gone wrong and give them the opportunity to take some corrective or preventive action. They may still not be happy, but they'll be completely unhappy if they're not informed. So the physical network can work with less than 100 percent accuracy, but the information system has to work all the time. Your javascript is turned off. Javascript is required to view exhibits. The *information is more important* than the package The *Quarterly*: People might argue that IT is easy for DHL because you run a very simple business model where everything is a package. That's not really the case, is it? Stephen McGuckin: Unlike, say, financial services, where the information is the transaction, we have two thingsthe physical consignment and the electronic consignment. It's critical to get those synchronized at the pickup and keep them synchronized through delivery. Consider what happens at a hub, where packages get sorted. When the package is scanned, we have less than two seconds to retrieve the delivery address for the package from the data record so that the sorting equipment can route the package; otherwise it has to be handled manually. If that data's not there, the system won't work. The planes will fly empty. It's tough enough for a domestic shipment. It's harder if it's international, because now we've got to get it through outbound and inbound customs, making sure that we've got the right information across more than 228 different countries, some with multiple customs authorities or points of entry. That all has to be synchronized, and we've got to pay all the duties, and then we've got to prepare the invoices to collect that duty back from the customer. In fact, in some cases that's the simple model. Often we're doing spare-parts logistics and we may get a call telling us that a high-tech piece of medical equipment is broken and they're not sure which part is necessary to fix it. The machine might be in Taiwan and the spare parts in a warehouse in Singapore. So we send a number of parts to Taiwan and clear customs. We pre-alert the engineer at the hospital to say that the courier will be there at a certain time, so that he can meet the courier, look at the parts, and pick the right one. Then we have to reexport the remaining parts, reclaim the customs duty that we paid on the inbound side, and put them back into the warehouse in Singapore. So if people think it's a simple process, they've got it wrong. The same IT intensity is true in our logistics business unit, where we're managing complex supply chainsfor instance, managing inventories on behalf of our customers or handling end-user returns. The *Quarterly*: How did you develop the IT service centers in your round-the-clock development and operations model? Stephen McGuckin: The genesis was back in 1996, when I was managing IT for DHL in the Middle East. We had different organizations in the Far East, Southeast Asia, the rest of Asia, and the Middle Easteach with its own central IT unit responsible for development and deployment in the country data centers and for managing the network that linked those country centers with central databases and switching. The *Quarterly*: The data equivalent of the "last mile"? Stephen McGuckin: Yes, interfaces with local customs, whatever was necessary for meeting local financial legislation, and so on. I was asked to take over as CIO for the Asia-Pacific and the Middle East regions, where we had regional teams in Singapore, Hong Kong, and Bahrain. By the way, the company also had regional teams in London and San Francisco, so IT was headquartered in four of the top ten most expensive places to live in the world. In the Asia-Pacific region, we were also losing about 20 percent of our productivity because people were traveling around the region for internal meetings. The CEO and I decided to consolidate these IT activities, even though the rest of the management team was skeptical. The *Quarterly*: What was the reason for the skepticism? Stephen McGuckin: They were worried that their projects would be delayed or the quality would go down. Really, it was just a general resistance to change. We researched the best place to locate a consolidated IT center where we could centralize much of the application development. We looked at the Philippines, Perth, Brisbane, Thailand, Malaysia, and India, and we also included, for the sake of our analysis, Singapore and Hong Kong. Malaysia came out on top. There was a business-friendly government, there were incentives, and the labor was skilled and affordable. The government there was just getting started with the Multimedia Super Corridor, which I can best describe as an IT-enabled business-development zone with a set of guarantees to businesses that set up there. Two of these were important to me. One was that telecommunications costs would be benchmarked and prices kept competitive with Western rates. Second, there was a guaranteed five-day turnaround to obtain a work permit for a qualified person from anywhere in the world. In some ways, Malaysia was still a difficult sell at that time. The infrastructure for the Multimedia Super Corridor was still being built, and at times there was rationing of water and power. But we managed to bring 30 good people from Hong Kong and Singapore; some of them are still there. And success begets success, so when people saw the good work we were doing there and the infrastructure improving quickly, we found it easier to attract additional specialists. The *Quarterly*: Beyond cost cutting, what did you hope to get from consolidating IT in one offshore center? Stephen McGuckin: While I felt that offshoring the noncritical development activities was a smart thing to do, equally important was the business transformation role that offshoring would facilitate. The challenge with our model was the extended time to deploy new products and services. We could develop a new piece of end-user software, but any requirement to deploy it in 50 different country data centers before we could get it operational would take us 18 months. If we had a single data center and could deploy the software once and make it available to 50 centers overnight, then we could reduce our time to market. The *Quarterly*: DHL has combined offshoring with a significant effort to outsource a number of commodity activities, mostly along the lines of application development. What were you looking for in an outsourcing partner? Stephen McGuckin: One thing that was very important to me was to choose a partner that had a process for transferring knowledge. Many of the companies in India said they could do it, but when I asked for details they were vague. That didn't give me a lot of confidence. But the company that we eventually choseInfosysactually had a detailed, documented process, and that was one reason we chose them. Three months after they started, they had picked up all of the knowledge required. I was also looking for a company with low attrition rates, because it was important to me that, once we had done the knowledge transfer, the knowledge should remain there rather than be lost. Infosys again made the short list because it was the only company, at that time, offering stock options to employees, and it had one of the lowest attrition rates in India. A third criterion was that I wanted to be a reasonable part of the company's revenue, so I could get its attention, but I didn't want it to be totally dependent on me. I was looking for an outsourced vendor where the volume of business that we would offer would be between approximately 5 and 10 percent of the whole. A fourth requirement was that the outsourcing vendor should be flexible in meeting my business model requirements. There are essentially two models for outsourcing. One is time and materials: you hire a team and then it's up to you to keep them productive. The other model is fixed price: you give a detailed specification and get a quote for delivering that project in a particular time frame for a particular price. I wanted both: a stable team but one that would bid for every piece of work, so that the vendor had to optimize the team, not me. We had long discussions about this with Infosys and eventually came up with a unique model that offers a minimum guarantee, which allows them to keep a team in place. They bid for every piece of work we ask them to do. We agree to the amount, and then the minimum guarantee is decremented. We now have a large team working for us at Infosys, and we've expanded our work there to become one of their largest customers. Within a year of the transition, *we had cut IT costs* by 40 percent The *Quarterly*: Can you tell us about the transition from managing employees to managing a vendor's staff? Stephen McGuckin: In my opinion, most outsourcing initiatives fail because the customer does not know how to manage the vendor. Managers are skilled at managing teams of technicians, not an external vendor. They must be retrained. For example, in the beginning there was conflict between my people and Infosys because we would disagree on whether something was a change or just an amplification of a requirement. My people would come to me saying, "This is never going to work. It's hopeless." It took about six to nine months and lots of education before the model really settled down. The *Quarterly*: How did it settle downwith more rigor on the side of DHL in determining its specifications, more flexibility from the vendor, or a little bit of both? Stephen McGuckin: I think a bit of both, but certainly there was more change on the DHL side. Our people learned that they were now managing a vendor and not programmers. We introduced the rigor that we needed in our specifications in order to manage the vendor rather than the informality that surrounds an internal IT department. We also had to learn the right level of outsourcing. We had outsourced everything from high-level design all the way through to integration testing. But after about six months, my team told me we had outsourced too much and no longer had enough visibility into the design of applications. This limited our ability to judge the merits of the vendor's bids. We decided to leave the detailed design with the vendor, but we brought the high-level design and architecture back in house. Thereafter, the team felt it could control things and could really understand whether the outsourced partner was overbidding or underbidding. The *Quarterly*: How did you manage your relationship with the business leaders who opposed consolidation and outsourcing? Stephen McGuckin: We migrated the first services to Malaysia in August 1997 and by October 1997 had our official opening. For that, we invited the CEO and his management team so they could appreciate that there were people there and there was a service delivery capability. We didn't have any loss of service during this transition while we closed down Hong Kong and Singapore and moved those operations. We had some loss of productivitysome projects were delivered later, and there might have been quality problems with them. But when the senior managers started to see the Malaysian operation, their attitudes began to change. It was probably another 18 months before there was complete satisfaction that this move had been a good thing. Before the move, the CEO had seen his IT costs escalating by 15 to 20 percent a year. Within a year of the transition, we had cut IT costs by 40 percent while returning quality and delivery to the levels before the move. So he was pretty satisfied that he was getting value for money. The working model was now starting to show real dividends, quality product was coming out, and we were ready to take things to the next stage. The *Quarterly*: When you became the CIO for the United States, you were not looking for the lowest costs there, right? Stephen McGuckin: I would say that the required skills involved change management. It was not a well-run environment. It was impossible to get a standard process in place, because people would just do things their own way. They were isolated in their little fiefdoms, and you could never actually get to them. There were eight different IT centers. The *Quarterly*: All sharing application development? Stephen McGuckin: All not sharing. All trying to avoid sharing. We had to choose the right location to consolidate these operations. We looked at a number of locations, and Scottsdale came out the best; it had a qualified pool of people and was relatively free from natural disasters. It wasn't, perhaps, the lowest-cost location, but it was reasonably priced. We had considered South America and Costa Rica, but questions about the maturity of the commercial infrastructure and the high price of telecommunications ruled these out. Scottsdale, judged by all the criteria, was best. Unlike Malaysia, where we started from scratch, in Scottsdale we had a small head start because we had about 60 people there; we had some seeds that we could develop. Again, speed of execution was extremely important, so we announced the move in November 2001 and we had the operation up and running by the end of May 2002. The *Quarterly*: Was Infosys working with you on Scottsdale? Stephen McGuckin: Yes, we just executed the same program againbrought Infosys in, got them to do the knowledge transfer, and then we undertook the migration of the higher-value-added activities. Now, this migration was a little bit more complicated because the US was a country site as well as providing support for the Americas region. This was a higher-risk proposition than the one we initially had in Malaysia, but we now had a little bit more experience and brought over some members of the team who had done that sort of work before. The *Quarterly*: Your European IT center, in Prague, is the newest and largest of the three, with more than 1,000 people. How was the European migration different? Stephen McGuckin: In Europe, it was even tougher because we had three big companies merging, each with 6 billion or 7 billion in revenue a year and different heritages and standards. Each believed that its own processes, standards, and solutions were optimal, but no one location was big enough to support the data-processing requirements of the combined and growing DHL business. We looked at finding the European location as a procurement exercise. And Prague was the optimumlike Scottsdale, not the cheapest, but the best in terms of English-language speakers, air links, the capabilities of the local workforce, and the receptiveness of the Czech government. The *Quarterly*: Some people said that when DHL went into Prague and hired 1,000 IT people, it would dry up the labor market and wage rates would rocket. Stephen McGuckin: This was obviously a concern, particularly since the Czech Republic was due to join the EU, which many people expected to result in increased labor costs in the region. However, I didn't see how an increase in the supply of labor in the EU would result in a price rise. It seemed pretty safe to me. The *Quarterly*: Still, hiring 1,000 people in a few months cannot have been easy. Stephen McGuckin: When we announced our plans for a large IT-development center in Prague, we had a big official signing. We blitzed the papers and had advertisements in the trams, so we got the maximum publicity that we could just before we started recruiting. We had job fairs in Prague, in Ostrava, Brno, Bratislava, and a few other places. Actually, we have more than 45 different nationalities working in Prague. We were able to attract a significant number of Czech nationals who were working abroad and looking to come back home and find highly challenging jobs. The *Quarterly*: Do you see any limits to the model? Stephen McGuckin: No, I don't see any limits. I think we won't hop about as frequently as companies do in the manufacturing world. I think there may be a time when we move again, but I look at it as a ten-year horizon. I think you want to get in early, get in fast. You can't do this without an element of risk, so you have to be able to identify and manage the risks. But if you're not prepared to identify and manage those risks, you'll never move, because moving will just seem too big a job. About the Authors *Michael Bloch* is a principal in McKinsey's global IT practice. He is a leader of the outsourcing and offshoring practice and is based in Paris. *Marcus Schaper*, an associate principal, specializes in managing the performance of IT, particularly software and applications. He is based in Hamburg. This article was first published in the Summer 2006 issue of *McKinsey on IT *. Site Map <http://www.mckinseyquarterly.com/site_map.aspx> | Terms of Use<http://www.mckinseyquarterly.com/terms.aspx>| Updated: Privacy Policy <http://www.mckinseyquarterly.com/privacy.aspx> | mckinsey.com Copyright (c) 1992-2006 McKinsey & Company, Inc. [Non-text portions of this message have been removed] Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/Indo-Linux/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
