Surviving Toronto

In a memorable scene from the movie Butch Cassidy and the Sundance Kid, those fabled outlaws, played by Paul Newman and Robert Redford, are chased by a posse to the edge of a high cliff above a river. Realizing that their only means of escape is to jump, Sundance mutters despairingly, “I can’t swim.” Replies Butch, “Why, you crazy — the fall will probably kill ya!”

When Jim Andrew became CIO of the new “megacity” of Toronto, he might well have felt like he had just put Sundance’s boots on. And who would have blamed him for viewing the crushing task of getting IT through the amalgamation process with a fatalistic eye? Some might even have been tempted to console him with a Butch-like, “Why, you crazy — year 2000 will probably kill ya!”

It is difficult to contemplate a more daunting scenario for a new CIO. Imagine having to ride herd on all of the following: creating a new unified organizational structure for the IT operations of six large cities (Toronto, York, North York, East York, Etobicoke and Scarborough) and one regional government (Metro); rationalizing and integrating all of the existing technology and applications of those governments; selecting and deploying major new applications and best-of-breed solutions; supporting ongoing business operations; downsizing staff by about 20 per cent; and, lest we forget, simultaneously preparing the entire megacity — not only its traditional computer systems, but also its fleets, buildings, traffic lights, et cetera — for year 2000 (this latter task in the space of a year).

Fortunately for Andrew and the rest of the new city’s IT team, some of the groundwork for amalgamation had already been done. The IT departments of the six cities and Metro had worked quite closely because of a need to share various types of information, such as mapping and financial information. In many areas there had already been considerable standardization. For example, Metro had put in a fairly large network, and when the other cities upgraded their networks they essentially followed the same standards that Metro had selected.

But this information-sharing and standardization amounted to little more than a good start. There was still a mountain of work to be done, and it began well before the official amalgamation on Jan. 1, 1998.

Rolling up Their Sleeves

“Work started officially in May 1997. The groups were all charged with the task of showing how they would amalgamate and consolidate,” said Chief Financial Officer and Treasurer, Wanda Liczyk. “The groups had to answer questions like: What would the new architecture or structure of their operations look like in the context of the new city? What kind of savings and efficiencies did they think could be realized in the short term? What would each of these operating areas look like for the longer term?”

During this period the IT directors of the former cities and Metro got together and responded with a fairly comprehensive plan for IT. Said Andrew, “That plan went forward to the then provincially appointed transition team, which adopted the report pretty much in its entirety. That essentially became our roadmap for us moving forward to the megacity.”

Consulting firm Johnson Smith had been hired to help put the new city and its organizational structure together. The IT organization started working with the consulting firm just as amalgamation took place in January 1998, and over the next several months the new IT model was fleshed out and finalized. Only part of that period, however, was spent on the restructuring process. In reality, it took about 20 days to do the work, interspersed with regular business activities and much-needed periods where those involved in the planning process could evaluate and mull over the major changes that were being contemplated.

Another important activity during this period was the mapping of all of the business activities that IT was doing in the former cities and Metro. “That was one of the biggest challenges, I think,” said Andrew. “Getting all that historical data and mapping it, and then putting an organization in place that would be service-oriented — figuring out what we were going to bring to the new city from a technology perspective.”

A New Model for IT

By June, the team had come up with its new IT model, but not without first getting it critiqued by a couple of independent consulting organizations: LGS and Western Management Consultants.

The model is patterned along the lines of a manufacturing organization. There’s a head-office function that does corporate standards, corporate initiatives, corporate IT strategy and major corporate studies. Infrastructure technology such as networks, desktop tools and telephones are all handled centrally. For service delivery, IT departments are located in each of the business units and they’ve been grouped into different clusters — the so-called manufacturing plants. Those IT departments use common networks and common standards, but they’ve got business-specific applications that they have to support. They report in centrally but do the work decentrally.

Three client service directors, each with two of the city’s six departments to look after, reside in the business units and act as the eyes and ears of IT, both corporately and departmentally. This is a big improvement over the past way of doing things, wherein head-office functions were isolated from the operating departments.

Liczyk likens the client service directors to salesmen in the private sector. “They are the entr