That is an interesting perspective. We do install our ERP upgrades and point releases in a test environment, allow our users to test to work out the bugs, and file bug reports with our vendor. We believe, given the amount of money we pay every year for the software maintenance, our vendor should fix the bugs we find - not us. It is enough that we invest to find the bugs.
But it sounds like ASU moved the non-working software to production, to find bugs there. While it happens here sometimes, I wouldn't call it a strategy.
Marc Eichen's point about risk management is a good one. I wonder if ASU missed any of the federal payroll quarterly reports (or whatever cycle they are on). I wouldn't want to be in a position where we installed software with bugs that caused us to be out of compliance on any federal or state compliance, like payroll or financial aid awards. What a headache!
Our admissions area implemented a hosted admissions system once that had so many bugs that applications dropped 40% in one year. While the university was still running, you can imagine the panic that went through when it looked like we could be facing a drop of 40% (or more) in a fall class - just due to buggy, non-functioning software. We went into a disaster recovery mode and we were able to recover.
Installing faulty software into production mode would require more than just a "fix it later" approach. It also needs a full risk assessment.
---- Original message ----
>Date: Wed, 26 Sep 2007 07:19:39 -0400
>From: Dwight Fischer <[log in to unmask]>
>Subject: [CIO] Try Software First, Fix it later
>To: [log in to unmask]
> The WSJ had a provocative article in Tuesday's
> paper. For anyone who's ever implemented an ERP,
> it's worth a read. Arizona State University
> implemented Oracle's ERP and the strategy was a
> shift in paradigm: Get it in first, assume there
> will be problems and fix them as you go with the
> help of users. In their situation, payroll was an
> issue for 3000 employees. Many were under- or
> unpaid. "The IT department...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 notion that trying to make
> it perfect before rolling it out causes costly
> project overruns.
> That's quite a paradigm shift. The software industry
> loves the approach. It's akin to releasing a beta
> version and addressing issues after the fact.
> Needless to say, however, ASU employees are less
> than enamored with the concept. I wonder what else
> they ran into. The thought of rolling out an ERP
> that didn't perfect financial aid, or provide
> regulatory reporting, or deliver comprehensible
> student bills is rather novel. And yet one of the
> key points is that many of us for years have sought
> perfection first, probably delaying our project
> schedules, and costing us in additional
> resources--and still we ran into problems. ASU
> simply accepted that as normal and changed the
> Still, it seems unlikely that our institutions would
> ever agree to this up front. There are expectations
> that we ensure all current functions are met, and we
> do it on time and on budget. This new approach,
> while pragmatic and maybe more realistic, is the
> sort that gets CIOs run outa town.
> Dwight Fischer, CIO
> Plymouth State University
> ********** Participation and subscription
> information for this EDUCAUSE Constituent Group
> discussion list can be found at
Assistant Vice President
University Technology Services
www.oakland.edu/uts - the latest news from University Technology Services
Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.