Bizarre ERP implementation experiment at Arizona State

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.