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 Centre in Huntsville, Alabama, 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.