My NacuboWhy Join: Benefits of Membership

E-mail:   Password:   

 Remember Me? | Forgot password? | Need an online account?

Business Officer Magazine

Mitigating the Risks of Big Systems

Consider the Community Source model as a way to blend the economies of off-the-shelf software with the customization advantages of owning the system.

By Brad Wheeler and Joanne DeStefano

Colleges and universities are complex organizations with growing needs to manage the integrity and timeliness of information. Information technology systems have risen to address this challenge and have become absolutely mission critical for the information-intensive work of student recruiting, registration, online instruction, research administration—and most certainly for financial administration. By 2007, many institutions had either recently replaced their large-scale administrative systems or were preparing to do so. Such system decisions invoke multiyear costs and risks for institutions—sometimes in the tens of millions of dollars or more. By 2002, conservative estimates placed higher education’s investment at more than $5 billion in these systems. In this article we assess the motivations for big systems, their inherent risks, and a new strategy for mitigating those risks.

Big Systems

For most colleges and universities, there are the “Big Three” administrative systems:  student information, human resources, and financial systems. They are often known by the corporate name of enterprise resource planning (ERP) systems. These three often connect to other essential systems for course management, endowment, library, and many others, but the big three represent some of the largest and most critical system expenditures. They promise integration of data and processes (e.g., a student action of dropping a class will update all relevant information systems). They have enormous switching costs and lifecycles that may span one or more decades. Depending upon their fit to an institution’s needs, they can enable or constrain an institution’s innovation and effectiveness.

The cost of administrative systems to the academic treasury can be immense. Although some colleges and universities—such as the University of Akron, Ohio, or Lee College—report successful large-system implementations (that meet needs, are on time, and remain within budget), large expenditures on any system do not ensure success. There are many stories of unanticipated, costly implementations with seemingly endless good dollars thrown after bad for support and upgrades that continue to raid the academic treasury. In 2006, the University of Wisconsin System halted and wrote off its $26M payroll project after six years of effort. Major problems with financial aid payments from a new system were among the reasons for executive departures at Lansing Community College, Michigan, after the trustees initiated their own investigation of the system. The North Dakota University System reports cost overruns of at least a $5 million on top of their $35 million project. The 23-campus California State University System is spending at least $440 million on an ERP, and a 2003 audit report notes that the costs could rise to $662 million. Many of the Big Ten universities have spent from $50 million to $150 million on their systems. Even very small institutions see $5 million to $10 million in costs, representing an enormous percentage of the annual budget. Higher education is not alone in these challenges. Major corporations including Dell and Hewlett Packard have either aborted large-scale implementations or at least suffered major business disruptions.

One thing is certain: The selection of a suite of comprehensive systems for an institution represents more of a path for the future rather than a simple product choice. What should campus leaders consider in choosing such a path? The following discussion examines institutional motivations, big system risks, and risk mitigation strategies.

Institutional Motivations

Community Source Reading

Given enormous costs and checkered track records of success, why would any institution undertake such risks? Most ERP decisions are driven by one of the following rationales:

Rational model. Large-scale system implementations are viewed as a necessary means to an end. According to an ECAR study, the most frequent motivation is “replacing aging legacy systems” followed by “improve service to customers.” Some institutions face end-of-technology-lifecycle for aging systems and have no choice but to transition. Others see value in the promised integration of these new systems to provide the data that faculty, staff, and students need.

Magic bullet theory. The magic bullet theory, described by M.L. Markus and R.I. Benjamin in the Sloan Management Review, Winter 1997, is anchored in the fallacy of technological determinism—meaning IT causes a desired outcome. In contrast to the rational model’s view of big systems as a means to an end, the magic bullet theory tacitly asserts that a big system investment will solve problems. Examples include new systems promising headcount reduction or that staff will work in new productive ways while being constrained from falling into unproductive habits. This is a much more appealing prospect than considering the formidable work of institutional change and its attendant human challenges.

Trojan horse strategy. Parallel to the mythical account of the Greeks and the walled city of Troy, the Trojan horse plan is institutional change disguised as an ERP. The strategy is appealing because the veiled gift avoids direct confrontation of the required change. The gift (system) surprisingly imposes a new set of processes on its recipients. The Trojan horse strategy is actually a dangerous variant of the magic bullet theory. It sets up the system, IT department, and project sponsors for recrimination because IT becomes the bearer of institutional action rather than appropriate administrative leaders and processes.

Big System Risks

San Joaquin Delta College’s Financial System Decisions


The decision by San Joaquin Delta College (Delta College), Stockton, California, to join the development of the Kuali Financial System was a strategic decision concerning the long-term direction that the college would take for mission critical systems. Although the current Oracle financial system is adequate for our needs, it is very cumbersome when we need to make changes and difficult to integrate with other systems. The decision to join Kuali was not based on a “burning need” to replace the financial system but on a commitment to open source.

Dr. Raul Rodriguez, the college’s president, provided the impetus for Delta’s decision to join the Kuali consortium. Rodriguez believed that the college needed a more secure direction than the mix of homegrown and vendor systems we were currently using. Although the core expertise of our IT shop was development, it was clear that this approach was not sustainable in the long run. So reluctantly, we began to look at integrated vendor packages. We found these packages not only very pricey; they also contained major gaps in supporting how we currently do business.

As a result of attending a conference on open source, Rodriguez and I met with the Indiana University (IU) IT team. Rodriguez made the commitment to join Kuali, then we came back and sold the idea on campus both to the board of trustees and to the campus constituent groups through the Appreciative Inquiry Budget process. In essence, we took decisive action and asked for forgiveness, of a sort, after the fact. The difference is that we could see the importance of this decision for the college, and we were passionate enough about it to infuse others with that enthusiasm. Open source played to our strengths in development. The commitment of the major universities to the sustainability of the community would ultimately provide the long-term security that we needed.

The other major factor that convinced us to join the Kuali effort was the ability to look at the existing system at IU that would be migrated to an open and modern architecture. As part of our due diligence, our financial leadership and staff observed the current system’s functionality and liked what they saw. Our financial director, Claire Tyson, went from initial healthy skepticism to playing a leadership role in Kuali’s development. After two years of development, we know that Kuali will be a success and will leap-frog existing vendor solutions for ease of use and functionality. Delta College has invested approximately $400K in development resources and cash in the Kuali project. 
Encouraged by the pending success of the Kuali Financial System, Delta College is now totally committed to viable open source solutions. Sakai is being used for Internet classes and uPortal is being used for our student and staff portal solution. Delta College is a founding partner on the “big one,” which is the open source development of a student information system, the Kuali Student System. It would be fair to say that Delta College is becoming a “petri” dish for open source systems in higher education. 

LEE BELARMINO is vice president for information services, San Joaquin Delta College, Stockton, California.

Big systems have both short-term and long-term risks. The classic view of a full system lifecycle across 10 to 20 years demonstrates that 80 percent of explicit system costs fall in the post-implementation phase. The many costs of lost opportunities are rarely quantified or even understood. Typical risks include the following:

Risk #1: Institutional fit. A square peg meets a round hole, meaning that the software does not fit with the operating model for the college or university. For instance, higher education and corporate accounting are not the same. Our fund-based accounting, multiyear contracts and grants, stewardship responsibilities, and other essentials are often not in the DNA of corporate systems. Corporate systems transferred into higher education often mean lots of expensive “shadow systems” to get the information that we really need.

Risk #2: Implementation challenges. Many observers note that the cost of the software is usually quite small in comparison to the implementation costs; and, frequently, the problem is attributed to some mismanagement of the implementation. An accurate assessment requires a deeper look at the complexities of implementation and the interaction of politics, ill-fitting applications, and management issues. The lessons from M.L. Markus’s 1983 classic “Power, Politics, and MIS Implementation” remain true today—system implementations are not impeded by just politics or simply bad software, but rather, the real story is a complex interaction of both.

Risk #3: Vendor behavior. In an efficient market, competition would continue to refine software offerings and pricing power, but higher education is anything but an efficient market for big systems. We are a unique industry with collegial decision making that can lengthen sales cycles. We also have public stakeholders and less-than-deep pockets and are quite small in size relative to other sectors of the economy. All is well when values are aligned, but shareholder needs for short-term profits often drive behaviors that are not in the interest of higher education:

  • Software patents can freeze competition and advance monopolistic pricing.
  • Consulting and service dependencies can create ongoing issues.
  • Software evolution is expensive, so we typically must wait for a more massive upgrade. The value of the upgrade additionally depreciates as institutional attention becomes frozen for months or even years. Conversely corrective upgrades can be forced upon us.
  • Product lines can be dropped.
  • Mergers can occur.

Each of these is a perfectly normal part of commercial activity, but each represents a risk for higher education.

Risk Mitigation Via a New Path

The often-framed system choice is either building a system or buying one off the shelf. Each path represents a known bundle of risks or risk mitigation tactics. However, what we really want is a new path that offers the best of both. The new option is to (metaphorically) borrow.

The Community Source model, based on the principles of open source software development, blends the economies of buying packaged software with the control-of-destiny of owning it.  It is “of, by, and for” higher education, and it represents an industry-level coordination mechanism for higher education’s comprehensive system investments (see sidebars “Financial System Decisions at Cornell University” and “San Joaquin Delta College’s Financial System Decisions” for several recent overviews of Community Source projects). At its heart, it is a model of “enlightened self interest” that balances near- and longer-term needs and risks for colleges and universities.

Fixing fit early. The hallmark of Community Source projects is that they begin in higher education and are directly steered by the investors who will be using them. Heterogeneity and detailed design reviews by the Kuali Financial System investors (both public and private, large and small, single and multicampus institutions) demonstrate that the system will in fact fit the needs for higher education.

Financial System Decisions at Cornell University


The financial system at Cornell University, Ithaca, New York, is a 1970s homegrown, online and batch Natural/ADABAS system that manages around 70,000 university accounts and millions of transactions annually. The general ledger system has been augmented by efforts with a data warehouse, reporting tools, and other added transactional processing programs using Web/workflow tools to meet current needs. Through all the productivity enhancements, Cornell has been unable to address the key data structure and architectural issues. Key concepts are missing and control data, structured data, and freeform data are sometimes all represented in the same table or file field. The result is that management decisions may be based on system capabilities and not business requirements or needs.

Cornell implemented PeopleSoft HR/Payroll in 1999 and PS Contributor Relations in 2004 and is working on implementing PS Student. Given the current state of the financial system, Cornell felt at risk to wait until a student system was fully implemented before beginning work on a financial system. We considered rewriting the financial system ourselves but rejected the option, because of the risk of having the university dependent on a handful of technologists for the system development and source code support.

Because the Indiana University System, Bloomington, was the starting point for the Kuali Financial System, Cornell evaluated the IU system to see if Kuali could be considered an option. Once seeing the functionality of the Indiana legacy system, Cornell was immediately interested in joining the Kuali partnership as an alternative to waiting five years to implement a costly vendor system. The Indiana system was developed for campus access and has been in use for more than a decade. The system was developed by and for higher education, unlike vendor enterprise resource planning (ERP) solutions, which are retooled corporate systems that do not fit our complex needs of fund-based accounting. Many of the constructs of corporate accounting do not apply and actually hinder effective fiscal practice in higher education. Studies have proven that ERP implementations have been very costly and disruptive because institutions were required to adapt policies and processes to fit the software rather than use the software as a tool to achieve their own objectives.

JOANNE DESTEFANO is vice president for financial affairs, Cornell University, Ithaca, New York.

A flexible implementation. Since the software code is open for inspection and modification by anyone, the technical cost of integrating it with other systems is often lower through simplicity. Openness also drives granular modularity so that implementations need not be large, black-box bundles as all-or-nothing propositions. Likewise, openness also drives down the need for proprietary knowledge from specialized consultants. While consultants as extra hands to help during an implementation will continue, the openness drives down their hourly rate. And the community itself possesses much of the knowledge and “how to” wisdom that is freely shared on open discussion lists. Our experience is that these lists and participating in the Community Source projects are efficient forms of staff development and cross-institutional knowledge sharing.

Unbundling software and support. Software that you build gives an institution perpetual right of use. No one can tell you to stop using it, pay additional fees, upgrade now, or eliminate the product. You can give it to others or sell it. Owning the code, however, means you usually paid the full cost of creating it just the way you wanted it—at the time. You must then pay the full costs to maintain it and retain the staff expertise to do so.

In contrast, software that you buy (packaged systems) comes with lots of terms in the license. You may have to pay each year to use it, pay additional fees if your needs change, or just pay more if the owner raises the price. You may not be able to share or receive software enhancements from others, and any changes (customizations) that you make must often be redone each time the owner updates the software. The proffered advantage is that the vendor provides efficiencies in economy of scale for maintaining the software over homegrown systems.

The Community Source model of open source software blends the best of both build and buy. Any institution can download the Kuali system without fee or consultation and have full rights to use, modify, redistribute, or even sell it as they see fit. Thus, institutions enjoy the same rights as building their own software, and most will choose the enlightened self interest of participating with the software community for the software’s continued improvement. Community participation includes many roles (design, quality assurance, documentation, etc.) beyond just programmers. Organizations like the not-for-profit Kuali Foundation provide a coordination mechanism for new feature development, quality assurance testing, user conferences, and release packaging.

The greatest risk mitigation of this model is that it unbundles the market for consulting services around the open software from proprietary ownership of the code. Many institutions will choose to purchase for-fee services for big system implementation, integration, and support work, and a number of vendors have adapted their business models to participate in this new ecosystem.

Zero disruptive upgrades. The Indiana University financial system has been upgraded 47 times to new releases during the past 10 years, and only two of those required any substantial interruption of services. IU could do that because it knew the system and could make continual, small improvements to add needed functionality. Community Source software has the same model and can free institutions from the substantial upheaval caused by large, multiyear upgrade interruptions for vended systems.

Continuous progress is possible as any institution (or company) can enhance the software and then share that improvement back to the community. Open source software methods represent the shortest path between system users and developers. It is not unusual to see a new enhancement design proposal be reviewed, modified, and decided in a day by multiple institutions to ensure that developers get the best direction for their work.

Collective Risk Mitigation As a Strategic Choice

The success—or failure—of community source is based in collective action by colleges and universities. In the past two years, the Kuali Financial Systems project has demonstrated that we can design, release, and improve big system software as a community. The second release of the Kuali Financial System is slated for Fall 2007, and some large implementations will begin in 2008. The software is owned by the independent Kuali Foundation, which is now using a similar approach for the Kuali Research Administration System (based on the MIT Coeus Software), Kuali Endowment, and Kuali Rice (see for details). Unlike other higher education consortia of the past, however, everyone has walk-away rights to the code. Knowing that others are using and supporting it provides a considerable hedge to any risks related to the Kuali Foundation.

Big systems carry risk, and no veneer of a risk shell game will change that. College and university leaders must consider the full range of options for risk mitigation as they consider their choice of paths for large system investments. Based on higher education’s decades-long experiences with merits and considerable challenges of the build and buy paths, the borrow path (Community Source model) is becoming a most appealing means of software production and maintenance for higher education.

BRAD WHEELER is chief information officer, dean, and professor, the Indiana University System, Bloomington, and JOANNE DESTEFANO is vice president for financial affairs, Cornell University, Ithaca, New York.