How J.P. Morgan, Chase tied the IT knot

The merger of Chase Manhattan and J.P. Morgan in December 2000 created the second-largest U.S. bank, with $800 billion in assets. The formal announcement was just the starting gun in a race to mesh together the pieces and build a leading financial institution.

Merging these institutions involved a massive effort to identify each heritage company's "centers of excellence," to reduce complexity and inefficiency and to reconcile different approaches to business. The two companies had thousands of employees as well as operations that spanned more than 50 countries. Chase was both a retail and a wholesale financial services firm, Morgan a wholesale one. Their cultures, too, were distinct.

Leadership of the overall merger effort was driven by a worldwide team of executives, including Thomas Ketchum, who before the merger had overseen technology, operations and finance as Morgan's chief financial officer and chief administrative officer.

To centralize and streamline the company's more than $3 billion in information technology infrastructure, Ketchum tapped John Schmidlin, a former J.P. Morgan technology and operations executive. Over the next two years, J.P. Morgan Chase created a new IT infrastructure organization and achieved cost savings in excess of 15 percent. Schmidlin also led the company's groundbreaking $5 billion, seven-year technology-outsourcing deal with IBM. The 2002 agreement calls for Big Blue to manage much of the organization's IT infrastructure, including the data centers, distributed computing and data networks.

In July 2003, Ketchum announced his retirement, and Schmidlin was named his successor. Schmidlin is now head of the company's technology council and serves on the company's executive committee. The two men discussed their merger and IT transformation experiences.

Tom, what was your hypothesis about technology when you took over responsibility for it in 2001?
Thomas Ketchum: Our CEO, William Harrison, had asked the merger team to pay particular attention to technology because of the huge impact it has on our clients, and because it was going to have the longest tail in achieving the merger's benefits. In the very early stages of integration, we saw big savings, but we also saw well beyond that. Technology is an enormous competitive differentiator for any large financial services firm. We had to lay the groundwork for a continuing IT transformation that would create a world-class function within a financial services leader. The merger had created a firm with the scale, capital and talent to do just that.

Where did you begin?
T.K.: We wanted to put together something new that wasn't J.P. Morgan or Chase but was a combination of the best of both heritage firms. The immediate challenge was to sort that out. In the first meeting of IT managers, who came from both firms, we saw clear similarities and differences in our operating models and in the basic economics for managing IT. So we started out taking an objective, fact-based look at the issues.

John Schmidlin: We also put a governance structure in place that brought our best technology people together and ensured that senior business executives would exercise oversight.

Everyone sitting around the council table came with great experience and a point of view. But thanks to our governance structure, we were able to move discussions away from heritage models and people and to focus on facts. The immediate cultural awakening was about costs. Smart people have a way of examining the facts and saying, "What are we going to do about this?"

So you brought together a new governance structure. How did you and your team make important decisions about the merger?
T.K.: We started working together very early on. For example, we had to make choices about a couple thousand applications to decide what was going to survive and what was not. We had to move fast, and we had to make sure that any changes were completely transparent to our clients. Our approach may be a little unusual: We decided which applications to keep before we decided which technology people to put into place to manage them. We took a fact-based approach about the application functionality that best supported each business, and we said whoever was appointed as leader of a function had to implement these decisions.

That created a lot of discomfort, as you can imagine. But it worked. Our transparency and objectivity gave us credibility with our peers, and successful execution established a track record for delivering on our promises. This created a foundation for us when we worked with business and IT leaders to make post-merger decisions, including centralizing the infrastructure.

How did you use a similar approach in centralizing the organization's infrastructure?
J.S.: We got everyone together, and we focused on facts. It was very compelling to chief information officers and business executives to see opportunities for savings of greater than 15 percent. So then the discussion was, "If you buy this, you also have to buy into a new infrastructure governance framework and operating model," which called for centralizing a lot of the technology infrastructure and defining new-line business interfaces into the infrastructure organization.

The combination of economic benefits, transparency and a well-thought-out operating model convinced these people, along with the self-funding nature of our process--the opportunity to plow savings into investments for growth and innovation. We also talked with the executive committee members individually beforehand. As we started to centralize, we gave both technology and business leaders regular progress reports and communicated regularly with the entire IT staff.

T.K.: As John says, there were two dimensions to the communications piece of that effort. For us, it was about working our partner relationships with the senior management of the firm to make certain that everyone was on the same page. But we also were very careful to communicate with our people, to tell them what was going on and why and to admit that we didn't have all the answers but would continue to keep them updated as we figured things out. We were promising them that we would get the right people in a room and make decisions as fast as we could and be as fair as we possibly could. We wanted to make sure that we weren't springing any surprises on our people.

So you centralized the infrastructure. What about applications? How much centralized management went into this?
T.K.: Very little. Our belief was that most strategy setting and execution for technology should reside in the businesses. We call it the 80/20 rule: 80 percent in the businesses and 20 percent we could influence centrally. That was our model.

Is the 80/20 rule still useful to you, now that the merger is complete?
T.K.: Absolutely. Applications development is a good example of how that operates. We believed that applications development should be embedded in the line businesses--with the businesses accountable for it. Each of our line-business CIOs has undertaken systematic efforts to drive out costs and to become more effective with the business. At the end of the day, the businesses are responsible for the end-to-end cost of their technology.

But that doesn't minimize the importance of the 20 percent the council owned. Excellence in applications development is a multiyear, firmwide effort. Now that we've entered the transformation phase of IT, we are aiming at a lot more than cost savings--such as creating a simpler, more productive, better-managed environment; a stronger foundation to support innovation and growth; and greater clarity for our people on developing their careers.

Behind those long-term goals are specific initiatives. They range from architecture standards and global resource strategies, including the use of offshore talent and fundamental improvements to our development processes, such as the use of Six Sigma and CMM1 and building a standardized tool set for managing the applications environment.

You consolidated the IT infrastructure, cut its cost drastically, and then outsourced a significant portion of it to IBM. What did you seek to gain by outsourcing?
T.K.: From the start, we made it clear to everyone that outsourcing wasn't just an expense reduction effort. There were a number of things we wanted to get out of this. We set out a range of criteria and made them clear both to the vendors we were talking with and to our people internally. We said, "This is what we're looking for," which included world-class technical solutions, business resiliency, variable IT costs rather than the fixed costs of owning infrastructure and access to vendors' IT talent and innovative ideas. All those had to pan out. We had to have a much more comprehensive story to tell than just cost reductions. And I think that was well understood internally.

People were uncertain about outsourcing. It was a very big strategic decision. Some top managers of the firm reacted with skepticism. They said, "We already have scale ourselves, so why would we do this? The vendors have to make a profit, so after their margin, how do we get serious cost reductions out of this? We lose control. There's no turning back." There were a lot of questions.

How did you address them?
J.S.: Just as we had earlier addressed the infrastructure-consolidation issues--get the facts on the table, do a lot of communicating and rely on our track record in streamlining the infrastructure since the merger. We couldn't have gone to outsourcing without the track record we had already compiled.

The vendors also helped us with the communications process. The CEOs and top people from both vendors that were finalists in our deliberations came in at least twice to meet with the executive committee and answer questions. The keys to this process were, again, the governance and operating model as well as our leadership team, which gave us the foundation that made the outsourcing decision possible. This was not just a technology decision but also a business decision.

T.K.: Right. Another critical variable here was that we went into the decision process with a clear sense of how much improvement we could do internally. In a lot of instances, as you know, companies decide to hand over a mess to a provider: "We'll let the provider sort things out, and we'll get 15 percent to 20 percent cost savings." We didn't do that. You leave money on the table that way. So we wanted to do our homework first. In the end, we had a very strong fact base for what we knew we could do ourselves, and we told vendors, "You have to beat this by a wide margin, not just overall but every year."

Who did the homework--IT or the businesses?
J.S.: Both. The line businesses participated in the vendor assessments. We had teams looking at things like distributed computing, networking and so on. The technology leaders who represent the line businesses participated in the ratings of the vendor proposals and capabilities. Everyone was involved in assessing who was better in each category. The tech council was involved every single month. We kept the executive committee apprised of our progress, and it provided input to the team. It took a year to reach a decision.

An important factor in this decision was how best to treat our people. We had people who would be let go as we became more efficient. Outsourcing vendors like IBM, Electronic Data Systems and Computer Sciences were in fact pulling people in--they needed people on the financial services side. So we had 3,000 full-time people and 1,000 consultants who became employees of IBM, and IBM was delighted to gain the experience and skills of our people in one swoop.

How did you keep senior business leaders and executives involved? How did you get them comfortable with this?
T.K.: John personally spent an enormous amount of time gathering facts and then sat down with line- and corporate-business leaders to talk about the issues and listen to their concerns. It takes a lot of discussion to get people comfortable with a transformation of this nature. And they involved themselves. They're smart businesspeople. They had a lot of questions, and they asked them.

For more insight, go to the McKinsey Quarterly Web site.

Copyright © 1992-2003 McKinsey & Company, Inc.

Interested in more research studies like these? If so, free registration at The McKinsey Quarterly will offer you topical alerts, monthly newsletters, and access to selected full-text articles. For premium membership, which offers full access to the McKinsey Quarterly site and the print edition, click here.