It seems that last Tuesdays Wall Street Journal article about ASUs ERP implementation has stirred considerable discussion in various venues around the country. Much is being extrapolated from some fairly vague details in the article. While we appreciate the Journals take on our progress, short articles like this have limited space for specifics. And focusing on controversy, while providing a provocative read, doesnt create the best backdrop for discussing the broader issues.
In the interest of spurring a solid debate on the virtues and drawbacks of ASUs approach, I'm using this venue to answer some of the questions that the Journal article either missed or answered incompletely. Hopefully the context added here will contribute to public debate.
Why Did ASU Undertake the Project?
In December 2003, three distinguished university CIOs were asked to review ASU's aging administrative systems. Their exceptionally frank report made it clear that:
- ASU's administrative systems were on the verge of collapse;
- ASU's administrative computing strategy was fundamentally flawed, focused more on conserving resources than on replacing the aging systems - a replacement needed to mitigate the serious risk of total systems failure;
- ASU's lack of an effective replacement strategy and the "can't do" attitude of its IT staff made any contemplated replacement plan extremely risky;
- In the opinion of the reviewers, replacing the legacy systems at ASU, one of the nation's largest universities, would require 5-10 YEARS (and an investment of some $70-$100M).
(For more on this, see How Deep Was the Hole?)
What was Unique about ASU's Approach?
At ASU we advanced a unique approach to cost-effectively deploy our Oracle/PeopleSoft SIS and HR/Payroll system. The approach had three key components:
- First, we used a strategy we called Regents Vanilla to quickly win and maintain strong cross-university executive support. A key component of the Regents Vanilla approach was our commitment to base the system deployment on an existing implementation, rather than the usual approach of building the system from scratch;
- Second, we used an approach we call Implement, Adapt, Grow. This approach allowed us to contain scope creep and included a commitment to stick to a well-planned schedule of rolling component deployments, and to bring in additional resources to correct defects exposed by our extensive system testing, rather than delay deployment. "Implement, Adapt, Grow" includes an implicit acknowledgment that, despite the high level of testing that we actually conducted, no amount of testing would produce a perfect deployment, leading to our commitment to rapidly respond to defects in the system in the first few weeks of deployment. This is the reality of every major new system deployment in every organization. We may have just been more honest than some to admit it up front, but the perspective gave us the flexibility to rapidly find and resolve problems;
- Third, we used a Strategic Technology Alliance to reduce our time to market. Our alliance strategy included decisions to externally host the application and to choose a single partner (CedarCrestone) for both implementation and hosting.
How Big Was This Project?
At 65,000 students, ASU is one of the nations largest research universities, located in the rapidly growing Metropolitan Phoenix area. In February 2006, ASU began a project to replace seven of its core administrative systems Admissions, Financial Aid, Student Records, Registration, Talent Acquisition and Payroll. Eighteen months later, at a development cost of about $15M, the replacement systems are fully operational. Six of the seven major components - the exception being payroll - went into service with negligible interruptions to University business (apart from the enormous work load placed on the dedicated cross-university team that labored so hard to make things go as smoothly as possible).
Was the ASU Approach Successful?
It's only after an institution begins to reap the benefits of its new systems that the whole story comes into focus. However, some facts not covered by the WSJ article point toward success:
- ASU enrollment grew during the period of deployment.
- ASU successfully registered approximately 65,000 students for the Fall 07 semester with very few visible glitches. At the peak of the drop/add frenzy, ASU ran nearly 6,000 concurrent sessions with decent and consistent response time - and no crashes. Not many SIS systems can make this claim on their first go-live (or second, or sometimes third).
- Financial aid was distributed accurately in a timely manner.
- From concept to final cut-over, the project was completed in 18 months for about $15M. For an institution of ASUs size and complexity, previous project forecasts put the costs at many multiples of $15M and at least a 5 year implementation time frame.
But Payroll Was a Disaster, Right?
ASU regrets every payroll difficulty that we caused our employees and we are working very hard to rebuild trust in our new payroll system. Clearly, if we had it to do over again, there are things we would change. No question. And once the dust clears, Ill be happy to share our conclusions about what we did right and what we did wrong.
The basic facts are these: we underpaid around 3,000 of our 12,000 employees in the first three payrolls. Half of those underpayments were for $100 or less. 84% of the underpayments were managed within 4 days of each payroll. But that still left several hundred employees with short checks that were not corrected quickly enough. To make matters worse, the majority of the people affected were hourly employees, who tend to be least able to financially weather missing or late paychecks. As the Journal reported, it was not so much that the software failed us, than that our employee support environment wasn't up to the task.
That said, the great majority of our employees were paid correctly and accurately. By the third payroll, the error rate for the new payroll system (4%) was 33% lower than the error rate of the system it replaced (6%). We successfully ran Open Benefits Enrollment for all employees with barely a ripple. The web time clock - which proved to be a bad cultural fit for our organization - was replaced with a more friendly system by the third payroll, and that is running smoothly.
Right now ASU is working through the process of adapting to the new system. We're fixing things that need improvement; we're implementing new ideas and new interfaces. It's safe to say we are at the low point of enthusiasm for the system, which is not atypical of the adoption cycle for systems of this magnitude. But our community is working with us patiently to advance and improve. Most importantly, we are safely on the other side of the river. All of our investments are going toward the future. There is no risk of having to retreat to the legacy systems, no risk of being unable to run the business on the new system. We look forward to interacting with the Higher Ed IT community over the next several months to learn the lessons, both positive and negative, that this implementation can teach us all.