Arizona State’s Radical ERP Rollout

By now you’ve probably heard about the troubled rollout of an Oracle/Peoplesoft student information and HR/payroll system at Arizona State University this summer. If you haven’t, read former CIO writer Ben Worthen’s account in the Wall St. Journal, “Try Software on Workers First, Correct Malfunctions Later.”

In an effort to deploy quickly and dramatically reduce costs, ASU rolled out a major enterprise software project in just 18 months, as opposed to the four or five years such projects typically take, at less than half the expected cost. But in the wake of the cutover to the new system, thousands of employees missed paychecks, or got paid too little, or in some cases, too much. Not good.

At the heart of this case is a fundamental shift in ideas about how to roll out big complex software projects.

The ASU approach — to stick to an aggressive schedule at all costs and “implement, adapt, grow” — is in stark contrast to the traditional model in which you don’t actually flip the switch on a new system until everything’s been tested, people have been trained, and the bugs have been worked out — especially if the system does something as fundamental as pay your employees.

While the troubles ASU has experienced seem to many people unacceptable (a business professor and former IT exec I know said of Sannier, “he ought to be fired”), it’s hard not to envy the results. “The final price tag for Arizona State’s project is $15 million to deploy the software and another $15 million to support it over the next five years,” Worthen writes. “The total is well below the $70 million the board expected to spend.” Oracle even published a case study on the rollout (which they’ve since pulled from their website), touting the remarkable results. Sannier has written a response to the Journal article in his blog.

So where do you stand? Is this the future of software projects? Is Sannier a visionary or irresponsible? Will employees and consumers come to accept a world where everything’s in beta and the “kinks” get worked out on the fly? On the other hand, even with years of planning and testing, what big project doesn’t have some problems? Isn’t it better to just work that into your plan?

I think Sannier’s on to something here. Of course, his case would have been a lot stronger if they’d had a good and reliable backup process in place to pay those employees whose checks went awry. If they had, they could now legitimately be heralding their own success. Instead, they’ll just quietly and discretely celebrate the $40 million not spent and the 65,000 students successfully registered with the new system this fall.

For more on university ERP projects, see “Big Mess on Campus.”