Case Study – Wisconsin’s $100 Million Loss

Note: The promised piece on ASP and SaaS availability standards has been postponed for one week.


It has been said that IT projects are always late and over budget. The most commonly given reasons are:

• Vendor errors;
• Vendor misconduct;
• Changed circumstances;
• Unforeseen obstacles.

Regarding “vendor misconduct,” it is easy to find IT executives willing to believe that vendors deliberately under estimate cost and time requirements to win contracts, only to have the true cost become apparent as the project unfolds. Such “low balling” undoubtedly occurs, but more often vendor and customer must share responsibility for a troubled project. If “blame” is to be assigned, perhaps it should fall upon customers who ignore the ancient maxim: “caveat emptor.”

Remarkable examples of “how projects go wrong” are provided by the State of Wisconsin, which in late 2006 and early 2007 confronted a number of troubled projects, with an exposure of some $100 million. The figure is all the more significant when one considers that the State’s annual IT budget is roughly $400 million. A quick survey of the troubled projects will help set the stage:

• In 2006 the University of Wisconsin discontinued a program to update its salary and benefits system, after spending five years and $26 million.
• As of Spring, 2007, a new system to track unemployment taxes was 3.5 years late and $12.2 million over budget.
• A new voter registration system was more than two years late (i.e. ready two years after the deadline set by Federal law).
  
• New sales and use tax software required a $5.7 million fix.
• Work on a new system to track unemployment claims was suspended in February, 2007, after an expenditure of $23.6 million.
• A new system to handle automobile registrations was abandoned. It was at least a year late, $9.4 million over budget and had significantly increased wait times at the DMV offices.

This string of difficulties prompted members of the State legislature to request a formal audit by the Legislative Audit Bureau (Wisconsin’s equivalent to the Federal General Accounting Office). According to the Bureau, these projects had much in common:

• Failure to appreciate the complexity of the projects;
• Failure to define the final function of the various systems;
• Failure to observe contracting best practices, such as standard procedures and incentive/penalty clauses.
• Lack of leadership and oversight.

Significantly, ALL of these variables were within the control of the State.

As a case study, Wisconsin’s difficulties are rich in lessons, for it appears the State made virtually every mistake in the proverbial book. It made many of them repeatedly:

• Failure to realistically allocate resources;
• Failure to plan in detail;
• Failure to plan with an end in mind.

Of these, perhaps the most damaging was the failure to plan with an end in mind. Without a clear goal in mind, it is not possible to set meaningful specifications. In turn, an absence of meaningful specifications opens the door to “mission creep” as each user tacks on items from his or her wish list. Cost and time requirements can and probably will increase dramatically. Even without mission creep, ambiguous specs are a recipe for failure. Vendor may believe that customer wants and expects “X,” while customer is expecting something quite different. Unfortunately, the misunderstanding might not be discovered until late in the project, after much time and cash has been invested. Also, without clear specs, it is not possible to develop reliable cost estimates or time tables. In a very real sense, the various Wisconsin projects were not over due or over budget, for they had never been properly planned or budgeted. Quite simply, the State did not know what it was getting into, and paid the price.

Taken as a whole, the Wisconsin projects suggest an IT unit in disarray:

• Lack of necessary expertise;
• Lack of leadership willing to set reasonable expectations;
• Lack of uniform contract forms and contracting procedures to guide personnel who might not be versed contractual matters;
• Lack of oversight.

The lack of oversight bears special consideration. The various projects discussed here fell primarily within the responsibility of the Department of Administration (aptly known as “DOA”).  That department failed in its responsibilities because it was pre-occupied with two troubled tech projects of its own. A second level of supervision is, in theory, provided by committees of the State legislature. Those committees, however, have been inactive since at least 2005.

Wisconsin’s misadventures offer a sobering example of the many ways IT projects may go wrong:

• Failed leadership, leading to unreasonable commitments. These commitments led, in turn, to unreasonable expectations and burdens on personnel.
• Lack of a core of personnel trained in the art and science of managing large projects (not to mention negotiating large contracts). As a result, individual units were left to fend for themselves, with unfortunate and expensive results.
• Absence of standard forms and procedures to guide users when they were indeed forced to fend for themselves.

A word should also be said about the broader consequences of these difficulties. The responsible CIO has returned to the private sector and the State has represented that all is not lost – that portions of these troubled projects can still be put to productive use. In a private company, the results might have been more dramatic. Such losses, combined with the evidence of failed oversight and leadership, might well cause a wholesale dismissal of management, not to mention the possibility of shareholder derivative suits.
Whatever the political or economic consequences, Wisconsin illustrates the importance of professional, systematic management of IT contracts (indeed, of all contracts) and the importance careful, detailed planning by trained and experienced personnel.