Common Enterprise Applications for the University of Wisconsin System

Key Takeaways

• System-wide governance, a project management office, a 10-year roadmap, and a rigorous budget process have been critical to the success of common enterprise applications in the University of Wisconsin System.
• Because of ongoing environmental changes, funding models also need to change every two to three years.
• An analysis of the return on investment or the value proposition of a common enterprise application should be undertaken early in the initiative.

The 15 institutions of the University of Wisconsin System have a 12-year track record in sharing an expanding portfolio of common systems. In some cases, such as the Desire2Learn learning management system, a single infrastructure supports the students, faculty, and staff at all of the institutions. In other cases, such as the PeopleSoft student information system, the software is run locally at each of the institutions, but an overarching support structure assists with license negotiation, procurement, installation, consulting services, and interfacing. The path leading to this high degree of collaboration was not always straight, however.

Background

Before 1971 Wisconsin supported two public higher education systems. The University of Wisconsin System had four campuses plus a few two-year colleges, and the Wisconsin State University System had nine institutions. The legislature merged them into one University of Wisconsin System in October 1971 with 15 institutions. For years they lived with two payroll systems and several financial systems, and built interfaces between the general ledgers and charts of account. In 1994 the UW System finally merged the two payrolls and created a single processing center. The pain of the merger can be measured in the 23 years required to create a common payroll and benefits operation.

The UW System adopted one common enterprise system after another in the critical decade before Y2K. The imminent threat to legacy systems as well as the maturation of off-the-shelf higher education applications drove adoption of new systems. Although there was no comprehensive plan, and no real intentionality before 1997 for adopting common enterprise systems, most UW System administrators believed working together on these expensive IT projects would be less expensive than implementing them 15 times.

The adoption of a shared financial system in 1997 compelled UW System President Katherine Lyall, Academic Vice President David J. Ward, and Business Vice President Marcia Bromberg to call for an IT summit in December. All 15 institutional CIOs, provosts, and chief business officers attended. The participants created a Common Systems Steering Committee to act as an oversight group for the handful of common enterprise systems launched since 1994. In August 1998 the president tasked the steering committee to create a common systems "framework."

The UW System has been retooling and reworking the "framework" for the past 12 years. The steering committee evolved into the Common Systems Review Group, and membership grew from seven to 19. Since 2006 all 14 institutions (UW-Extension and UW-Colleges had previously merged into one institution) have had a representative on the Common Systems Review Group. The representatives provide a balance between chief information officers (CIOs), chief business officers (CBOs), and chief academic officers (CAOs). One chief student affairs officer is selected as an ex-officio member. The UW System CIO and chief financial officer (CFO) serve as the standing co-chairs.

The common systems portfolio, which initially supported three projects in FY1999 at $270,000, has grown in FY2012 to 15 projects and production operations at $29 million. These figures do not include software licensing costs.

As the complexity of the enterprise portfolio grew, the Common Systems Review Group developed more sophisticated tools and processes for managing cost, scope, and selection. This was a highly iterative and evolutionary process. Like many other state systems, the University of Wisconsin's path to collaborative enterprise systems is a product of the tensions between local autonomy and centralization. Despite the differences in history and circumstances between state systems, there are always some interesting experiences that might provide guideposts for others coming along later. The development of common enterprise systems has had some success in Wisconsin, but some failures as well. In this article we've tried to tease out some universal lessons learned and some cautionary advice for sharing enterprise systems among institutions.

The Common Systems Portfolio

As early as 2001 the Council of CIOs from all of the UW System institutions created a strategic plan that foreshadowed much of the current portfolio. They used the conceptual framework of a fully online curriculum, which has not yet been implemented in practice, to delineate the necessary cross-institutional technologies. Figure 1 shows the 2001 conceptual framework of the technology portfolio necessary for a fully online, system-wide curriculum.

Figure 1. Technology Needed for UW Online

The current portfolio includes seven sets of related applications, each governed by a system-wide executive committee that provides budget and operational oversight to any applications in production, vets and approves upgrades or new project proposals, and annually presents the next fiscal year budget proposals to the Common Systems Review Group. This executive committee governance model has evolved since the creation of a payroll Service Center Committee in 1997. Today, no new projects may come forward without the sponsorship of one of the seven executive committees.

Each portfolio typically contains more than one project. The following list of portfolios is in chronological order of earliest Common Systems Review Group funding. The corresponding executive committee typically evolved at a later date.

• Shared Financial System (1999)
• Human Resources, Payroll, Benefits (1999)
• Student Administration (1999)
• Academic Systems (2001)
• Identity and Access Management/Middleware (2002)
• Data Privacy and Security (2009)
• Library Systems (2011) (Note that the Council of University of Wisconsin Libraries was the earliest executive committee and had its own separate funding for automation before the Common Systems Review Group was created. It joined Common Systems for the first time this year.)

An eighth application, the UW System's wide-area network, has been governed by an educational cooperative, WiscNet, with a state-wide board. It has never been part of the Common Systems Review Group portfolio.

Philosophical Underpinning for Common Systems

When common systems were first thought about in 1997, no one created a vision statement, mission statement, or goals document. When we were mulling over what direction to take in putting some structure to the common systems effort, the CBO at UW–Madison summed up what was probably a majority opinion. In a December 19, 1997 memo titled "IT Common Systems Planning Structure," John Torphy wrote to Ed Meachen:

1. We already have groups addressing common systems in three major areas — students, financial and library.
2. Other groups are already thinking about the issues.
3. We don't need to create a new committee to review and initiate action when the people who know what is going on have already initiated it.
4. The real issue is funding and timing of all these common systems. Those are decisions that a steering committee cannot make. The provosts, Institutional Business Representatives and UW System staff can, however, propose some basic policies regarding funding responsibilities.

Indeed, funding and timing have remained front and center even as the portfolio and the Common Systems Review Group grew in scope and size, although from time to time the group has also tackled the issue of "value." Since the first IT summit in 1997, the value discussion has had wrapped within it the issues of priorities, funding, and service. The clearest articulation of the value proposition occurred at the January 13, 2005 retreat "Vision for Common Systems." Its audacity is quite refreshing:

What is the vision for common systems in the next 10 years? Common systems are sleek, efficient, robust, and innovative systems that enable users to be efficient and effective in their work of teaching, learning, scholarship, service, and administration with no barriers in terms of time or place. They are strategic investments that provide increased efficiency and effectiveness while maintaining or improving quality for all UW System institutions. The common systems environment provides seamless and integrated access to data and information for conducting the business and making the decisions of the universities.

Few of our enterprise systems are "sleek" and "innovative," but even by 2005 the evidence that the portfolio of products had helped the UW System accomplish a number of key benefits was clear. We had come a long way in terms of:

• Leveraging a large higher education system to solve common service problems
• Providing a base level of technology services for every institution in the UW System
• Reducing technology complexity for students, faculty, and staff
• Lowering the cost of licensing software and hardware
• Reducing the complexity of interfaces and reporting lines to state and federal government and other stakeholders

On the other hand, some compromises cost the UW System some missed opportunities. UW System leadership and the Common Systems Review Group never contemplated centralizing the student information system. Consequently, each institution implemented their PeopleSoft Campus Solutions instance somewhat differently, precluding a common data dictionary. This decision, or lack of decision, adversely affected the argument for common analytics tools and delayed the development of an action analytics strategy to take full advantage of the enterprise systems.

What We've Learned...and Cautionary Notes

Of course, it turns out that selecting and supporting common systems is a lot messier than the vision we articulated in 2005. How do you manage funding during periods of state economic decline? How do you set project priorities in the midst of political and administrative events that are often beyond your control? How do you manage to deal with the overall common system infrastructure when you're faced with a runaway or failed project? The University of Wisconsin has faced all of these unanticipated events during the common systems era.

Funding

We began the common systems effort in a moment of opportunity seasoned with a touch of necessity. The effort was driven by actions of the UW System Administration rather than by a grassroots movement within the individual institutions. The first systems were administrative, and they developed organically out of the realities of the merger 30 years earlier. Thus, UW System Administration did not seek institutional buy-in. Complete fiscal buy-in would have required the UW System institutions to divide up the full cost of the growing portfolio. Instead, UW System Administration asked for a quarter of the total cost, and the institutions readily paid the $3 million. It was an incredible bargain for them. The remaining $9 million came from various system-wide holding funds.

This "accidental" common systems approach may have been driven by necessity, but it proved problematic over the long run. While there was plenty of money in FY2001 ($2.4 million carried over to the next fiscal year), funding declined in the next two fiscal years while the portfolio grew, and FY2003 ended with a $7.2 million deficit. The combined contributions from the UW System institutions remained at $3 million as other sources of funds fell from $9 million to $4 million. The UW System is large enough to self-fund a debt, but it would be imprudent to allow the debt, especially on operating budgets, to grow too large.

By 2010 the internal debt had become so significant that the Common Systems Review Group determined to move forward on a "pay as you go" model with a long-term debt retirement component. So FY2011 became the first year since FY2001 that the entire portfolio had to be funded out of current revenues. It is particularly unfortunate that the new balanced budget approach occurred at the very moment the national economy went into serious recession. Major budget cuts at the campuses pushed administrators to make commensurate cuts in proposals for common systems. Almost all the common systems portfolio is operational, and operational budgets may be cut, but only at the margins. It is not realistic to underfund the general ledger, reporting, or payroll/benefits systems and risk a failure.

Although the UW System did not tackle the funding issue up front, it did have the capacity to do long-term borrowing, appropriate in building out capital projects. Accounting rules allow for capitalizing large and expensive IT projects and amortizing them over some number of years. It might have been wiser to set aside a much larger collective pool of resources to fund ongoing operations and not tap the operating budgets of the institutions each year. But funding models are often dictated by the economic environment, and over the 12 years of common systems we have gone through three iterations of funding models, none of which seemed appropriate for longer than two or three years. A system-wide collaboration needs to remain flexible, resilient, and creative. It also should do something the UW System never did: undertake a credible study of the return on investment of a "common" versus "individual" enterprise systems approach. It's possible there would have been no financial return on investment, but perhaps a value return on investment. In any case, it would have positioned the university system to answer such questions as: How much money did we save by implementing a "shared" financial system rather than 15 financial systems? How much is saved annually? And what's the value added above and beyond cost savings?

New Projects and Ongoing Operations

Determining the best method for selecting new projects for incorporation into the common systems portfolio is the pivotal question that defines much of the history of the UW common systems. Each year from 1997 through 2002 UW System Administration hosted an IT summit that included the 15 CAOs, CBOs, and CIOs of the UW institutions. Each year the summit attendees wrestled with the budget and the portfolio. Over the years the summit group and the Common Systems Review Group hammered out a process and a philosophy for surfacing and approving new projects. What started with an informal process and an open-ended budget evolved into a rigorous and highly structured exercise.

Over the years the CSRG created four structures to guide the development of the portfolio.

• A system-wide governance structure through which all common systems proposals come to the Common Systems Review Group Budget Committee. Over time, executive committees emerged to provide governance oversight for each of the major enterprise systems. The executive committee structure allowed for a sifting and winnowing of any new projects and of production operations (which might include expensive upgrades). Highly representative governance groups are now in place for Academic Systems, Student Information Systems, Shared Financials, Human Resources, Libraries, Identity & Access Management, and Data Security & Privacy. Each of these governance groups owns a portion of the current common systems portfolio.
• A Project Management Office (PMO). The Common Systems Review Group agreed in 2007 to create a PMO to provide day-to-day management of the portfolio. The PMO is led by a project director who has responsibility for overseeing the managers of major new projects or upgrades. The project director also works with most of the executive committees to help guide new initiatives. The PMO also has a budget analyst who tracks the individual budgets of each of the portfolio operations and projects. The PMO is a critical tool in tracking the week-to-week operation of a $20 million enterprise portfolio. The PMO brings professionalism, process, and structure to every major new project. Rules have become clear for engaging a professional project manager, adopting a project governance structure, following national standards in constructing requirements, and creating a project plan with measurable objectives and established outcomes.
• The Common Systems Roadmap. The Common Systems Review Group met at a two-day retreat in January 2005 and agreed that a strategic plan for common systems would probably be ineffective. The history of the first six years demonstrated the difficulty of developing an IT strategy that would have a credible lifespan for even two years. Instead, the group chose to develop a philosophical scaffold with a set of goals. The group laid out a 10-year roadmap that recognized there would be many ways to use technology, including technologies not even in the current marketplace, to achieve those goals. Each year the Common System Review Group meets for a day to refresh the roadmap. The enduring goals (from the September 2010 roadmap) include:
  • Deliver high-quality education to students wherever and whenever they desire it
  • Improve knowledge management and data-driven decision making to better facilitate student access and learning
  • Add measurable value to faculty, staff, and students by "cutting red tape" and improving services
  • Improve business processes to become more efficient
  • Reduce the risks inherent in supporting legacy systems
  • Safeguard information systems and data with the adoption of best practices in security and privacy
• A rigorous, analytical process for budgeting common systems. In 2006 the Common Systems Review Group created a six-member budget committee to review all portfolio budgets for the coming fiscal year. Executive committees and project sponsors fill out a template that requires each production operation or new project proposal to submit a guided narrative accompanied by a detailed budget at least six months in advance of the next fiscal year. The budget committee has its own measurement tools based on the goals of the Common System Roadmap to weigh the priority of each proposed project. The project sponsors make presentations to the budget committee and are questioned in detail. The budget committee meets again without the sponsors to accept or reject the proposals and to alter budgets if necessary. The committee presents its recommendations to the full Common Systems Review Group by late January in anticipation of the start of the July 1 fiscal year. The group members vet the recommendations with their CBO, CIO, and CAO colleagues before submitting the final budget to the UW System chancellors for ultimate approval. Any increase in total portfolio spending above the approved budget over the course of the year requires the approval of the chancellors' group. In the 12 years of common systems, no total portfolio has ever exceeded the approved budget.

These four structures — system-wide governance, PMO, Common Systems Roadmap, and a rigorous budget process — have been critical to the success of the UW common systems. They provide predictability, fairness, and transparency for any group that decides to bring a project forward, for any production operation, and for the institutions that must pay for the systems.

Finally, it is important to consider administrative turnover. Common System Review Group members are appointed for three years on a staggered basis. Only the CIO of the overall UW System, who co-chairs the group, has served continually since 1997. Today, there is one CBO and no CIOs or CAOs remaining from the first five years of the common systems effort. Finding yourself, as a newly appointed CAO, immersed in discussions about the funding and future of large enterprise administrative systems about which you know little or nothing is discomforting. Therefore, the Common Systems Review Group and the PMO focus on educating new members. Even so, it is challenging to come up to speed to serve on this complex and highly structured system-wide committee.

Future of Common Systems

As important as common systems are, they are only one part of a larger infrastructure of technologies, policies, and processes ultimately needed to offer students a more extensive curriculum than they can get at any single institution, and to offer it whenever and wherever students need it (see Figure 2).

Figure 2. Common Systems in the UW Academic Infrastructure

The admonition to remain flexible, resilient, and creative remains pertinent. Any significant disruption might cause some campuses to question the value of staying with the consortium; after all, the annual bill each pays is considerable. This is a case where having a better definition of the value proposition and the costs avoided by the common systems effort, not just the costs incurred, would serve us well. Nevertheless, we are optimistic because the executives of the UW System institutions have stuck with the common systems approach through the implementation of the most ambitious and expensive project to date, a new HR system.

© 2011 David Stack and Edward W. Meachen. The text of this EQ article is licensed under the Creative Commons Attribution-Noncommercial 3.0 license.