When I became CIO for the State of Utah, one of the things for which I had very little appreciation was how much time and effort went into governance issues in a large organization. Before my stint as CIO I'd been CTO of a company I helped create and had hired nearly everyone who worked for me. As we built the organization, we also built and shaped the vision. People naturally understood the business because they'd seen it develop and had crucial roles in making it work. Further, while we'd had our share of culture problems, we'd handled these on-the-fly and with decisiveness. When decisions needed to be made, we made them and things worked marvelously.

I soon found out that the State was a different animal altogether. There were, of course, differences between the public and private sectors, but over and above those, the organization was an order of magnitude larger than what I'd been doing and there was what I call a "legacy lethargy." Moreover, IT was organized in a decentralized fashion so that no one really had the authority to make many important decisions, even when there was clear and imminent risk.

For example, at one point, for a period of about two months, a wireless network was set up in the Capitol with no access control whatsoever. Anyone with a laptop and wireless card could come to the Capitol and surf the net at taxpayer expense. What was worse was that the network had been set up for legislators and so it was also possible to monitor almost everything they did. I knew about it almost from the beginning and yet, I was powerless to put an end to it. The network had been put in place by another organization and even though it presented a clear risk, not just to the people who used it, but the entire enterprise network, there was no process in place to review plans, audit compliance with policy, or take corrective action. In short, we were stuck by our lack of a governance process.

Governance issues seemed to take up almost all my time when I was CIO. The Governor had a clear vision for what he wanted IT to accomplish, but it was difficult to see how to move the organization toward those goals. Part of the problem was a lack of understanding on my part of how to use the organizational tools I had since they were different than the tools I'd used previously. Part of the problem was that we needed some new tools and, most importantly, an enterprise-wide vision and commitment to achieving the goals of the chief executive.

After months of frustration, we finally embarked on a process to create that vision in a large cohort of executive management, both business and IT, and determine the process by which we would govern the implementation of that vision. The process, which I'd now call the "architecture initiation phase" took over three months and involved over a hundred people in dozens of meetings. It was exhausting. Nearly everyone grumbled, including me. I wanted to build things, not spend all my time in meetings and so did they.

In the end, we created a governance process that, looking back, had many of the required features of a good governance model, but for many reasons failed to take hold. The process was a significant step forward, but it ultimately suffered from three things:

• The resulting governance process was incomplete. There were crucial functions, such as auditing, that received very little attention, in part because they were unpopular.
• The model lacked a clear financial structure. IT governance isn't free and resources need to be committed unambiguously for it to work.
• There was insufficient buy-off by many of the people who had to support the process. We should have spent more time in meetings and in communicating the vision and plans.

We could have mitigated these problems had we had a better idea about what the initiation phase had to accomplish in order for it to succeed. At the time, I couldn't see the forest for the trees. I was too caught up in immediate goals and meetings to understand the true nature of what we had to accomplish.

You may share my initial lack of appreciation for governance. Over time, I've come to understand that a significant portion of a CIO's job involves standardization, training and certification, and management through policy, notifications, audits, and approvals. These may not be as sexy as building the next big system, but they ultimately are what will determine whether the large IT organization succeeds or fails.