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. (The award-winning functions are centralized, of course!)
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 much 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. But 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.
Consolidations can be done well, as in Missouri by Bill Bott and Dan Ross, or Teri Takai in Michigan.
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 or three as well. I hope others can learn from this. I certainly have the "scars of the school of hard knocks" from this experience!
Our city (close to 1 million population) could also benefit greatly from consolidation, but I know those of us in stovepipe departments would fight it tooth and nail, because we don't trust our central IT. They've failed to provide knowledgeable, timely service over and over again. The central IT group needs to have a track record of credible accomplishments and recognition of user needs, not just "my way or the highway".
What a breath of fresh air to see a CTO provide such an honest and insightful piece. It's obvious that the mayor has the right people in place to lead The City of Seattle's IT Operations. All to often, it's amazing how counter productive other agencies in State and local government will be when their true focus is owning something rather that always assessing, "what's the best way to do this?". It's good to see that the overall mission statement is what drives great decisions at the City of Seattle. As a new partner to the City (recent award of a technology contract), I have shared this with my entire organization as we are more motivated than ever to deliver on the promises we made during our pre contract stages. We have decided that the success of this project that we're just about to kick off will be the one we gauge ourselves on internally this year.
It is normal for CTOs to claim success even when their project has failed and has resulted in enormous losses. And when they are forced to admit that their project is a failure, they try to pin it on somebody else.(I tried my best and it was a good thing but it turned out that my organization is not mature enough!!). Especially in the IT field.
So it is really nice to read an honest account of a project. Thanks Bill.