Ben Worthen's Wall Street Journal article on arizona state university's recently completed ERP implementation project has resulted in quite a little mini-firestorm of debate over the relative merits or demerits of University Technical Officer Adrian Sannier's decidedly unconventional implementation approach.

Briefly, Sannier took what I have termed an "agile" approach to the project implementation-a concept borrowed, depending on who you ask, either from Google and their perpetual beta approach to software deployment, or from the world of agile software development. Or perhaps from neither... there is remarkably little detail about what the approach actually was, but much extrapolation from those of us in the peanut gallery. In any event, some claim that the rapid implementation had a certain "rip off the bandaid" quality to it, confining the pain and trouble of a major upgrade into a relatively short and less costly timeframe; others find it deplorably irresponsible, resulting in many major problems affecting staff which would not otherwise have been incurred.

What we all had to say about it is after the jump.

Michael Krigsman takes exception to the risks of the project and then even more to Oracle's decidedly self-serving description of it. On my Status blog, I take a bit more of a contrarian perspective, suggesting that since more conventionally run projects have such a ghastly failure rate it hardly seems fair to single this out as bad practice. Oracle themselvse think it was the greatest thing since sliced bread. Chris Murphy at Information Week has a moderately balanced but leaning toward skeptical post on the matter. Sannier himself has a number of posts up regarding the project on his own blog, including justifications behind both the project and the approach from a conceptual standpoint, but unfortunately provides little detail on the implementation.

I suppose I have already made my biases clear, but the entire debate could use a little summation. One, it's clear that almost no one outside the Oracle/ASU community (except apparently some other college IT departments-and perhaps they should be given extra credence, despite remaining relatively quiet in the matter) thinks the outcome was entirely successful-employees going home without paychecks, regardless of the point of failure, is Bad. Two, it's not so clear that this was necessarily an obvious outcome of the methodology, considering how many more conventionally implemented projects go downhill just as swiftly, nor is it clear that the sum of human misery generated in a few bad months of problems exceeds the sort of lingering, but low-level frustration generated by smaller problems over a longer period. Three, you'd better structure your vendor deals so that they share some of the pain when things go wrong with the systems whether it's short or long term.

If ASU's board is genuinely happy with the outcome, then it isn't really necessary that anyone else is pleased-it's their dime, their employees, and whether they are shrewd buyers or simply Oracle's dupes, it matters little to those of us in the outside world. What might matter more is some real and honest accounting of this project or others implemented with a similar philosophy, to better inform those of us in a position for making such adoption decisions in the future.