Thursday, September 06, 2007

Regents Vanilla

regentsvanilla.jpgThe 2004 independent CIO’s report did not paint an encouraging picture: IT with a “can’t do” attitude; a serious risk that the administrative systems were at the end of their life, subject to unpredictable failure; no strategy or institutional will to address the issue -- and even if the institutional will could be summoned, any fix would likely take 5-10 years and $70-$100M.

Not good.

Within days my arrival at ASU in August of 2005 (New Post), it became clear that if ASU were to move forward technologically, some solution to the ERP puzzle would have to be found: a daunting task since smart people at ASU had been trying to solve that puzzle for the previous decade.


  • The Student Information System, SIS, had been in place at ASU since it was written in 1980. In 1992, the Human Resources portion was converted to a vendor's package and its database moved from IDMS to DB2, replacing the network/hierarchy database structure with a more standard, better-supported relational database. However, the SIS proved more difficult to convert.

  • By 1995, it was already clear to many at the University that our 15-year-old system would have to be replaced. A 2-year effort, the "Student Process Reengineering Project," was launched University-wide to develop a common understanding of how to create a new system. The effort didn’t result in a new system but did expand the life of the old one by adding a web self-service front-end and DARS, a degree audit system.

  • In 1999, ASU took another 2-year run at developing the institutional will to replace the aging system, this time through a development partnership with SAP. SAP and ASU staff worked together to define a student information system for North America but disbanded their cooperative venture before deploying any product at ASU.

  • In 2004, right after the independent IT report came out, ASU began exploring a PeopleSoft option. However, this was suspended when Oracle acquired PeopleSoft, making the future of the product temporarily cloudy.


In any case, the price tag on the table was still $70M+ dollars, and the risk of total failure loomed large. To put the cost in perspective, $90M is the entire annual IT expenditure for the whole university. $70M is serious money. Combine the magnitude of that expense with the very real risk of failure: U of A’s 7-year Cosmos Project was about to be reported to ABOR as an aborted attempt, after $18M spent trying to replace just the Student Information System -- without success. And stories of larger-scale projects at schools similar to ASU in size and complexity -- Michigan, Wisconsin, Minnesota, Johns Hopkins -- ran to the $100M+ range. ERP replacement at those prices, with those delays, those disruptions, and those risks, just seemed like a bad idea.

We tried for several weeks to formulate a renovation strategy, similar to the approach taken in 1995, based on encapsulating the existing system and refitting a new front end. But to do that would require an internal technical champion, and no one was stepping up to lead. Perhaps no one really believed renovation was even possible anymore.

The last week of August, Max Davis-Johnson and I went to visit Fred Estrella at NAU (Visit to NAU). Max had led NAU’s PeopleSoft team for Fred but had come to work at ASU the year before. On that trip, I learned that NAU’s experience with PeopleSoft HR in the late 1990s had been difficult but that their recent project, the one Max and Fred led, had been pretty successful. They had replaced the Student System successfully in 3 years:
…I was very impressed with Fred Estrella (the NAU CIO), his crack IT team, and the administration folks that helped craft their PeopleSoft Human Resources and Student Administration implementation. From what I gathered, their implementation did take somewhere between 3 and 5 years, and while they managed to skip the worst of the “monster” phase, their system did have to “grow live” rather than “go live.”

But all the participants in the project that I met — and I met easily 20 from both the technical and “business” side — were unanimous that the new system meets their needs better than the old system and it gives them a better platform for addressing the future.

It was also interesting to learn that their decision to go with PeopleSoft did have its roots in a crisis — a registration failure one fall that sent all the students to the gym with pencils and 3×5 cards.

Given that we want to avoid a crisis, I wish there was a way to wave a magic wand and be where they are now.

In a sense, our magic wand came in the form of an ice cream flavor: Regents Vanilla. It didn’t work instantly, but it did put us in NAU's position inside of two years from when we started - a far cry from the predicted 7 years.

In a blog post at the end of September of 2005, (The Relative Importance of Keeping Score), I drew an analogy between the administrative computing system and the scoreboard at a football game – each necessary to play the game but neither one central to the game itself.
...as important as this function is, the scoring system isn’t in any sense strategic. No student is going to choose ASU because of the student administration system that we pick. The NSF won’t select ASU to lead an ERC because we have a state-of-the-art ERP (aren’t acronyms great?).

Despite the fact that it wasn’t Core, I advanced the argument that the investment to replace ASU's administrative system still had to be made:


  1. In the considered and expert opinion of its authors and maintainers, the University’s core information system, the Student Information System, simply does not have the flexibility to meet the needs of the New American University.

  2. The only other user of ASU’s SIS system, Northern Arizona University, has already experienced a failure of that system, and as a result, abandoned it in favor of an industry standard ERP solution from Peoplesoft/Oracle.

  3. The university is not prepared (nor should it be) to modify its enterprise goals and strategies to continue to fit within the confines of what the existing infrastructure can accommodate.

  4. Given the foregoing, a new system is inevitable for ASU. It is only a question of when we start, how long it will take, and how much it will cost.

  5. There are no serious alternatives to a vendor supplied system. No champion has come forward with a vision for internally writing a new system from scratch or radically rewriting the current system.


Based on this set of facts, I’m convinced that ASU should implement a vendor supplied solution that removes the scorekeeping system as an obstacle to change subject to the following criteria:

* we want the lowest risk we can find
* we want the lowest cost we can find
* we want the fastest implementation we can find

If the scorekeeping system is not strategic, then the goal is to remove it as a constraint as quickly and as cheaply as possible, while minimizing the risk of failure.

We introduced the idea that to replace a non-Core yet essential system, ASU needed to find the lowest risk, lowest cost, fastest approach. We contrasted that with Rocky Road, the traditional approach that has caused so much risk in the marketplace.
va·nil·la (va'-ni–la) adj.

  1. Flavored with the flavoring extract prepared from the cured seedpods of any of various tropical American vines of the genus Vanilla in the orchid family, especially V. planifolia, cultivated for its long narrow seedpods from which a flavoring agent is obtained.

  2. Lacking adornments or special features; basic or ordinary: “We went through a period of vanilla cars.” (Charles Jordan)

  3. Implementing a full featured ERP product that has proven its ability to run a University by customizing the product as little as possible and instead adapting the business processes to match the software’s capabilities.

  4. The fastest, lowest cost, least risk method for implementing an ERP.



rock-y road - (rak'-e rod) adj.

  1. A common ice cream flavor. Though there are variations on the flavor, it generally combines vanilla ice cream, chocolate ice cream, marshmallow and nuts. The flavor was created in 1929 by William Dreyer during the Great Depression “to calm jitters.”

  2. A rough and difficult path, a metaphor for any challenging and uncomfortable journey.

  3. Implementing a full featured ERP product that has proven its ability to run a university by convening committees to redesign, usually on paper, the business practices the software supports, and then implementing these newly redesigned procedures through the use of custom code that overrides the base functionality of the product.

  4. The slowest, most expensive, highest risk method for implementing an ERP.



After talking with CIOs from both the higher education and commercial communities and reading the histories of failed and problematic implementations of ERP systems, I know what my favorite flavor is….Regents Vanilla.

What makes Regents Vanilla so attractive? Well the NAU SAS/HR system was developed from a system with common roots to the ASU system. The organization that developed it, NAU’s IT team, has an excellent working relationship with the ASU team. Regents Vanilla has been in production successfully for 3 years and has proven its ability to successfully run an Arizona Regents University.

If we implement the NAU system with the minimum set of changes possible (and defining that minimum is the key of course), what good will it do us? Well, it will be the fastest way to implement a new scorekeeping system that doesn’t act as a gate for the go forward. It will also be the cheapest way, if for no other reason than because development costs will be lower. And it will present the lowest risk, from a technical point of view, because it’s already proven to work in the closest real time production environment to our own.

So what’s the rub? Well, implementing vanilla means changing procedures, which is never popular and sometimes unwise. (A theme that will emerge again near project's end...)

Regents Vanilla changed the debate. It lowered the cost, risk, delay and disruption to a level that gave decision makers comfort that there was a strategy that with high liklihood could address the issue without derailing the progress of the University. Over the next 3 months, the growing team of technical and functional experts were able to build institutional will around the Regents Vanilla plan -- a system based on NAU’s successful code, to be deployed with alacrity to minimize cost and risk. By January, we were ABOR bound.


Next Up: Strategic Technology Alliance: Avoiding the Phoney War
Previous: How Deep Was the Hole?

0 comments: