Bizarre ERP implementation experiment at Arizona State

Bizarre ERP implementation experiment at Arizona State

Summary: Arizona State University's deployment of Oracle ERP is challenging important and fundamental assumptions about how complex software systems should be implemented.ERP implementations are often difficult, expensive, and painful, involving significant disruption to the organization.


Arizona State University's deployment of Oracle ERP is challenging important and fundamental assumptions about how complex software systems should be implemented.

ERP implementations are often difficult, expensive, and painful, involving significant disruption to the organization. To minimize these disruptions and ensure the system works as required, most organizations spend significant budget on such items as software testing, training, change management, and documentation.

According to conventional wisdom, mission critical software should always be thoroughly tested prior to deployment in a production environment. Arizona State University has challenged conventional wisdom by deliberately releasing partially-tested finance and operations software to users. In doing so, the school made an explicit, strategic decision that user problems and organizational disruptions are an acceptable trade-off in the fight against high implementation costs.

As described in the Wall Street Journal:

Roughly 3,000 Arizona State employees 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.

The Tempe, Ariz., school has installed its new software using an unconventional -- if painful -- approach: Admit from the start that there will be mistakes; then work through the glitches with users' help. Most companies take their time and don't start using a new computer system until they are convinced almost everything works right; then they are caught off guard when mistakes inevitably happen. Often, the delays allow them to expand the project's scope, which adds cost and can further compound problems.

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

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, which includes $6.5 million that the school's board of regents approved at the end of August. The total is well below the $70 million the board expected to spend.

The school's implementation is substantially below budget, an extreme rarity in the world of ERP deployments. However, this comes at the expense of quality, usability, and employee morale. Again, from the Journal:

The new strategy's pain is undeniable. "Morale is the lowest it's been in the 14 years I've worked here," says Allan Crouch, who works in the university's human-resources department.

Does this approach make sense? It depends on how one values issues like employee morale. These are judgment calls, and the answers will be different from one organization to the next.

Regardless of value judgments, Arizona State took a big risk. While they acknowledged personnel and business disruptions as an expected implementation cost, such problems can spiral and escalate out of control. For example, SAP-related payroll problems at the Los Angeles Unified School district (LAUSD) went on for months, resulting in threats of union boycotts and lawsuits.

It's interesting to note Oracle's perspective on this new approach:

In a statement, Jim McGlothlin, an Oracle vice president called the project "highly successful."

Well, of course. Oracle received its license fee, has an under-budget implementation and, for probably the first time in history, the customer is uncritically accepting of software-related payroll problems. I'm sure Oracle can't believe its lucky stars on this one; it's like they've won some sort of ERP Triple Crown.

Has this experiment succeeded or failed? Only time will tell, because the full impact of insufficient testing will be revealed as the system is used, over time, in a production capacity.

The savings derived from this approach come at the expense of increased downstream risk. A probability exists that system bugs will arise in the future, after the implementation programmers are long gone. If these bugs are severe, the school could face substantial disruption while it scrambles to fix unexpected problems.

Should your organization follow this approach? As an answer, rely on the immortal words of Clint Eastwood, from the movie Dirty Harry:

You've got to ask yourself one question: 'Do I feel lucky?'

Update 9/26/07: Welcome Fark users, and thanks for Farking this page. We love you!

Update 9/27/07: For another twist on the situation, you've got to see this.

Topics: Banking, CXO, Enterprise Software, Oracle, Software, IT Employment

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Simple changes could have avoided ASU ERP pain

    It seems things would have been fine if ASU had been better prepared for providing manual payroll. They had paper checks for payroll but ran out. Could they have created a second instance of the payroll? Better communications beforehand, a robust payroll backup plan and more paper checks would have solved most of the morale problem.

    If ASU saved $40M by doing it this way,they should share $10% with those who had their payroll disrupted. I'd bet that would help morale some.

    As long you people know what to expect and they get paid on time,this is totally doable.
  • This is nuts!

    I really feel sorry for the implementation team. This totally goes against any seasoned Project Manager's instincts.
    The implementation team received all the heat from p.o.'d stakeholders for a decision that they didn't make.
  • Fascinating but risky

    I'm a big believer in the idea that you know you're being successful when people start complaining: it shows that your software is actually being used. And from a big picture, the cost to the organization of some payroll errors, provided they don't last too long, may be acceptable in return for a $40MM savings. Certainly those problems slow the organization down -- but perhaps not $40MM worth of slowdown. As other folks have said, only time will tell. I'd love to see a more formal study and post-mortem of this implementation 6-12 months from now.
  • should have paralleled

    They should have parallel paid. The one system printing to *REAL* checks, the new system to "advice" checks, and request the employees compare pay stubs for accuracy...

    run a few times that way... and you won't have real dollars involved in the mess up..

    but there I am.. an idea man.... and the world hates idea men.. :)
    • good idea but...

      they were moving from a bi-monthly pay schedule to a lagging bi-weekly pay schedule which complicated the whole process and required estimated pay. The payroll issues were inexcusable and there is no defense fo those. But in all other areas the implementation has gone very well. Any conversion of this size is going to have problems no matter how much testing.
  • RE: Bizarre ERP implementation experiment at Arizona State

    They should put the Oracle consultants and programmers payments on that system.
    Tsu Dho Nimh
    • Pretty funny

      Yeah, that would certainly influence how they approached development and testing!
  • RE: Bizarre ERP implementation experiment at Arizona State

    Amazing that anyone would think that creating the lowest morale in decades at a company would be a successful implementation of any software. This shows how sick things are getting. Outsourcing vast segments of highly paid IT to countries where people are paid a fraction of what they are here is considered "a good strategy" too. Maybe with proper planning, and a well designed software package, they could have achieved both.
  • ASU Response

    I reply with this to the updated story also.

    ASU has responded to some of the internet chatter about their PeopleSoft implementation. See

    On the surface it is quite remarkable. Having worked with PeoleSoft including implementing the student system at another university, the student system is 2-3 times as complex and difficult as a payroll implementation. Any payroll issues is a serious issue - and ASU had some - but overall the implementation is worth looking at and is a fresh approach - especially for higher education.
  • Where to find Oracle Case

    Does anyone know where I can get a copy of the case study that was written by Oracle?