C-NIC OREGON: Fred Thompson, Guest Blogger

Ed. Note: Once again Fred Thompson checks in with an in-depth discussion of a local issue.


The legislature is currently holding hearings on the State of Oregon’s computing and networking infrastructure consolidation (C-NIC) project, the most ambitious technology project ever undertaken by the state (Statesman-Journal, 14 Aug 2008, p. 1). This topic deserves our attention. More than half of the activities performed by the state involve information processing, storage, manipulation, and analysis. How well the state government does its work ultimately depends upon the quality and effectiveness of its Information and communications technology.

Most of the scrutiny directed at C-NIC has zeroed in on the fact that it was over budget and behind schedule. The business case for the project looked primarily at operating cash flows and depended primarily upon personnel reductions. Bob Cummings, the information technology analyst for the Legislative Fiscal Office, has subsequently acknowledged that it was unrealistic for state officials to think they could cut staffing while consolidating complex operations. In any case, C-NIC’s is currently $67 million over budget (Statesman-Journal, 14 Aug 2008, p. 1). Some of us said so at the outset.

Construction of the hardened facility, installation of mainframes, and configuration of the new network architecture was supposed to be complete by the end of 2005, with migration of operations from the three largest existing data centers to the consolidated data completed by the end of 2006. As it happens the project is still not entirely complete, which has doubled transition costs and substantially delayed benefit flow from the project. Moreover, payback depended upon the project staying on schedule and being completed on time. That was also unlikely, although not necessarily for the reasons given.

Nevertheless, knowing what we now know, if we treat the project as a standard capital budgeting problem with a life of 25 years and a discount rate of five percent, it looks better than break even, even before taking account of benefits accruing from greater security, substantially increased peak capacity, learning-curve effects, or buying power. Moreover, according to DAS Director Scott Harra, consolidation has generated an additional benefit: "Departments can focus on their core business.” Department of Revenue Director Elizabeth Harchenko agrees, she no longer has “to worry about having her own agency maintain the necessary staff, software and equipment to do the work” (Statesman-Journal, 14 Aug 2008, p. 1). So by any reasonable standard, C-NIC has been a qualified success, which is occasion for self-congratulation, especially given Oregon’s history of IT fiascos.

Nevertheless, instead of patting ourselves on the back, we ought to ask what can be learned from this experience.

For students of e-government C-NIC reflects two noteworthy design choices. First, its designers chose to break no new ground, but, instead, they were content with paving the existing cow paths, justifying their effort in terms of standardization, departmentalization, and operational cost-efficiency. Consequently, C-NIC architecture reflects existing agency databases, which are built around general ledgers rather than geographic locations, and make limited use of meta-data and intelligent agents, unlike the systems implemented by governments on the leading edge of IT development. Moreover, the project’s governing board evidently never considered making database information available to the public. Instead, they redefined the security challenge C-NIC was meant to address. Rather than a terrorist attack, they now emphasize C-NIC’s capacity to maintain data confidentiality.

Second, the project’s governors chose to consolidate all of the state’s data processing and storage at a single hardened site. Indeed, the only alternative they formally considered was consolidating processing at two locations, the primary location and a backup, which they rejected for reasons of cost. The consolidation option was largely driven by fairly mundane considerations: the existing data centers were highly vulnerable to physical attack, existing server capacity was often underutilized, but was insufficient to meet peak demands as configured.

However, given this problem diagnosis, the best prescription would seem to be grid computing, which would distribute computing power throughout the state, In that case, over half of the nodes in the state could be destroyed and the system would continue to operate. Instead, we chose to put all our eggs in one basket.

The implicit decision to ignore these basic, conceptual design issues was never seriously questioned. Why didn’t the dog bark? One answer is that the project’s governors, the heads of participating agencies, were largely unfamiliar with digital organization or even the basics of IT -- when the project began, fewer than half of the board members answered their own e-mails. It probably never occurred to them to consider these alternatives. Moreover, as the State’s former IT manager, Mike Freese, explained (October 4, 2005), Oregon lacked “the technical expertise to implement grid computing.” He continued, “The best solution to an IT problem is useless if it cannot be implemented, so we looked for an 80 percent perfect answer that we could actually pull off – from this perspective, consolidation was a no-brainer.” One cannot fault Freese’s logic, but the proper lesson to be drawn here is somewhat different. If one accepts that information management is a core function of government and that Oregon hasn’t developed the necessary capability to perform that function, it follows that Oregon lacks the capacity to perform one of its core functions. It needs to develop that capacity. Further, top managers who do not understand the IT function shouldn’t be top managers.

In this case, legislative interest in consolidation preceded executive commitment to shared services. According to the Statesman-Journal (14 Aug 2008, p. 1), the 2005 Legislature approved C-NIC’s two-year budget of $100 million, including money for a new building on Airport Road SE in Salem, “with little opposition.” This means that C-NIC missed the legislative scrutiny an administrative proposal of its magnitude would normally receive prior to authorization. Again, one suspects that the legislature failed to scrutinize this project because it lacked the expertise to do so.

Most of the delays associated with the C-NIC project resulted from governance failures. These have been manifested in an inability to make timely decisions, but the dithering over policies and priorities seems to reflect deeper difficulties.
First, there was the conflict over the independence of the data center and the governance role of shared-services board. C-NIC’s designers drew a sharp distinction between shared and centralized provision of support services. They assumed that data processing would be consolidated into a stand-alone business unit that would be owned by its clients and whose only mission would be client service. They further assumed that the consolidated data center would negotiate service-level agreements, specifying standardized services and mutually agreed upon rates, with each agency, relying on quasi-market mechanisms to link the center to its clients or customers

By making data processing the unit’s sole purpose, they hoped “to elevate the importance of this back-office function to front-office status” and, thereby, “increase customer focus and employee motivation and ownership.” This logic was outlined in the shared-services governing board’s initial report, Shared
Services: A Strategy for Reinventing Government (DAS, August 2004).

Nominally all of the members of the shared services governing board endorsed this vision. However, DAS was responsible for managing the C-NIC project. DAS is not only Oregon’s central control agency (budget and financial management); it also supplies other agencies with a variety of support services – space and facilities, maintenance and landscaping services, utilities, the motor pool, etc. As it happened, project management gradually evolved into program management and, whether by accident or design, the consolidated data center came to be treated a simply another arm of DAS.

Unfortunately, customer service is rarely if ever a high priority of control agencies. DAS is no exception to this rule. Its priorities are central control, economy and efficiency, and adherence to rules. Even if DAS had in this instance been truly concerned with providing the consolidated data center’s clients with the best possible service, past experience with its service delivery practices might have led them to doubt its good intentions. Consequently, DAS’s unilateral rejection of the shared services concept, which had led to the creation of the shared service board in the first place, disgruntled some of the agencies represented on it.

Second, establishing a program management (as opposed to a project management) office was repeatedly delayed. The program management office was supposed to be put together from personnel drawn from longstanding functional units, who had worked with different kinds of data and applications processing styles. C-NIC’s designers assumed that personnel from different processing centers could be gradually integrated into a single functioning team with a common mission, regardless of their prior task-orientation or role. Cross-functional integration proved very difficult for the C-NIC project management team. This too was partly due to agency distrust of DAS. As it became increasingly clear that things were going to be done DAS’s way or not at all, their erstwhile partners turned increasingly uncooperative.
The third lesson, there is a fundamental conflict between DAS’s service-delivery mission and its fiscal-control mission. The time has come for Oregon to assign those missions to different agencies.