Everyone likes to tell success stories, particularly if the success occurred under your own leadership. But we all have failures and make mistakes. Few of us like to discuss them. I am writing about my biggest failure as CTO, hoping there is a lesson here for others.
I recently spoke to an IT consolidation retreat in Nashville hosted by the Center for Radical Improvement. In 2005-2006 we tried to partially consolidate information technology in the City of Seattle. It failed. Well, let’s say it was “less than successful”. And here is the “rest of the story”.
City government in Seattle has 11,000 employees, of whom about 550 work directly in technology and 215 of those work in the central Department of Information Technology (DoIT) which I lead. We have three service desks, three different radio systems, four large data centers, and at least six different groups providing server support and desktop support. We have at least five different work management systems, and some unknown number of document management systems.
On the other hand, we are standardized in many ways – a single e-mail system, Windows XP on all desktops, Oracle and SQL Server for databases, a single award-winning web presence at www.seattle.gov, an award-winning municipal TV station, one set of connections to the Internet, a single firewall, and a single financial management system and payroll system.
In 2005 the Mayor and I proposed a consolidation of technology infrastructure employees – about 100 employees would have moved from a dozen departments into the central IT shop – DoIT.
It failed. Why?
1. We did not calculate a return-on-investment and a potential cost savings from the consolidation. Such a cost/benefit analysis is essential to proving the case to elected officials. Furthermore, I promised there would be “no loss of jobs” due to the reorganization. I did this primarily because I felt we could re-deploy employees more efficiently to tackle a whole host of new projects. But I was also hoping to lessen the fear of change which is embedded in any organization, especially government, and especially during an impending organizational change. This is a dilemna – in difficult budget times, consolidation/centralization has a strong return-on-investment (ROI) and good support from elected officials, but the ROI comes from cutting jobs, which has a disastrous effect on morale. Yet in “good” budget times, when jobs can be preserved, the support from elected and appointed officials is less compelling.
2. I failed my Mayor. Mayor Nickels made the decision for this reorganization. But I didn’t properly engage him – and his senior staff – in supporting and leading the change. Consequently many employees, department directors and others saw this consolidation as “empire building” on my part – an internal grab for power rather than an honest attempt to improve government. Indeed, a Seattle City Council member openly accused me of “empire building” in a City Council meeting (he later, but privately, apologized for the remark). That meeting is undoubtedly stored somewhere in the vast video archives of the Seattle Channel.
3. We did not get a consultant. Yes, there are many jokes about consultants. And good organizational consultants are expensive. But the blunt fact is simple: a comprehensive look at consolidation by someone outside the organization – a dispassionate outsider – would have greatly improved the credibility of the change. A good consultant would also complete a detailed cost/benefit analysis.
4. A labor union opposed the change. IT professional employees in the Department of Information Technology (DoIT) employees have decided not to be represented by a union. Many of the employees in other departments (who would be consolidated) are currently represented. Those employees probably would have lost that representation when moving. Although the numbers are small here – 35 to 40 employees in a labor union of 2,500 – there are larger principles at stake.
Generally, I believe in centralization of tech infrastructure functions – networks and data centers and computer operating system support. Certainly, we should have a single financial management system, budget system, and payroll system. Centralized functions are almost always more efficient, effective and secure.
In an organization our size, some applications support should be decentralized, for example, the software used to manage Seattle Parks Department resources and reservations is certainly different from the software used to manage resources for the Seattle Police Department or our electric utility Seattle City Light. Employees in those departments know best how to use technology to support their unique business needs.
But achieving technology consolidation is hard. Although I’m proud of most of the work done under my technology leadership at the City of Seattle, I’ve had a failure or two as well. I hope others can learn from this. I certainly have the “scars of the school of hard knocks” from this experience!