I spent the better part of my 20-year career in technology engaging with state governments. I worked for major corporations selling software and consulting services to governments. I managed teams that did the same. I was a research fellow at the John F. Kennedy School of Government at Harvard. I have done consulting, systems integration and project management through a nonprofit corporation I ran for the sole purpose of supporting government technology efforts. I could argue no one outside of government was more intimate with state government IT than I was.

Despite all that, when I became the first CIO of Georgia, I was amazed at just how different government looks from the inside.

In the 2000 legislative session, two years after being elected to office, Gov. Roy E. Barnes introduced legislation that created the Georgia Technology Authority (GTA). His intention was to establish a central IT organization that would become the centerpiece of his effort to transform state government into a state-of-the-art public management model by melding the best of what he could find from both the private sector and other state government IT management models, sprinkling in ideas to address the unique circumstances of Georgia.

In January 2000, everyone's attention was on IT. Because of Y2K remediation, the Georgia Legislature learned the scope of the state's annual IT expenditures, which were huge. Lawmakers were angry because no one was managing the expenditures, and no one could be held accountable for letting the Y2K bug bite them.

This led the Legislature to overwhelmingly support the governor's proposal for the new GTA governance model, despite its usual reluctance to provide the executive branch with the kind of concentrated authority the GTA would possess.

In fact, the scope of the GTA authority was so complete that in terms of IT budgets, projects, operations, standards and practices, it eclipsed the level of control delegated by any other state.

That's where I came in.

Through my nonprofit, Public Interest Breakthroughs (PIB), I provided no-cost consulting to the Georgia Department of Human Resources (DHR) on its child welfare system efforts. While engaged with DHR, I met the governor's policy director, Renay Blumenthal, on several occasions to explain why DHR had so much difficulty.

In March 2000, shortly after the legislation passed, Blumenthal asked me to meet with the governor about the new job of state CIO and executive director of the not-yet-formed GTA. I instinctively said no. I was not interested for three reasons. First, I was making really good money -- twice what the state would pay. Second, my family was happy and comfortable living in northern Virginia, and I could not imagine telling my wife we were going to move again. Finally, I just could not see myself as some ineffective bureaucrat. There was no way I was going to be a cog in the giant machine that was the nation's 10th largest state government.

Most of the folks I knew in government IT positions were lifers. They lived in the state capital, liked living there and didn't want to move even for a "better job." I had always been willing to do whatever it took to move my career forward, and CIO often stands for career is over.

When I hung up the phone I turned to Mark McGowan, my partner in the pro-bono work PIB was doing for DHR and one of my very best friends. "You are never going to believe the call I just got," I said. His reaction surprised me. He said I would regret not looking into it.

Mark reminded me that I "got off on making a difference," and although we felt like our nonprofit work was rewarding and important, the states we worked with continuously fell short of their goals. Although they were gung ho during planning, through a lack of authority, support, courage, funding or for whatever reason, they rarely fully executed their goals.

Mark suggested I would enjoy "grabbing the reins, following through, making things happen for real." The more we talked and the more I thought about it, the more I was inclined to find out what the governor had in mind. So I told Blumenthal I would take the interview after all. Two days later, I met the governor for a chat.

Barnes is an incredibly charismatic man. His office was comfortable, of course, and exuded the seductive aura of power. Bobby Kahn, his chief of staff, and Blumenthal also were there for the interview. The exchange was terrific. The governor was committed to change, and his vision of IT's role in government dovetailed with mine. Most importantly, he recognized that the "antibodies" of state government would rally to reject me, and the "permanent government" would try to shrug off the changes he and I envisioned. Barnes committed the full resources of his office and his own leadership skills to support and protect GTA in leading the state through change. Kahn and Blumenthal expressed the same commitment and their own offer of full partnership.

What sealed the deal was the governor's dare to "stick around, follow through, make it work, not just consult and then jump on a plane and fly north." He dared me to commit. He dared me to lead. I called my wife that afternoon. When she reluctantly agreed to the upheaval of moving the family to Georgia, I let Barnes know I was his man.

Learning from Role Models

Once the decision was made, I had to decide what kind of CIO I wanted to be. I had four role models who I consider the best ever at being a state CIO: John Kost, former Michigan CIO; Richard Varn, then-CIO of Iowa; Texas CIO Carolyn Purcell; and Steve Kolodney, former CIO of Washinton state. They were all brilliant, but each was different. Each had qualities I would endeavor to emulate in my own term as CIO.

When I arrived to be sworn in as the state's first CIO and executive director of the GTA, I identified a deputy for operations, a deputy for financials and inherited a dozen or so people who ran GeorgiaNet, the state's Web presence.

During the next several months, we hired nearly 125 people to staff the GTA. Half of those people came from the private sector -- from dot-coms and technology companies that were imploding all around metro Atlanta.

The talent available was extraordinary. Top-flight people of a technical and managerial caliber which might not have been available during the boom times of the 1990s were drawn to the stability of a government paycheck, and even more to the vision I was painting and the chance to make a difference in their state and community.

The other half of the team came from the ranks of existing state IT professionals. I was accused of "cherry picking" the best IT folks from around the state, and frankly I was guilty as charged. This 50/50 split of insiders and outsiders was accidental at first. We were looking for the best people for each position and things just turned out that way. But after a while, maintaining that balance became a hiring objective. The goal was to bring in fresh blood while utilizing the passion, commitment and insider knowledge of longtime state employees.

Trouble on the Horizon

While we built an incredible team inside the GTA, agency IT staff outside the GTA were becoming wary and already began to question openly the wisdom of its creation.

I articulated the need for an enterprise view of the state's IT environment. We described four major initiatives we would undertake. To most of the state government community, what we were saying sounded a lot like language they heard more than 25 years earlier when Gov. Jimmy Carter created the Department of Administrative Services (DOAS). Even after the creation of the GTA, DOAS maintained the central data center operations, as well as operational responsibility for telecom and network operations.

When I talked about server consolidation, network modernization, a more centralized portal environment, a single e-mail system, common standards for a variety of computing functions and a utility computing model that would centralize computer operations -- leaving the agencies to manage their applications and databases -- the agencies' technology people went berserk.

Despite every indication that those were the right things to do for Georgia, despite validation from experts in academia and our governing board -- which includes the luminaries of corporate computing in Georgia and the high-powered consultants who provided support for the governor's legislation in the first place -- and despite the fact that there were no arguments against the logic of our moves from any quarter, no one from the agencies had any interest in ceding control of the IT environments they independently maintained. It was as though they weren't paying attention to the creation of the GTA until after the fact.

It was immediately evident why the opposition was becoming so persistent, moving from passive aggression to active and vocal opposition by agency IT staff to their favorite legislators, agency heads and anyone else who would listen. The reasons agency IT staff members were so opposed to "modernization" were both self-interest and bad prior experiences with centralization by DOAS.

When DOAS was created, the data centers were consolidated, or more accurately, colocated. Agencies that used the mainframes located in the DOAS data centers maintained their own operations staffs, did their own job scheduling and managed their own data sets and their own physical storage devices. We learned that the DOAS rate setting process was pretty random and unpredictable. Agencies that used the DOAS data center were not in control of their own budgets.

DOAS represented the worst of all worlds. Agencies could not control their own costs, but they stepped all over each other because DOAS provided little central management. They just "hosted" the agencies' applications on their machines. There were no service or service-level agreements. DOAS receivables had delinquencies averaging months. It was a mess.

Over the years, the agencies reacted to the DOAS situation by embracing client-server computing. The result was nearly 4,000 distributed servers spread throughout the agencies' facilities. Servers were sometimes in closets or under desks. DHR even installed sheds on its roof -- wherever there was room -- so long as it was not at DOAS. There were no standards. There was no interoperability, no coordination and no governance.

These experiences made the agencies wary of a new centralization initiative that appeared to make them even more dependant on DOAS and threatened their "pirate" distributed facilities. Behind that was an even more extreme problem for the agency IT folks: All they knew was how to operate LANs, traditional data centers and the very functions the GTA aimed to centralize. The agencies did not have database administrators or application folks, such as analysts, coders or designers. Despite the GTA's good recruiting experience thus far, agency IT people complained that qualified people would not work for the state in those disciplines.

It became clear the GTA would have to focus on infrastructure and DOAS-controlled functions to accomplish our modernization objectives. It was also clear the state's IT community (outside of GTA) wasn't interested in change. It would have to be agency, program or business heads because they would benefit from efficiencies and the ability to focus on the exploitation of technology, not its operation.

It took us a year to establish our goals, hire staff, get our facilities in place, create relationships with key constituencies and make the discoveries described above. At the GTA's one-year anniversary, the governor decided to transfer all IT-related responsibilities, people and budgets from DOAS to the GTA. The mission of the GTA changed dramatically when we took operations. We could focus inside -- on ourselves -- to prove we could make things better for agencies by improving our own operations and proving our capabilities before demanding landmark changes from the agencies.

Where's the CEO?

Even with that change, the concept of a statewide enterprise was hard to implement. First, think of what an enterprise is and how it's run. You have a CEO who sets the vision and directs the enterprise, even transforms it. But the public-sector enterprise is far-flung, and the governor's role is less like a CEO and more like a chairman of the board, and good board members rarely concern themselves with daily operations. They expect executive officers, like the CEO, to do that.

The governor focuses mostly on a handful of critical problems, such as education or crime, but when it comes to operational transformation, most elected leaders don't have time to devote to this issue. The governor is concerned more with broad, new and outward facing programs than with the business operations of government. While the governor and his senior staff were willing to use their political capital to create the GTA, the public, which elected him to office, is only indirectly interested in operational transformation. What the public really wants are lower taxes and better education, and in Georgia there were other distractions, such as the confederate battle emblem on our flag.

The public wasn't going to pay much attention to how the state operates, especially how we operate IT governance. It was not Y2K anymore, and moreover, with the IT sector hurting badly, it was no longer sexy to be the "technology" governor. IT had come and gone as an appealing issue for public discussion. So despite the governor's original intentions when he created the GTA, he did not have time to focus on the sort of transformational changes that the GTA was created to undertake. Barnes was approaching re-election, and every minute he spent on the GTA was time he could not spend on more urgent political activities that would affect his re-election.

Agency directors represent the CEO role in Georgia state government, but only in an entrepreneurial sense. They are accountable for the results of their agency or department, but don't require fidelity to a statewide enterprise. When we first started the GTA, the agency heads' concerns for the state's overall functioning were entirely subordinate to the success of their agency. In Georgia, agency heads don't even meet as part of the governor's Cabinet.

I established monthly GTA agency head meetings to have some forum for enterprise-level discussions among the state's top executives. Even at these meetings, their sole priority was protecting their agencies' interests. It took several months to achieve some common good and purpose in the meetings.

In general, the CIO's role is to inject the potential that technology has for enhancing a CEO's vision, for enhancing the COO's responsibility for operational improvements and for supporting the CFO's focus on return on investment. In the corporate world, CIOs fulfill their mission by creating a common infrastructure based on the needs of the enterprise.

I discovered it's very hard to be a CIO without a clear enterprise CEO, COO or CFO. The public-sector CIO is handicapped without those other enterprise partners. I had enterprise responsibilities without the necessary partners in operations, finance and executive management to drive transformation forward. The governor expected me to transform state government. Despite the critical role of technology, transformation must start with the business process. The CIO is in no position to drive process change in the agencies. That effort must come from an operational or financial activity, supported by technology.

I don't think I am unique. I think the position of lone enterprise officer is common among my colleagues. We are expected to drive transformation with technology. Yet technology, despite its incredible potential, cannot drive change. It's a facilitative tool in the hands of the right leaders. Even the most effective CIOs, who are generating ideas and have the vision and understanding of technology, cannot drive change without the right partners at the enterprise level. In effect, public-sector CIOs have enterprise responsibilities within an organization that does not view itself as such. We are left to work with agency heads who take all the risks associated with their success, and therefore do not want to cede control of something so fundamental as the infrastructure of their agencies.

Although Blumenthal agreed with many of my observations, she still set expectations for me that I thought were inappropriate. She wanted me to do all the governor hired me for without upsetting the status quo of operational management. Her expectations reflected the views of many in the public sector. For some time now, it's been expected that IT be managed separately from the rest of government. The notion grew enormously during the dot-com binge, which gave rise to the e-government concept.

Champions of e-government put it this way: When you e-enable something, it becomes different from the rest of operations -- faster, cheaper and better. In my view that's simply not true. Digital government is government. E-government does not stand on its own -- separate from the programs it supports. IT is tightly woven into the practices, policies and operations of government.

The expectation that we in technology leadership should effect change without infringing on agency heads' business is unrealistic. But that view frees the governor's staff and legislatures from engaging in the messy business of changing the state's governance model more broadly.

Forces of Collaboration

Technology is an integral part of government operations and services. Massive efficiencies are gained from sharing resources across a common infrastructure, but the CIO must ensure the technology is executed and managed collaboratively with program managers. Without that collaboration, the consequences can be disastrous.

Take one example close to my heart: child welfare. It is layered with redundant workflow based on manual processes that rely, for the most part, on paper documents. Caseworkers go into the field, conduct investigations and file reports. The reports are produced at different times in different locations, using different methods.

Typically, the reports are turned over to data entry clerks who copy them into a case management system. This double data entry system is inefficient. By introducing a mobile computing device with the right kind of software into the process, managers can wring enormous savings. Instead of having one data entry clerk for every three to four caseworkers, you can use one clerk for every 10 to 15 caseworkers. These are great efficiencies, but they are also significant business process changes that affect human resources and the program's budget.

The same opportunities for transformation can occur when technology is used to drive each individual caseworker's decision-making. Child welfare programs suffer from large amounts of turnover due to the taxing nature of the work and low pay for the worker. To compensate for the problem, agencies could turn to expert systems and other types of decision support tools to help the worker in the field manage cases.

But in this instance, technology would force caseworkers to conform to a set of standards of care embedded in the code of the system they used, leaving out the benefit of intuition and experience by senior caseworkers. It is important to apply this type of technology selectively -- only to junior workers, leaving senior workers the capability to "overwrite" the systems' directions, for example. The contents of the expert systems, the direction given and the rules for adoption belong to the program experts. The level of collaboration necessary for deploying this type of system is extraordinary.

If it's so obvious that CIOs, agency heads and program managers must work in collaborative partnerships, why is it so hard?

My experience tells me the reason goes back to the lack of an enterprise management paradigm in the public sector. The person in charge of the child welfare agency is responsible for its success or failure. It's his or her name that's going to appear in the newspaper when a child dies. The last thing these directors want to do is take their eyes off daily operations and spend time focusing on the potential that new technology can deliver. This becomes even harder to do if the agency head isn't comfortable with IT. Now, imagine what's going through the agency head's mind when the one person telling him to change the system is the state's CIO, someone who has authority to define IT but who has no direct responsibility for the program and policy outcomes of child welfare. In his or her view, the CIO only is concerned with how well the IT system works.

Without other enterprise executives stepping into the picture to provide reasons to change, that child welfare agency head is not motivated to respond to the CIO's direct input. A CFO must say, "We just can't afford to run child welfare this way anymore. You have to work with the technology department and drive out cost." Or a COO must tell the head, "There's so much turnover; we need a plan to insulate ourselves from its effects." Without that, CIOs are on their own. They must explain to the agency head the potential for change, but without the legitimacy of other nontechnology factors, such as financial or operational concerns. Without help from COOs and CFOs (not budget directors whose views are often too narrow and short term), the forces of turf and agency self-interest will always win against the proposals set forth by the CIO -- the lone enterprise executive.

No matter how capable a CIO I thought myself to be, I needed stronger enterprise partners than I had.

Government's Architectural Blueprints

The real benefit of IT comes from organizational productivity. Federal Reserve Chairman Alan Greenspan made that point when he said the private sector received significant productivity gains from IT over the last seven to 10 years. The same potential for organizational productivity gains exists in the public sector.

My greatest pride in the work I did as Georgia's CIO resulted from the introduction of an enterprise architectural view of how we manage IT in the state.

At the policy leadership level, it's fairly easy for governments to cede the network to an enterprise CIO. Network access is a fundamental, base capability. Currently, most governments have a disparate network infrastructure, consisting of hundreds of LANs (we had thousands in Georgia). In addition, many governments have multiple wide area networks -- sometimes dozens.

It's at this level of the architecture that I had the easiest time getting consensus for the need of an enterprise view. It's easiest for bureaucrats and politicians to think of it in enterprise terms and as being provided by a central "utility," since very few organizations operate their own phone company. Why should state agencies be different? The difficulty right now is that most IT managers in individual agencies are not willing to give up control of their local networks, especially the universities. The business leaders got it right away.

The opportunity for consolidating networks is huge. With Java-enabled workstations and large-scale servers, it's possible to have very thin clients with hosted servers driving systems out to the farthest reaches of the enterprise. You don't need a separate network for each agency. Governments that build scalable, enterprise network architectures can pull out tens of millions of dollars in waste from the redundancy of existing networks. This is one of the places where the enterprise view gets the clearest return on investment, and where opposition to the enterprise view is not particularly strong.

However, making that kind of change to network connectivity can be expensive. That's why I chose outsourcing as the most appropriate and powerful tool available to me. Because there's so much waste, Georgia, like most governments, has a lot of its operations budget committed to maintaining existing networks. The solution is to convert the operations expense into capital. That's hard to do in the public sector. By using a portion of the operations budget to pay a third party, the outsourcer converts the funds into capital to pay for an enterprise infrastructure at a reduced cost, so long as they are assured a continuing revenue stream even after their capital expenditures result in lower operating costs.

The next level of the enterprise architecture is computing. The consolidation of servers and data centers into an enterprise computing environment has become very important. Everyone now recognizes that computing is more efficient and effective if it's managed as a utility. Unfortunately that's not how it's managed in government. Every agency has its own generator in the basement. It's terribly expensive, but the attitude among agencies is if they don't control the machine, they don't control the application.

I worked tirelessly to help executives in the agencies and departments understand that computing is like an electrical utility. They don't each need their own, separate generators. They shouldn't really care what's behind the electrical socket. More importantly, while I wanted GTA to have broad management of that utility, that didn't mean I wanted to tell the agency how to run its business, which applications to run, or how to use its data. While selling this concept was difficult, it's almost as beneficial as the consolidated, outsourced network. My intention was to allow the agencies to turn their attention away from operating the computer environment and toward the utilization of it for their business.

The third level of the architecture is interoperability. Government is not organized around rational business functions, citizens, businesses or policy objectives, but around politically defined programs. I spoke whenever I could about IT's great potential to integrate disparate back-end processes into systems that achieve better outcomes. The interoperability level allows each program to focus on its own objectives and needs, and allows an enterprise government to knit together programs around customer requirements and political objectives. In this new Web services world, with component-based software, XML and a host of other useful middleware tools, government agencies and departments now have the ability to build their own applications based on their own business needs and still participate in the larger enterprise.

There are other layers of architecture, but these are the layers I had the opportunity to focus on in my short time as a state CIO -- a little longer than two and a half years.

That brings me to the biggest lesson I learned: Time is short. In the private sector we often feel like we live from quarter to quarter, but we usually live to keep trying the next quarter. In government the end is often abrupt.

Barnes lost his bid for a second term. Even though I describe the role of governor as more of a chair than a chief, at least in Georgia, he is a powerful chair. We made much progress toward our goals, but I am afraid without his vision many of our gains will be lost. He and I were sure there would be a second round to secure our gains. We scheduled the completion of many of our programs this spring. The next step would have been to focus on stabilization. But once the results of the election were known, I left.

It was a hell of a ride that came to a startling and sudden stop, but it is a ride I will never regret. I highly recommend public service to anyone who wants to make a difference, and I wish the very best to those I leave behind in my adopted state of Georgia. Good luck to that wonderful enterprise, may it find itself and someday live up to its full potential to serve its citizens.

Larry Singer is a vice president in the Global Information Systems Strategy Office of Sun Microsystems.

Larry Singer  |  Contributing Writer