Tuesday, September 25, 2007

A Successful Implementation?

Today's Wall Street Journal had a fascinating article about strategy that the Arizona State University IT department used to deploy Oracle HR software and the consequences of that strategy.
When Jay Reinke's July 31 paycheck wasn't automatically deposited into his bank account, the 42-year-old painter at Arizona State University, went to the school's human-resources office. A paper paycheck was waiting for him. For $0.00.

Mr. Reinke is one of roughly 3,000 Arizona State employees who have been underpaid or unpaid since the school started using new software from Oracle Corp. to manage its payroll. Others have received paychecks thousands of dollars too high. The payroll problem has caused so much unrest that armed police guarded the university's HR office on several recent paydays. ("Try Software on Workers First, Fix It Later" by Ben Worthen, p. B1)
Sounds like a disaster, doesn't it? Not being able to pay one's employees correctly or in a timely manner is one of the cardinal sins of any business. How could this happen? Well, deploying ERP software is notoriously difficult, costly, and fraught with peril. ASU originally estimated that it would take $70 million and multiple years to deploy the Oracle HR suite. Instead, ASU's IT department did it in 18 months for $30 million.

The information-technology department at Arizona State decided it would be more effectie to stick to rigid [implementation] deadlines, releasing the software on schedule even if all the kinks hadn't been worked out -- and try to fix problems on the fly.

They're getting a lot of positive reviews from IT departments at other universities, and the ASU board is ectatic and deems the implementation an astonishing success. I really don't know how it's possible to argue that that is true. Large-scale IT implementations are difficult, and it's very difficult for them to spiral out of control very quickly. More than that, it is impossible to plan for every contingency and be able to ensure a problem-free implementation. At some point, you have to take a leap of faith, implement the software, and clean up whatever problems you find. But for the implementation to fail so badly that it can't accomplish what it's there to accomplish (pay employees) a sizable percentage of the time is not good. For the IT department to fail to plan adequately for what they would do if employees failed to get paid is not good. And for the IT department to blame the payroll catastrophe on others (which they did) is unconscionable. Sure, the project came in $40 million under budget, but who cares? By throwing it out there before they were ready, they seriously damaged some employees, violated the trust of all employees, and have guaranteed that no matter how well they fix the problems, everybody at ASU will be quick to blame any problem on the software and slow to believe that the software is working.

1 comment:

Ben W. Brumfield said...

I remember that at Rice, Nick Metrowsky had implemented a disaster/failover scheme so stringent that even if the entire accounting system went down due to hurricanes or something, employees would be issued a paycheck for the amount equal to their previous check.

The ASU setup really doesn't pass level-1 correctness. The other side of "do half the features" is "make it twice as good".