Leadership: The Four (Not Three, Not Five) Principles of Managing Expectations

The worst day in Joe Eng’s career was the day he told his CEO that his company’s most important IT project—a $500 million, state-of-the-art global network that is among this decade’s most important IT initiatives in the financial services industry—would be three months late.

Eng is CIO of the Society for Worldwide Interbank Financial Telecommunication (Swift), a financial industry-owned cooperative that supplies messaging services and software that most of the world’s banks use to send trillions of dollars in financial transactions daily. In February 2003, Eng and his team were testing the backbone of SwiftNet, the new network. With only a week before the two-year rollout of SwiftNet was scheduled to begin, the network monitoring software was not working reliably. Fixing the problem would take a few months. Eng’s boss, Swift CEO Leonard Schrank, had to know.

And so Eng called Schrank at headquarters in Brussels with the bad news. Schrank was incensed. The last time Swift replaced its network, in the 1980s, the project was years late, and Swift’s banking customers hadn’t forgotten. What would they think now?

“The problem had a very visible repercussion,” Schrank says. “This was like delaying a space shuttle launch, with all the political pressures.” Eng endured Schrank’s grilling.

But the pain was short-lived. By the end of the 10-minute call, Eng had explained the problem, offered a solution and reset Schrank’s expectations for when SwiftNet would be ready. He would do the same thing a few weeks later, when he was called on to repeat the story to Swift’s board of directors. Three months later, with SwiftNet fixed, the rollout began, just as Eng had promised.

Eng’s encounter with Schrank may have been his most difficult moment, but there were many instances during the six-year project when Eng had to define—and then redefine—what he would deliver and when. For many CIOs, their toughest challenge is managing the expectations of senior executives, end users, IT staff and employees across the company, and the failure to address constituents’ expectations undermines CIOs’ credibility. In fact, expectations management can define whether or not your IT department is successful. (“Managing expectations” is one of five must-do items identified by CIO’s editors as part of the Leadership Agenda 2005 series.)

In Eng’s case, Swift IT staff, business leaders and its 7,800 shareholders (who are also Swift’s customers) all had their own ideas about what SwiftNet should be. Eng couldn’t possibly accommodate everyone’s demands, or predict every problem that might crop up.

But he could be prepared to deal with them. Eng knew that managing expectations for SwiftNet would require frank communication, creative planning and deft diplomacy. He devised a strategy that included training internal IT staff and other employees about SwiftNet and its goals, providing choices to customers without compromising standards or efficiencies, and satisfying board members and executive staffs within defined parameters.

“I understood that the project had to do with understanding the stakeholders and what their needs were and being flexible enough to meet them without straying too far off course,” Eng says. “It’s a sensitive balancing act.”

A High-Stakes Project

SwiftNet was no minor upgrade. It represented a multigenerational advance in telecommunications technology that the global financial industry required in order to operate in the future. Global competition means banks need to close financial transactions in near real-time (rather than waiting days sometimes) and to offer new network-based services. Swift provides the primary messaging and transaction network that makes international finance possible.

Swift’s 7,800 customers in 200 countries generate millions of messages daily in order to conduct trillions of dollars in transactions. These transactions range from the simple, such as exchanging foreign currencies, to the complex, such as clearing securities trades.

Swift’s legacy network, built on 1980s X.25 technology, was an aging, albeit dependable, workhorse. But manufacturers who supplied hardware for the network were closing out production of their old products. Furthermore, the cost of maintaining the network, at nearly $60 million euros a year, was increasing—costs that were passed on to customers. Most importantly, financial institutions wanted new messaging services that would allow them to offer Web-based products to their customers, decrease financial risks and lower their operating costs. One service the banks wanted was instant messaging that would alert them when a transaction was completed. Other customers, including John Galante, CTO with JPMorgan Worldwide Securities Services, needed more bandwidth to deal with a growing volume of securities trades.

The project had numerous risks, not the least of which was that any malfunction of SwiftNet during the migration would disrupt transactions and cost customers money. “The biggest challenge was how do we do this conversion while we support the ongoing business,” says Galante. Mistakes held the potential to bring international finance to a halt. “If SwiftNet were down a day, we would have a worldwide crisis,” says Mike Fish, deputy CIO for Swift. Swift executives worried that any major failure would encourage customers to abandon SwiftNet for Internet services offered by telecommunications vendors.

Eng knew, however, that conflicts and problems were inevitable. “I knew [managing expectations] was going to be my number-one job, and I needed help,” Eng says. He found it in a set of four principles for ensuring that everyone understood what they had to do, what IT would deliver and when.

Principle #1 Define Expectations Internally

Eng set as his first task making sure his staff understood why new messaging technology was needed and how they would approach designing, building and deploying it. Previous projects, including the last network upgrade, had fallen short because the IT staff spent too much time debating technologies and approaches to development.

Eng assembled a cadre of senior and middle managers from throughout the company whom he thought employees admired and trusted. If these managers bought into a common approach to the project, the staff would take their cues from them. The debates about technology and deployment strategies would be minimized.

“I needed these vanguards out there in the company selling the idea of change because I spent a lot of my time working with executive management, the board and customers,” Eng says. “[And] I just didn’t have the time.”

Eng is an Apollo mission buff and an avid reader about the subject. The astronauts in the Apollo program, as portrayed in Tom Wolfe’s 1979 book, The Right Stuff, had developed strong communication skills, along with an ethic of teamwork and trust. Eng sought to replicate their camaraderie, and so, working with Swift’s human resources director, he devised a leadership training program (which he called The Right Stuff) to impart the necessary skills to his management team.

In keeping with The Right Stuff theme, Eng borrowed the famous line, “Failure is not an option,” from the 1995 movie Apollo 13. The IT shop adopted the line as its motto, and it soon became a guiding principle within Swift. The expectation was set: When problems cropped up, the IT team would manage them and learn from them without letting the project get derailed.

On past projects, there had been little collaboration within the IT department or across Swift’s business functions, so Eng sent his first class of trainees (mostly those decision-makers involved in the design, architecture and operations of SwiftNet) to NASA to learn teamwork. At the US Space and Rocket Center in Huntsville, Ala., they rode in a space shuttle simulator for a team-building exercise, and NASA staff taught Swift managers how to make decisions quickly. Astronauts Wally Schirra, Dave Scott and Alan Bean told the group about trusting their colleagues.

The class returned to work with a plan for building a cohesive project management group by creating flexible teams for design, operations and testing. The managers also reworked the way Swift’s IT department measured performance. Rather than measuring the amount of time spent on specific tasks, managers would measure the results of the work.

The Right Stuff group also instituted town hall meetings twice a year at locations worldwide, where speakers from across the company helped allay fears that SwiftNet would not deliver the services users needed or that the IT staff was out of touch with those needs. “What this did was narrow and align people’s expectations to a common set,” says Eng.

Principle #2 Establish Rules of Engagement

Eng knew that if he tried to satisfy too many stakeholder requirements for SwiftNet he would end up with a mess.

Most customers felt strongly that they needed everything they wanted, and they expected Swift to accommodate them. Rather than debating every idea with every customer, Eng decided to develop SwiftNet through pilots with a subset of representative customers. Whatever functionality was built into the pilots became the basis for SwiftNet’s requirements. The pilot customers understood what to expect from the system because they had been involved in deciding what they would get. They could then effectively manage the expectations of other customers by becoming public supporters of the system they helped build.

For example, Eng and his team used the pilots to determine which platforms SwiftNet would support. They settled on three platforms that would accommodate the largest percentage of customers while keeping the system cost-effective: Sun Solaris, IBM AIX and Windows (for smaller banks). By standardizing on these platforms, Swift was able to oblige 80 percent to 90 percent of its customer base.

While Eng had never promised to support everyone’s legacy systems, that didn’t stop customers from lobbying for their unique platforms. “They came in waves,” Fish recalls. “At meetings, there were people pulling board members and our people aside to say, ’Hey, I know you can’t include everything, but we have a VAX. You have to make it work with that too.’” Pressure to add requirements also came from within Swift, as the marketing and sales staff pushed for services they could sell to customers.

Eng managed all of these requests by using a standard process for determining ROI. The litmus test for a requirement was whether it had a positive ROI for the customer. If it didn’t, Eng’s staff would point out the requirement’s downsides, and most customers would agree that the consequences were not worth the effort. Another argument Eng and his staff employed was to explain that the requirement could not be done technically or within the given time frame (he might agree to put off the requirement for a later release).

The bottom line was that the new messaging services had to benefit the vast majority of the banks. “I would say, If you can show me how to justify it, then we’ll do it,” says Eng. Using this approach, Eng and the IT staff settled on the services and messaging capabilities the new SwiftNet would offer.

Principle #3 Deal with Doubters

The CLS Group, a foreign exchange service based in London and one of Swift’s bigger customers, was one of the participants in a SwiftNet pilot. As the day approached to launch the pilot, CLS executives were getting nervous. Testing of SwiftNet had produced the inevitable bugs and glitches, and CLS began to second-guess whether the network would be as reliable as Eng had promised. They weren’t even sure who exactly was responsible for setting up interfaces between CLS’s platform and SwiftNet—Swift or CLS’s operating systems vendor, IBM.

CLS executives wanted to clarify responsibilities for the project, so they asked Eng to meet with them and IBM. “There would have been no second chance if it could not be shown that the end-to-end system worked effectively,” says Rob Close, group CEO at CLS (he was then the chief operating officer).

To prepare for the meeting, Eng asked the project manager and technical director to find out whatever they could about how IBM viewed its role in the project. He also made himself aware of the source of the confusion (a disagreement about what was causing the problems during testing—IBM’s application or SwiftNet’s difficulties interfacing with IBM). “I didn’t want to be surprised, and I wanted to be honest and stick to the facts,” Eng says. After numerous meetings, Eng clarified Swift’s and IBM’s responsibilities for the deployment.

CLS executives were satisfied. “Joe showed a sense of pragmatism and goodwill to find the way forward in what otherwise could have been a difficult circumstance,” Close says.

Principle #4 Not Everything Is Negotiable

Finally, in the summer of 2003, SwiftNet was ready to roll out, and Eng came face-to-face with an expectation from customers that was nonnegotiable. He had to meet the deadline for deployment.

Eng had wanted to recapture the time he lost earlier in the year, when he was sidetracked by the network management glitches, as well as build in time to deal with complications. To compensate, he wanted to move the completion date for the rollout from December 2004 to mid-2005. He was concerned that Swift’s largest users would need 18 months to migrate to the new system. Banks had to follow a complicated process to migrate to SwiftNet that included deploying a pilot before they would be ready for full operation.

But slowing down the rollout wasn’t an option, according to Y.B. Yeung, head of information technology in the Asia-Pacific region for Hong Kong & Shanghai Banking and a member of Swift’s board of directors. “Any delay would be a sign that Swift was not meeting customer demand,” says Yeung, who chairs the board’s technology and policy committee. Galante adds, “Holidays, planning for disaster recovery, regular system upgrades took time. If anything, we wanted to go faster.” Eng went back to his staff with the message that the deadline was not moving.

Within two months, Eng presented a new deployment plan that both met the deadline and addressed his concerns that banks have enough time to get the migration right.

Eng’s original plan was to assign countries to “windows,” in which Swift’s smaller customers in each country or region had a set time to migrate to SwiftNet. Large customers had their own migration schedules. To make up for lost time, Eng devoted additional resources to quality assurance before the migration began. In addition, his staff found ways to add the large customers to each country window or overlap the beginning and end of each window so that more banks were migrating at a time. To simplify the process for ordering services, Eng’s team created an online application for customers to place their orders.

The migration was completed on time, with no notable problems, according to Yeung. Yeung gives Eng high marks for his responsiveness to customers. “He says, ’I hear what you are saying,’ and then he goes back and sees if there are ways to meet your needs. That way he [is] innovative in identifying solutions.”

In other words, Eng and the IT department succeeded and earned credibility by effectively managing stakeholder expectations.