The Kuali Group: Effective Practices and Structures Foster a

The Kuali Group: Effective Practices and

Structures Foster a Successful Collaboration

Bob Albrecht, ECARJudith A. Pirani, ECAR

ECAR Case Study 5, 2007

Case Study from the EDUCAUSE Center for Applied Research

4772 Walnut Street, Suite 206Boulder, Colorado 80301www.educause.edu/ecar

The Kuali Group: Effective Practices and

Structures Foster a Successful Collaboration

EDUCAUSE is a nonprofit association whose mission is to advance higher edu-cation by promoting the intelligent use of information technology.

The mission of the EDUCAUSE Center for Applied Research is to foster better decision making by conducting and disseminating research and analysis about the role and implications of information technology in higher education. ECAR will systematically address many of the challenges brought more sharply into focus by information technologies.

Copyright 2007 EDUCAUSE. All rights reserved. This ECAR case study is propri-etary and intended for use only by subscribers and those who have purchased this study. Reproduction, or distribution of ECAR case studies to those not formally affiliated with the subscribing organization, is strictly prohibited unless prior written permission is granted by EDUCAUSE. Requests for permission to reprint or distribute should be sent to [email protected].

EDUCAUSE Center for Applied reseArch �

The Kuali Group ECARCaseStudy5,2007

©2007 EDUCAUSE. Reproduction by permission only.

The Kuali Group: Effective Practices and Structures

Foster a Successful Collaboration

PrefaceThe EDUCAUSE Center for Applied

Research (ECAR) produces research to promote effective decisions regarding the selection, development, deployment, manage-ment, socialization, and use of information technologies in higher education. ECAR research includes

research bulletins—short summary analyses of key information technology (IT) issues;research studies—in-depth applied research on complex and consequential technologies and practices;case studies—institution-specific reports designed to exemplify impor-tant themes, trends, and experiences in the management of IT investments and activities; androadmaps—designed to help senior executives quickly grasp the core of important technology issues.

From its recent research, ECAR published a study, IT Collaboration: Multi-Institutional Partnerships to Develop, Manage, and Operate IT Resources,1 about IT collabora-tion in higher education. The study results indicate that the higher education IT community has an impulse to be collegial and collaborative, but institutions tend to pursue collaborations if and only if the

collaboration is perceived to benefit the collaborator’s institution.

Literature ReviewThe literature review focused on several

different aspects of collaboration. We examined prior research on the factors that differentiate successful collaborations, specialized collaborations in nonprofit organizations or government agencies, practitioners’ guides for structuring effective collaborations, and specialized collaborations to develop software.

Online SurveyWe designed and administered three

quantitative Web-based surveys. The first was a brief screening survey that was distrib-uted to the senior IT leaders at all 1,473 EDUCAUSE member institutions. We received 586 responses to the screening survey. We next distributed two follow-up surveys. The first was tailored to those institutions that identified themselves as collaborators in the screening survey. This Web-based collaborators survey was distributed to 398 institutions. A second follow-up survey was designed and distributed to those institutions that identified themselves as non-collabora-tors in their screening survey responses. The Web-based non-collaborators survey was

�


distributed to 183 institutions. We received 157 responses to the collaborators follow-up survey and 113 responses to the non-collabo-rators follow-up survey.

InterviewsWe conducted follow-up telephone

interviews with 30 individuals. Interviewees included representatives from both collabo-rating and non-collaborating institutions. These interviews helped us to interpret and explain the quantitative findings and explored how institutional mission and climate influence the IT organization’s approach to collabora-tion, and other topics. Finally, ECAR hosted a roundtable discussion with six IT leaders with significant experience at forming and operating collaborations.

Case StudiesResearchers conducted this in-depth case

study to complement the core study. We assume readers of this case study will also read the primary study, which provides a general context for the individual case study findings. We undertook this case study on the Kuali Project to understand the methods and prac-tices used to manage ongoing collaborative activity, and how the Kuali partners plan for the sustainability of their collaboration. ECAR owes a debt of gratitude to J. Mike Allred, Associate Vice Chancellor and Controller, University of California, Davis (UC Davis); Richard Andrews, Assistant Vice Chancellor and Controller, University of California, Irvine (UC Irvine); Mark Askren, Assistant Vice Chancellor, UC Irvine; Lee Belarmino, Associate Vice President, Technology, San Joaquin Delta College; Wendell Brase, Vice Chancellor, Administrative Services, UC Irvine; Chris Coppola, President, The rSmart Group; Ted Dodds, Chief Information Officer and Associate Vice President, The University of British Columbia (UBC); Stephen Dowdy, Director, Electronic Research Administration, Massachusetts Institute of Technology (MIT);

David Gift, Vice Provost, Libraries, Computing and Technology, Michigan State University (MSU); Aaron Godert, Senior Software Architect/Engineer, Cornell University; Andrew Hollamon, Computing Manager, Computing Services, The University of Arizona; Kymber Horn, Director of Communication and Outreach, The University of Arizona; David Lassner, Chief Information Officer, University of Hawaii; Paige Macias, Associate Vice Chancellor, UC Irvine; Brian McGough, Manager, Research Administration, Systems Integration Team, and Kuali Lead Architect, Indiana University (IU); Kathleen McNeely, Assistant Vice President and Executive Director of Financial Management Services, Indiana University; James A. Thomas, Kuali Financial System Project Manager, Indiana University; John F. "Barry" Walsh, Associate Vice President, Enterprise Software, Indiana University; Martin Wanjohi, ICT Director, Strathmore University; Bradley C. Wheeler, Chief Information Officer, Indiana University, and Dean of Information Technology, Indiana University Bloomington.

IntroductionCollaboration is a tantalizing activity. In an

ideal scenario, the participants pool resources to create a harmonious and synergistic experience that achieves a common goal and is sustained as long as the collaborators wish. But in reality, collaboration can be difficult. Individuality may usurp the collaborative, project interest may lose momentum, and resources may disap-pear, causing the collaboration to drift without accomplishing its original goal.

But when executed effectively, a collabo-ration’s benefits to the IT organization and to the institution can be significant. Collaboration may offer cost savings in various ways to the benefit of both. It may also offer services other-wise unavailable to IT in a particular institution. The key word, however, is effectively; hence, it is worthwhile to observe how a collaboration’s structures and practices enhance its potential



effectiveness and success. In this vein, this case study examines the collaborative practices of the Kuali Project and particularly its first activity, the development of the Kuali Financial System (KFS) enterprise application. As a complemen-tary case study to the ECAR research study on collaboration, this presentation of the collab-orative practices focuses on the collaborative aspects of the Kuali Project rather than the project’s history, structure, or operations. We look at its process from idea through formation to a sustained organization, highlighting how its collaborative nature helped to meet its goal of building a suite of administrative software. The converging of these intentions drives the collaboration for all of the partners.

The spectrum of participants results in some divergent views of the Kuali Project. In part that divergence arises from the nature of collabora-tion: some of the leadership comes from those who are committed to collaboration as a way to address problems of software development that have not been solved by commercial vendors and who see a need for transforma-tion in order for IT to meet the challenges of higher education in the 21st century. Others are challenged by situations in their respective institutions, seeking through collaboration the solutions to challenges of cost, service, and support for furthering academic goals. Apparently, the Kuali Project has successfully embodied the convergence of these interests: one for reifying a vision of meeting higher education software requirements through collaborative resources, the other for meeting daily needs to support the academic enterprise. The converging intentions of these interests drive the collaboration.

The Kuali Project Background

The Kuali Project originated from IU’s need to replace its institutional financial informa-tion system. After evaluating the possibility of building its own replacement system or purchasing a vendor solution, IU decided to

explore the feasibility of using a collaborative approach to build a financial information system together with other institutions. The university is familiar with this method, most notably through its participation “in the Sakai Project to develop an open source course management system for higher education by assigning staff at the participating institutions to develop course management software systems under the direc-tion of a multi-university project board.”2

IU garnered interest from other institu-tions in building a financial system together and subsequently formalized its activities through creation of Kuali, the Malaysian word for wok, which symbolizes the humble but essential nature of higher education administrative systems. Today, KFS is being developed by staff from Cornell University, Indiana University, Michigan State University, San Joaquin Delta College, the rSmart Group, The University of Arizona, and the University of Hawaii, with guidance from the National Association of College and University Business Officers (NACUBO). It received a $2.5 million grant from the Andrew W. Mellon Foundation. The University of California Office of the President, along with University of California campuses at Davis, Irvine, and Santa Barbara, joined the project in 2006.

The KFS consists of a suite of modules that an institution can install at its discre-tion, including Chart of Accounts, Financial Transactions, General Ledger, Workflow, Capital Assets, Budget, Labor Distribution, Accounts Receivable, Purchasing and Accounts Payable, and Research Administration /Contracts and Grants.

As Figure 1 illustrates, the Kuali Financial System Project has several key components.

The Kuali Financial System’s Project Board consists of two representatives from each partner institution—a senior IT manager and a senior financial offi-cial—who manage KFS development. Each institution, however, has only vote. NACUBO and rSmart each has a

�


single nonvoting member who sits on the board.The Kuali Technical Council creates and implements the technical standards for the financial system. Each partner institution has one representative who sits on the board.As with the Project Board, the Kuali Financial System’s Functional Council consists of two or more user represen-tatives from each of the partner institu-tions, but each institution has only one vote. There are also nonvoting represen-tatives from NACUBO and rSmart.The project manager manages the KFS technical development.

Financial System Module Teams: A Functional Team, a Technical Team, and a Business Analyst exist for each KFS module. The Functional Team, composed of user representatives from each partner institution, delineates the module’s functionality. A lead subject matter expert (SME) heads each Func-tional Team. The Technical Team is composed of the module’s software developers from partner institutions and is headed by a development manager.“Commercial Affiliates provide for-fee guidance, support, implementation, and integration services related to the Kuali software. Affiliates may offer pack-

KFS Functional Council Project Managerand Staff

General Ledger

Chart of Accounts

Reporting/Decision Support

Commercial Affiliates

Contracts & Grants

Kuali Technical Council

Phase 1 – October 2006 Phase 2A – October 2007

Purchasing/Accounts Payable

Labor Distribution

Accounts Receivable

Capital Assets

Budget

Workflow

Functional Teams

Financial Transactions

Nervous SystemEndowment

Phase 2B – July 2008

Refactoring/ Enhancements

Refactoring/ Enhancements

Purchasing/Accounts Payable

Endowment

KFS Extended Board

Development Teams

Budget

KFS Board

Source: Kuali Foundation, http://www.kuali.org./communities/kfs/KFSProject_lg.jpg

Figure 1. Kuali Financial System: Project Organization



aged KFS versions that provide value for installation or integration beyond the basic Kuali software. Affiliates may also offer other types of training, documen-tation, or hosting services.”3

The Kuali Project has evolved into a multifaceted organization that is developing a suite of enterprise applications for higher education institutions. As of August 2007, these applications include Kuali Financial System, Kuali Research Administration, and Kuali Student, as well as Kuali Rice, a software development framework. The Kuali Foundation, a nonprofit organization, employs staff to coordinate the efforts of partners and manage and protect the foun-dation’s intellectual property (see Figure 2).

Nine Collaborative Practices That Drive the Kuali Project

Throughout the Kuali Project’s develop-ment of its Kuali Financial System and its subsequent activities, the collaboration part-ners have implemented numerous structures and practices to facilitate the creation, opera-tion, and sustainability of a viable project. These nine collaborative practices are identi-fied as key elements in this collaboration. They can be found in most large collabora-tions, although their precise form varies. In describing these practices our intent is to high-light their functionality in the Kuali Project’s organization. The transferability to other collaborations or to internal operations falls to the judgment of individual institutions.

1. Driving the Collaboration Forward Through Leadership

Generating new ideas can be easy. A productive brainstorming session can generate a substantial list of feasible ideas, but a lack of interest, follow-through, or resources can make the transition from the whiteboard to a viable project a challenge. Once the collaboration passes that hurdle, commitment, passion, and

discipline are needed to keep interests alive and the project focused. Throughout the case study interviews, several participants cited the collaboration’s strong leadership as a major influence when contemplating their participa-tion in Kuali and a significant factor through its discipline and enthusiasm in nurturing the collaboration. As Richard Andrews, assistant vice chancellor and controller, UC Irvine, char-acterizes it, “The IU leadership is incredible. They’re competent, dedicated, and enthusi-astic.” Many of those interviewed for this case study praised the quality of leadership demon-strated in the collaborative. Since many of the leaders brought their institutions into Kuali, the presumption must be that these people are similarly viewed within their institutions.

The collaboration’s leadership must share a common vision and work together toward the realization of its goals. A lack of harmony may push the collaboration in too many directions, hindering its productivity and even endan-gering its viability. For example, as leader for Kuali’s most recent effort, Kuali Student, Ted Dodds, CIO and AVP at UBC, worked with several institutions before finding the four partners (along with UBC) who would share the commitment of money, in-kind contribu-tions, and support “to design and build for the vision which is a next-generation student system using service-oriented methodologies and technologies, through a community source process with support service architecture.” The key factor in establishing the effort has been the nexus of sharing the vision as well as committing the needed human and financial resources. The project came together as Dodds describes it: “After two days of meeting with all issues on the table...we found that we could all agree on ways forward. These meetings were a proof of concept that we had the right people.” The collaboration is based, in his view, not only on the resources of the partner institutions (although that is undoubtedly important) but also on the people, particularly on the leaders who could act together.

�


2. Identifying Compatible Partners with Thorough Vetting

Any partnership is only as strong as the capability, compatibility, and commitment of its participants. Thus it is important for a collaboration to begin properly by thor-oughly vetting its potential partners. Wendell Brase, vice chancellor of UC Irvine, notes, however, that a collaboration doesn’t have to offer perfection; UC Irvine has partici-pated in many collaborative efforts and, he concluded, “We compromise; we have to be flexible. Nothing is a perfect fit once you get into it, but the benefits of collabo-ration are ultimately substantial.” The Kuali Financial System Project approached this

task in several ways to ensure its founding partners were in synch.

For example, in the words of Bradley Wheeler, CIO at Indiana University and dean of information technology at Indiana University Bloomington, “There are no blind marriages: there is dating.” During interviews for this case study, people mentioned institu-tions that have been tracking the development of Kuali for many months by attending meet-ings and talking to current participants. Such interaction provides the opportunity for the “dating” Wheeler mentions. Lee Belarmino, associate vice president, San Joaquin Delta College, recalls his “date” at the Open Source Conference in December 2005: “rSmart’s founder, John Robinson, who I know from my

ProjectManagement

KFSKuali Financial System

Project Board

FunctionalCouncil

DevelopmentTeams

Subject MatterExperts

ProjectManagement

KRAKuali Research Administration

Project Board

FunctionalCouncil

DevelopmentTeams


ProjectManagement

KSKuali Student

Project Board

FunctionalCouncil

DevelopmentTeams


KualiTechnical Council

PartnerInstitutions

CommercialAffiliates

KRKuali Rice

Development Team

KNS KualiNervous System

KEW KualiEnterprise Workflow

KEN KualiEnterprise Notification

KSB KualiServices Bus

Kuali Foundation

LegalServices

CollaborationInfrastructure

Documentation

CopyrightHolding

Licensing

Bug Tracking

Board

UserSupport

ResourcePlanning

Figure 2. The Organization of Kuali

Source: Kuali Foundation as of August 2007, http://www.kuali.org/assets/foundation_org_large.jgp




partners were willing to extend the opportunity of collaboration to some very different partners. Collaboration doesn’t signal uniformity.NACUBO’s inclusion “enhanced the Kuali Financial System’s credibility with the founding partners’ financial users,” states David Lassner, CIO, University of Hawaii. “Otherwise, it would be perceived as a technically oriented project.”The diverse group of institutions brings different needs to the KFS Project and ensures that it remains focused on serving all types of colleges and universities. As a community college, San Joaquin Delta’s financial system requirements are more basic, as it lacks research or foundation needs. But it requires a function to address the State of California’s community college program tracking system, which impacts all community colleges’ state reimburse-ment levels. “It is essential that we have this functionality in the structure of the system,” states San Joaquin Delta’s Belarmino. “No other partner needed it.” San Joaquin Delta presented its need unambiguously to the KFS partners, who voted to expand the system’s scope accordingly. Belarmino observed that after the fact, other partners devised ways to use this function at their institutions. Further, Wheeler said that taking on the “heterogeneity [of Delta] is worth it because then you build the pool of potential adopters.”The nonacademic partners provide a reality check. “If we start thinking about going off in a certain direction, the rSmart Group can bring us back to reality by raising potential issues in the marketplace,” states UC Davis’s asso-ciate vice chancellor and controller, J. Mike Allred. “They balance things out for us.”

previous experiences in Silicon Valley, invited President Rodriquez and me to lunch with IU’s Barry Walsh. Barry talked about Kuali’s vision and we understood it. We talked about our IT development. It became clear that we were interviewing each other. About 20 to 30 minutes into the discussion, Barry asked for our opinion and President Rodriquez agreed to get involved in the project.”

Another early task was to identify institu-tions that had “synchronized institutional clocks,” explains Wheeler. “They realize a similar need within the relatively same time frame of action. If you can’t begin within the time frame of need for several institutions, you don’t have the first condition to pull a collab-orative effort together.” When forming the KFS collaboration, IU found several institutions that were evaluating the replacement of their enterprise financial information systems and were open to alternatives to the traditional means of building it internally or purchasing a vendor solution. “My institution thought it made sense to join Kuali to pool resources, to work on common problems, and to share economics,” states Aaron Godert, senior soft-ware architect/engineer, Cornell University. Such motivation is typical of the attitude of the founding Kuali partners: the acknowledgment of the problem and the willingness to seek an alternative to historic solutions.

Determining the collaboration’s optimum size and composition is important, too. The collaboration should be large enough to generate synergy but small enough to remain manageable. “Evaluating partners’ ‘use cases’ identifies new information, ideas, or characteristics that optimize the collaborative project’s goals,” continues Wheeler. For example, the Kuali Financial System Project’s diverse group of partners provides various attributes:

The research institutions—Indiana, Michigan State, Arizona, Hawaii, and Cornell—presented very compatible cultures and personnel. Still, these

10


Courtship comes next, as potential part-ners evaluate their cultural and philosophical alignment to determine, as Wheeler describes, their “collaborative capability. Can they make it through the difficult times? Can we do things together? These projects are completed more by covenant than contract. You can’t contract all [the details]. There is a tremendous amount of trust and risk sharing involved in these collaborative projects. [You have to determine] how much of your personal capital you are investing on a success that is based on the actions and behaviors of others.”

As Goldstein says in his report on collabo-ration, “very few report that they engage in a structured, formal process to understand the strengths, weaknesses, and readiness of their partners.”4 Certainly the Kuali collaborators seem to follow the practice of an unstructured evaluation process when contemplating their participation, although there are comments that potential partners spend many months “considering” their participation. Whether any of them engage in a “structured, formal process” is not known.

We do, however, record in this case study that Kuali partners share a purpose in developing and adopting the KFS, and they are willing to accept partners not entirely like most of the founders. Wheeler has indicated that some mixing of partner institutions opens the door to a broader variety of partners. This gives credence to Goldstein’s conclusion that partners value personal relationships, similar institutional missions, and common goals for the collaboration. These criteria do not exclude dissimilar institutions; hence, the inclusion of a community college in a group of research universities suggests a preponder-ance of shared interests as well as relationships among individuals. A process of due diligence for accepting participants exists, but the process is designed to measure “correct fit” rather than a rigid check-off list.

One means to determine “correct fit” is cultural compatibility, which some part-

ners perceive as a critical element in the collaboration; but it is not the only means to determine collaborative alignment. As David Gift, vice provost, Michigan State University, expresses it, “The cultural match between partners and within the collaborative culture is a key factor in the success of a collabora-tion.” But while some of those interviewed spoke of the serendipity of similar institu-tional cultures—for example, large research institutions—others found a match through their working relationships. On the one hand, San Joaquin Delta participates in Kuali despite being the only community college in the collaboration. On the other hand, two similar institutions worked together on a Kuali-related activity until the development group leader at one institution left, ending the partnership. Wheeler, addressing the issue of a Kuali culture, remarks, “We can’t have seven ways of doing things. You need a way to work together.” That way is the Kuali culture. Such divergent examples suggest that cultural compatibility is desirable but not required. The University of Arizona’s Kymber Horn, director of communication and outreach, aptly describes the spirit of the culture: “Kuali is family, and we take care of each other.”

3. Adapting Proven Practices and Products Fosters Collaborative Framework Development

After recruiting partners, the KFS Project began to build an appropriate framework to support its goals and activities. Rather than starting from scratch, the collaboration has cherry-picked proven concepts and products to incorporate into its collaboration. The adaptation process jump-started the collab-oration’s genesis by minimizing debates on fundamental collaborative elements. Partners found it easier to review concrete examples of operational collaborations and products, and through discussion adapt any relevant features into their collaborative framework.

EDUCAUSE Center for Applied reseArch 11


Creating a Patchwork of Proven Organizational Practices

Several entities guided the development of the KFS organizational practices. “Our general intelligence on how to build soft-ware collaboratively and communities comes from all over,” states the rSmart Group’s president, Chris Coppola. “We try to under-stand why certain practices work and adapt them accordingly. It is hard to isolate where particular practices come from, but there are some standouts from several organizations.” Of particular importance was to find practices and philosophies that fit the higher education community’s particular needs.

Several interviewees referred to the Apache Software Foundation, JA-SIG’s uPortal Project, the Open Knowledge Initiative (OKI), and the Sakai Project as inspiration for Kuali’s practices. For example, several KFS partners had participated in the Sakai Project, so it seemed natural for them to implement any lessons learned from their Sakai experiences. Indeed, IU’s Sakai development team reports to IU’s John F. "Barry" Walsh, associate vice president. The University of Hawaii’s Lassner, a Sakai and a Kuali partner, suggested using Sakai as the default for Kuali’s project structure, changing things only that need improving. “It was a simplifying statement, but we made substantial improvements along the way, too,” states Wheeler.

In Kuali, “the cross-seeding of individuals from several institutions on teams has become very important,” states IU’s Brian McGough, manager, research administration, systems integration team, and Kuali lead architect. “Large projects need to be broken down into smaller projects, so we cross-seed from the institutions both from the technical side and the functional side. In Sakai, [each institution] worked on different problems, and they didn’t all balance out in the end.”

The enhanced role of users in Kuali is critically important. “Sakai was first a techni-cally oriented community, springing up from

an IT perspective rather than an academic perspective. There is now a growing focus on the user experience driven by the users, but that came later,” explains Coppola. “When Kuali community began, the community understood this—maybe subconsciously or somewhat consciously—and subsequently architected the Kuali community to be driven first and foremost by the system’s functional users. Kuali’s organizational structures enable the functional leadership to direct every-thing; the technical leadership is responsive to the user leadership.” As UC Davis’s Allred observes, “They are the people who know whether or not the system will meet our needs. It is key to have functional users’ involvement so they understand 1) how the system will work, 2) how it will fit with their campus, and 3) any change management implications at their campus.”

The result is “an agile development with iterative processes where the functional people and the technical people are living in each other’s pockets,” states IU’s Walsh. “The users—the real stakeholders—are closer to the decision process and closer to the development process. We have developers intimately involved with the thought process of the functional people so that they actu-ally understand what they’re doing, not just coding some set of specs.” One example of the users’ power is that the Functional Council ultimately controls the KFS Project scope, voting to include suggested enhancements to the baseline IU financial system, which in turn assists with project planning. “Without a doubt the concept of a Functional Council has been ingenious,” states James Thomas, project manager, Indiana University. “Scope creep can kill a project. When an enhance-ment request arises that is beyond the original scope, the Functional Council prioritizes the request and addresses any necessary trade-offs. This makes my life as project manager much easier because I present the situation, ask them to prioritize it with the current list of

12


project functions, and they decide the course of action.” Functional users are highly involved in the Kuali Financial System’s quality assur-ance, too, reporting issues and bugs with the various development managers.

Finally, Sakai has impacted Kuali’s sustain-ability practices. “We learned from Sakai that the notion of a foundation with coordinating responsibilities enhances the community’s effectiveness,” states Coppola. “We learned, too, the importance of intellectual property management early in the Sakai foundation. Open source products are subject to a higher degree of scrutiny than a proprietary product because it is assumed the vendor has taken all steps to protect their intellectual property. So we go deeper and have built a very strong intellectual property practice within both the Sakai and Kuali communities.”

Building from a Baseline ProductKFS Project partners agree that re-

architecting the IU’s financial system was a lower-risk strategy than building one from scratch collaboratively. “If we had started with a blank sheet of paper, we’d still be writing on that piece of paper and not coding any software,” states UC Irvine’s Andrews. “It is a question of trade-offs,” states MSU’s Gift. “Open Knowledge Initiative tried to first establish standards and then to find a product that embodied the standards, but they seemed never to find a product. Sakai tried to form an organization to build a product primarily by combining two existing products, but with other added ‘modules,’ and ran into some delivery and maintenance problems with modules contributed as ‘add-ons.’ So Kuali took a different approach, starting with a preexisting product and having all of the development partners sticking as closely as possible to that until we deliver a fairly complete version and tested the replica of it. Of course, the rub in this latter approach is that the product must be accepted by all the principals.”

But using a baseline product accelerated the development process. When the KFS lead technical personnel hashed out collectively the project’s technical strategies, the IU baseline system enabled the group to skip the initial nuts and bolts of product “specing” and to focus instead on the broader issues of func-tional enhancements, Web-based and Java technical requirements, and other issues.

The IU financial system provided a working prototype for potential partners and Kuali Financial System’s first user, Strathmore University, to evaluate while mulling their participation in the Kuali Project. “The fact that we reviewed the IU system gave us greater confidence that Kuali is based on solid understanding of functional require-ments and specifically financial processes and controls of a major university,” states Strathmore University’s ICT director, Martin Wanjohi. San Joaquin Delta’s Belarmino recalls, “It allowed our skeptical functional people to kick the tires of the IU system. They had to be convinced that the IU system’s basic functionality enhanced with a new platform and refactored for us was going to work. But after they saw the IU system and picked the IU personnel’s brains, they became convinced that this system will work for us.”

4. Formalizing Concepts Promotes Mutual Understanding and Guidance

The KFS partners agree that “what’s on paper is not holding us together,” as UC Irvine’s assistant vice chancellor, Mark Askren, expresses it. “It’s the common interest and our agreement on higher principles.” Yet the collaboration has been diligent in documenting key agreements and principles. “That’s really important,” explains MSU’s Gift. “Details have to be written down. When people talk to one another, they hear what they want to hear. Only when they write it down do they discover what they agree upon.”

EDUCAUSE Center for Applied reseArch 1�


The documents offer guidance in problem resolution and project planning, especially as partners balance institutional and collaborative interests. “The perspectives are that you can think you’re advocating for the collaborative when you’re advocating for the institution,” states University of Hawaii’s Lassner. “The compromise might hurt the collaborative. Often you can’t tell whose interest is being put forward. So balancing institutional interest versus collaborative interest is and will continue to be a problem.” The Kuali Project’s documents provide a reference that can help clarify these conflicts.

One might find a significant divergence of opinion here, but the essence of Kuali is to accept the collaboration’s evolution. Indeed, as described later, some of the Kuali Project’s formal documents continue to evolve in tandem with the collaboration. For example, the emerging Kuali Student System documents are not those of the Kuali Financial System.

Memorandum of Intent (MOI)As with many collaborations, the partners

memorialized their participation in the KFS Project. Each founding partner does not have a direct agreement with each other; rather, their MOIs are written directly to a third party, the Mellon Foundation, and shared with the other partners. Signed by a provost, president, or very senior official, the MOI affirms the institution’s project support and specifies the institution’s resources, staff, and/or cash contributions to the collaboration. It confirms two basic collabo-ration agreements: First, the Kuali Financial System’s Project Board provides oversight of the project’s resources; second, the institu-tion will adopt or implement KFS afterwards on the outcome of the project’s activities. It gives each partner, as an investor, the right to become part of the project as well as to have representation on the Project Board, the Functional Council, and the Technical Council for the Kuali Financial System.

Statement of Philosophical PrinciplesOne of the first documents created by the

KFS partners was a Statement of Philosophical Principles that “helps unify and focus a means of making decisions and coordinating activi-ties,” states IU’s Wheeler. “Having a set of overarching principles empowers the various module teams in their decision making,” states IU’s Walsh. “It is a self-regulating process. If the recommendation is wrong, the collective wisdom of the organism will recognize it immediately and isolate that microbe.” The first principle designates IU’s financial system as the base system for KFS. The remaining principles address the criteria for expanding the project’s scope and system functionality, the criteria for addressing indi-vidual institutions’ disparate practices, the need for the system to accommodate essential and high-priority system enhancements easily and expeditiously, and a release date for the baseline financial system.

This document is especially important because it provides a hierarchy of criteria from which the partners resolve their differences. For example, it guides the collaboration on how to enhance the baseline IU financial system’s functionality during its transformation to the Kuali product. And as Kathleen McNeely, assis-tant vice president, Indiana University, notes, “It helps remind people on a daily basis what the collaboration’s target is.”

Scope DocumentWhen planning the KFS Project, partner

institutions viewed demonstrations of the IU financial system. In January 2005, the original Functional Council members and user representatives from the partner schools met to review an original scope document that outlined IU’s financial system’s current capabilities plus some IU-identified enhance-ments. The partner institutions gave their feedback and offered their enhancement suggestions. The collaboration finalized the scope document by March 2005. This docu-

1�


ment accompanied Kuali’s grant request to the Mellon Foundation.

The Kuali Scope Document (see http://www .kuali.org/communities/kfs/Kuali_Financials_Scope.pdf) specifically outlines vision, project timeline, and the status and priority for each module’s current and future enhancements of the baseline IU financial system. “The scope document provided a basis from which the partners could talk and build consensus as to what each institution wanted from the collabo-ration,” states IU’s McNeely.

The Reality TriangleThe reality triangle of resources, time, and

scope (Figure 3) is a conflict resolution tool introduced by IU’s Walsh to the Kuali Financial System Project. “This concept enhances the project’s discipline,” states San Joaquin Delta’s Belarmino. “There are no questions about the project’s deliverables and the required resources. When someone wants to change the system or a problem arises, the reality triangle enables us to see whether we have to add additional resources or extend the timeline accordingly.” The Functional Council considers the proposed change’s impact on the reality triangle.

The concept was further refined by creating a spreadsheet of KFS’s functional scope and the total number of technical people’s required hours divided by the total number of available resources. It is a visual assessment aid that “enables the people to make trade-offs of

functional priority,” explains IU’s Walsh. “It’s a good mechanism for allowing a diverse group to confront competing interests and to come to some resolution. It gives the project manager and his development managers a starting point to determine where to allocate the software development’s available resources during a given period.”

5. Defining Structure and Procedures Promotes Efficient Operations

In a project as complex as Kuali, “there has to be a way to adjudicate direction and priorities,” states UC Irvine’s Askren. “The Kuali Financial System’s organization structure does that by giving direction and setting priorities.” Given the number of institutions involved, it is important for Kuali to minimize the risk of tension between institutions and Kuali priorities. Achieving efficient operations is not the goal of raising revenues. For IU’s Wheeler and others the goal is to “drive down the cost of imple-menting, improving, and refining these systems over time. We want to drive down the risk of collaborating together.” These goals facilitate the effort of the Kuali part-ners’ IT leaders to convince others in their institutions, such as chief financial officers, to support the collaboration.

Consequently, the KFS organization is very hierarchical and structured. “All the people in this project—for whatever reason—understand the importance of structure,” states IU’s McNeely. “The orga-nization structure as well as [most of the] roles and responsibilities were identified up front. The project’s governance structure and organization work well to help reconcile the different partners’ management styles and cultures.”

The project created detailed decision-making procedures, usually designed to push decision making down to the lowest levels, escalating up through the organization as

RealityTriangle

Scope

Reso

urces Time

Figure 3. Reality

Triangle of

Resources, Time,

and Scope



needed. For example, if an institution’s subject matter expert (SME) in the KFS accounts receivable module identifies a missing enhancement, he or she initially discusses potentially incorporating this enhancement with the other SMEs assigned to the module and eventually with the Kuali Functional Council. “There is a structure and a process that rolls up, and eventually the Functional Council votes to either approve or reject the enhancement,” states UC Davis’s Allred. More importantly, any change is memorialized in the scope document. Since the scope document is the project’s official work plan, additional resources are not allocated to an approved enhancement until the change is recorded in the scope document and validated by the reality triangle.

As the project evolved, it became apparent that the partners needed a means to address unpopular enhancement decisions. For example, institutional SMEs and software developers can raise an issue with their institution’s board member and, if deemed appropriate, the entire Project Board discusses and rules on it. The project participants must then honor it. “Things can be escalated to the Financial System Board level for resolution, where we apply the project’s Statement of Philosophical Principles,” states MSU’s Gift.

The collaboration, too, has tried to equalize the founding partners’ power through its one-vote-per-institution procedure in its board and councils, where each institution has a seat. For a community college like San Joaquin Delta, this was particularly important. “When we started the project, we wondered how we were going to be treated,” explains Belarmino. “There is a whole pecking order of institutions, and we are so off the radar that we don’t understand it. Whatever the pecking order means, it has been set aside during this project. It seems that Kuali has set up a whole structure and hierarchy to ensure equality.” Just as important, the distributed decision-making structure tries to counterbalance IU’s

leadership role in the KFS Project. IU, almost of necessity, assumed most of the project leadership positions because it contributed the baseline financial information system. But despite this, the governance structure enables each partner to contribute to the project’s direction through its votes.

6. Developing and Reinforcing Project Culture

As work began on KFS, a separate project culture took root. The collaboration has taken numerous steps to reinforce it.

As a virtual organization, the Kuali Project members reinforce the culture through frequent communication. “The single culprit of any of the problems that we’ve experienced on the project is miscommunication or no communication,” states Cornell’s Godert. “The most successful teams are those that go the extra distance to ensure their work and decisions are transparent to the commu-nity. Overall, the partnership has recognized this, and its actions are evident in the ample opportunities for the teams to communicate remotely and face to face.” All teams, councils, and boards communicate frequently through weekly or biweekly phone or videoconference calls. As noted earlier, quarterly face-to-face meetings between groups are the norm to form bonds within the project. Interaction between the project’s functional and technical factions is fostered through attendance at each other’s meetings. Meetings are supple-mented by Web-based development tools and collaboration tools, as well as e-mail and instant messaging. Some participants, however, note a need to improve decision implementations through logging decisions, creating tasks associated with the decisions, and following up on the tasks’ execution.

Each council strives to reinforce the culture. For example, the Functional Council pushes the culture out through roles and responsibilities. A Functional Council repre-sentative sits on each module’s functional

1�


team to monitor the module’s activities and enhance communication up and down the project’s functional organization.

The sense of culture is even more impor-tant at the software developer level, where each person must separate the collaborative work culture from his or her institutional IT organization. This helps developers under-stand and adapt to the potential differences between the two entities. For example, a developer’s IT organization may operate differently than Kuali’s deadline-driven, iterative software development approach. Just as important is to establish a sense of trust among the module development team members. “All developers contribute code; people sometimes ‘step on’ [modify] other people’s code,” explains IU’s Thomas. “In this situation, the developers have to trust that their colleague is improving the code and not messing it up. This trust does not occur very easily between developers who work in the same building, let alone halfway across the country.”

One important factor in reinforcing the Kuali culture at the developer level is that the majority of the software developers work totally for the Kuali Financial System Project, reporting directly to a Kuali development manager, not to their individual institution’s IT organization. Another reinforcement factor is a face-to-face working session per quarter, allowing each financial system module’s software developers to work side by side and become acquainted personally. “The developers learn that there is a real person behind the e-mail address, the IM handle, and the blurry face on the videoconference screen,” states IU’s Thomas.

The Kuali Financial System Project has used a “boot camp” approach, initially hosted by IU IT staff, to initiate new developers into the collaboration. Andrew Hollamon, computing manager, The University of Arizona, describes it as “focused training for two weeks for style and tools to get new people up to speed.

After boot camp, they are subjected to pure immersion, which is not significantly different from typical university employment.” The newly assigned software developers work face to face on a team for a week or two, usually paired up with another developer to write code together, discuss questions, and review documentation. Another option is to assign a new developer to fix bugs, enabling him or her to review previously written code to gain a feel about KFS software develop-ment practices.

Reinforcing the Kuali culture is important, as the demands of the Kuali work can create tensions for developers who report to a Kuali manager while physically continuing to occupy space in their home institution. By its very nature the collaboration requires a dual loyalty for some participants. Some developers cannot reconcile the differences between the project and institution cultures and may be reassigned from the project. But comments during the interviews suggested that in most instances such tensions produced a highly desirable result: Individuals came to see that their work in the collaborative strongly supported the goals of the institution employing them. Rather than producing a schizophrenic work situation, the dual reporting resolved into the recognition that they were promoting their own institution. Some remarked that the developers who worked on the Kuali Project became all the more valuable to their institu-tion, since those developers would be most familiar with the ultimate software being produced. (Many of those interviewed also noted that the Kuali work was so challenging that it attracted better-qualified developers to work in their IT organizations.)

Still, as MSU’s Gift suggests, “There is a Kuali culture, but it is not terribly different from the culture back home.” This assertion may reflect the essence of compatibility among most of the institutions that have formed the Kuali Project. Similar, they are able to come together in a new, different,



yet recognizable culture. (Gift points out that MSU and IU have been shaped by past presidents, and IU’s Wheeler has recently coauthored a book with that IU president on the importance of collaboration.)

7. Moving the Project Collaboration Toward Sustainability

The very nature of collaboration raises the issue of sustainability: What can be done to sustain the collaborative beyond its initial stages? Must there be written agree-ments and commitments or binding legal contracts? Institutions have long worked with private providers; they typically have not experienced voluntary collaborations for business purposes.

Kuali must confront the issue of how to sustain the collaboration to achieve long-term viability. An institution entering an agreement to receive a significant software product has expectations and needs extending into the future. Indeed, Strathmore University signed on as the initial KFS user because it felt the Kuali Project did exhibit signs of long-term viability. “The fact that the project has stable membership, composition, and funding reduces the risk of development,” states Strathmore’s Wanjohi. “We have as a fundamental that Kuali is here to stay, at least in the foreseeable future. If there was a sense that the Kuali Project was a passing fancy of an unstable group, we would not have gone for it.”

Users need evidence of Kuali’s viability to maintain its relevancy as an enterprise system in the future. The Kuali Project plans to accomplish this through the development of an ecosystem or community of educational, commercial, and standards organizations that will use the Kuali enterprise systems and (for partners) contribute enhancements, modifi-cations, and best practices back to the Kuali community. But as MIT’s Stephen Dowdy, director, electronic research administration,

notes, “An open source initiative is only good if it has contributors. If people don’t write code or contribute, then the open source initiative dies quickly because there are no enhancements, bug fixes, or new features.”

In the light of such critical issues, the collaboration’s sustainability is of mutual concern to all participants. That concern emerges from interviews in numerous forms. Some divergence occurs between comments from individuals in the Kuali leadership and those who are less closely connected with the collaborative than with their own insti-tutions—an arguable distinction. While the former address the collaboration’s sustain-ability, some of the latter speak in terms of the product. For example, one who voiced his strong belief in the collaboration’s sustainability explained that the essence of continuance was that in 10 years there will be many institutions “running the same system [Kuali Financial System] with different feeder systems.” In short, he said, “I won’t be alone.” Another who is more concerned with product said, “We needed a model where we weren’t left behind in functionality, where we weren’t locked into a vendor’s changes.”

To achieve sustainability, the Kuali Project has undertaken several initiatives. First, the collaboration has expanded beyond its initial scope of the Kuali Financial System Project to develop other enterprise systems for higher education, including Kuali Research Administration and Kuali Student. “Within individual system projects, you have to be realistic as to what is a manageable number of partners,” states IU’s McNeely. “The overall Kuali Project could include partners that are involved in only one project [financial, research, or student system]. The number of participants in Kuali is only limited to the number of systems that Kuali can build.”

Second, it has launched three organizations or programs designed to foster sustainability:

The Kuali Foundation is a nonprofit organization responsible for sustaining

1�


and evolving the Kuali Project through the management of its portfolio of enterprise software applications. A small staff coordinates activities relating to source code control, release engineering, packaging, documenta-tion, project management, software testing and quality assurance, confer-ence planning, and educating and assisting members of the Kuali Part-ners Program.The Kuali Partners Program provides the means for collaboration to expand from the original partners to other entities to become a self-sustaining organization funded entirely by its membership. While the Kuali software is made available to anyone for any use or modification without fee, the membership organization will provide resources to its members, including quality assurance, release engineering, packaging, documentation, and other work to coordinate the timely enhance-ment and release of quality software. The Kuali Partners Program is an oppor-tunity for others to influence the direc-tion of the Kuali Project’s development through voting rights to determine the board of directors and software devel-opment priorities.The Kuali Commercial Affiliate desig-nation is provided to commercial affiliates who become part of the Kuali Partners Program to provide for-fee guidance, support, implementation, and integration services related to the Kuali software. Affiliates hold no ownership of Kuali intellectual prop-erty but provide value for installation or integration beyond the basic Kuali software. Affiliates may also offer other types of training, documenta-tion, or hosting services.

The University of Arizona’s Hollamon notes the increasing importance of these

services in the Kuali Project’s future: “These structures will become more important when the Kuali Project evolves from product development to a system where the commu-nity of users will contribute enhancements and modifications.”

To some, formal written agreements bind collaborative partners together; to others, the formal agreements are mere paper. The latter point out that vendor relations are often based on written agreements, but those contracts don’t always guarantee the expected results to the institutions. The former see written agreements as codifying documents that reify solid relationships. Kuali began as a collabora-tive with few written agreements, but recent developments indicate a direction of more formal agreements. David Gift argues that the “primary written agreement is in the Mellon MOI [which is soon to expire], so some other form of agreement [is needed].” While, as noted above, written agreements within the collaborative are common, those that legally bind the partners are still few.

8. Facing the Challenges of Participant Succession

The nature of the Kuali collaboration, at least in the eyes of some, means change within partic-ipating IT organizations. The aforementioned “cross-seeding” of people from several institu-tions working together can result in a different organization internally. IU’s Wheeler himself argues that in the life cycle of the collaboration from pre-project through the project phase to the post-project phase, “a large community project” emerges.

For Wheeler, succession planning is so important that he reflects, “Building sustain-able partnerships is the foremost item that I am working on now.” His notion is that such partnerships need to be “efficient, coordinating mechanisms,” and he takes his cue from a former IU president, Herman B. Wells, who said that the right level of university administration is no more than absolutely necessary, implying also



no less than is absolutely necessary. But such thinking is not always apparent in all partners’ comments. Understandably, some individuals see Kuali as an unusual nonprofit effort to provide a software product, one that in the long run they will maintain with or without the Kuali organization. For them, the product rather than the collaboration is the purpose. For others, such as Wheeler, the two are inseparable.

With the diverse assumptions of its partners, it is a matter of course that the operation of a collaboration has issues of succession, and the Kuali Project offers some characteristics that offset potential succession conflicts. As in other collaborations, the Kuali Project’s volunteer nature means that people within the partner institutions move in and out of the project as their personal and work priorities change, potentially jeopardizing the organization’s operations. To counter this, the project’s hierarchal organizational structure and defined roles facilitate people’s moving into new positions up or across the organization as required. “When you have a broad community, you’ve got depth and talent,” explains UC Davis’s Allred. “You have to identify the talent within the community and get it into position.” One example is Cornell’s Godert, whose involvement in Kuali has shifted in tandem with his professional circumstances, from his original appointment in the KFS architecture team now to the Kuali Rice program. All the while he has maintained his role on the Kuali Project Technical Council. “At any given time you have people in both the technical and functional areas who could step into key roles to facilitate the process,” states IU’s McNeely. This is particularly impor-tant as the Kuali Project continues to grow, and as software developers move on to non-Kuali assignments.

9. Replicating Lessons Learned Across Projects

As the Kuali Project begins to develop other enterprise applications, it faces new

challenges. It needs to create new struc-tures that facilitate collaboration across several large projects: research adminis-tration, endowment management, and student systems. One way to do this is to “evaluate the Kuali Financial System Project, incorporating the good practices while improving the less-than-perfect ones,” states Godert.

The Kuali Project seems flexible enough to modify best practices in accordance with the needs of upcoming projects. The Kuali Research Administration Project adheres more closely to the KFS development path. After deciding that the research, grants, and contracts information systems were to become a separate project, the Kuali part-ners decided to enhance a baseline product, ultimately negotiating to modify MIT’s Coeus research administration system. But as part of its agreement, MIT has designated its seats on the Kuali Research Administration Board, the Functional Council, and the Technical Council as Coeus Consortium seats, which are populated by representa-tives of the Coeus Consortium—who may or may not work for MIT.

Kuali Student is taking a different tack, mixing new and proven approaches in its system development. For example, it is taking the radical approach of building a student enterprise system from scratch. “The methodology and the practices that we need to follow to build a true service-oriented system are quite different from what any of our institutions have done before,” states UBC’s Dodds. The project will not enhance a single baseline student system but rather take a best-of-breed approach, enhancing exemplar modules of various institutions’ systems—for example, UBC’s pre-admission module. The Kuali Student team is testing the feasibility of this new concept by using its first product, a curriculum system, as a proof of concept for this method.

20


But while Kuali Student takes this different development tack, it continues to adapt proven Kuali practices. As with the Kuali Financial System Project, Kuali Student involved a representative functional user organization, the American Association of College Registrars and Admissions Officers (AACRAO), in the planning process. In turn, AACRAO voted to become a founding member of Kuali Student. The Kuali Student Board has documented the project thor-oughly in a project report submitted to the Mellon Foundation.

Lessons Learned“Collaboration is harder than doing some-

thing yourself, but the value of collaborating well far exceeds the difficulties,” states the rSmart Group’s Coppola. Indeed it does take a certain set of skills to work in harmony with your collaborative partners. Members of the Kuali community offer several lessons learned; some are general truisms, others are specific to collaborative practices.

Strong leadership is essential. Few, if any, elements are more important than leadership at all levels of a collaboration. The leader-ship must be rooted in the institutions while championing the collaboration. Heading the list of qualities necessary and even required is the need to be visionary, responsive, realistic, thorough, and imaginative. During our lengthy interviews, Kuali participants repeatedly ascribed these leadership qualities to Kuali leaders at all levels.

Develop collaborative skills to operate effectively in a cooperative environment. This advice may seem basic, but as Coppola observes, “We’ve lost people [in Kuali] because they could not adapt to living with decisions that were so far outside their span of control or influence.” For example, Godert suggests “maintaining an attitude of mutual respect and tolerance. You have to be open, to listen to other people’s perspectives, and to balance them with yours to create a general

solution that benefits higher education, not just any given institution.” In a similar vein, UC Davis’s Allred suggests, “Don’t think that you will get everything that you want from a collaboration, even most of everything you want. You have to keep an open mind and look for ways to reshape your needs to fit the system at a certain point of time.” Kymber Horn, The University of Arizona, notes that the Kuali collaborative also permits the develop-ment of a solution by a subgroup with similar needs for an enhancement; or, “Alternatively, we may find a function that falls outside the current scope but we alone can develop a module to meet that need and offer it to others within Kuali.”

Thoroughly vet your potential collab-orative partners to create a cohesive collaborative unit. In several case study conversations, partners discussed how their cultures and collaborative styles meshed well. Kuali leaders have implied that devel-opment and decision making constitute the essence of the Kuali culture. “There was no question that there were people who wanted to be part of Kuali, but they would not fit,” stated one partner. Probing for compatibilities up front facilitates harmony later. The stability of the Kuali collaboration testifies to the careful vetting of partners, both academic and commercial. However, the vetting also leads to a diversity of part-ners that strengthens the collaboration. The Kuali experience suggests that partners can agree on mutual needs but differ on what each contributes to meet those needs. San Joaquin Delta, for example, has needs potentially met by KFS but differs in its contributions to the collaboration.

Create structures and processes up front that equalize collaborative partners and participants. “The idea of democracy is a pretty alien concept for system analysis and design, and it is totally essential when working in a consortium,” states San Joaquin Delta’s Belarmino. From its incep-

EDUCAUSE Center for Applied reseArch 21


tion, the Kuali Financial System Project strove to identify organizational structure, roles, and responsibilities. Everyone under-stood how the collaboration functions. “You need to have the mechanisms in place to make decisions,” states IU’s Thomas. “Everyone has to agree up front on the deci-sion-making process. And once everyone agrees on the process, those resulting deci-sions are final. Not everyone will be happy with the outcome, but their opinion gets heard. Without these mechanisms in place, we would spin our wheels, analysis paralysis would set in, and nobody would be happy, and you won’t be able to make decisions.” To facilitate the creation of its structures and procedures, the Kuali Project continu-ally built from proven concepts, balancing democracy and hierarchy by relying upon equality of voice in arriving at decisions, and by using organizational structure to carry out those decisions.

But don’t be so structured as to hinder communication and collaboration. The Kuali Project’s collaborative practices continue to evolve through constant communication. The functional representatives and software developers meet frequently to hash out their differences. “People are so entrenched in their own institutional business practices,” states MIT’s Dowdy. “The best practices emerge when you put them in a room with their peers. Individuals then realize that their institution is the only one that does some-thing in a certain way as they gain exposure to others, and consensus emerges.”

There is never too much communication in a collaborative setting. The interviews with people at all levels in the Kuali Project reveal a penchant for communication. Board members, Functional Council members, the development teams—everyone—spoke of the unceasing need for communication. IU’s Thomas states bluntly, “If you are not able to communicate effectively...you have a problem.” Collaboration, after all, is an

exercise in interinstitutional sharing toward reaching desired ends. A failure to commu-nicate widely can defeat that purpose. The Kuali projects are characterized by extensive, persistent, and ceaseless efforts to communi-cate through various media as well as face to face. Not surprisingly, the personal relation-ships among people at different institutions led to Kuali’s formation and sustain its development. Horn voices the spirit of such collaboration as she describes the process of prioritizing: “As we learned to process the lists [of enhancements], each of us learned how to give things up. We learned there is a future, a time when something placed low on the lists works its way up.”

Documenting and referencing important principles and concepts facilitates plan-ning. A collaboration as complex as Kuali can easily get sidetracked from its original aims. “I see projects fail because they can’t manage to get a handle on the scope,” states Thomas. Consequently, the Kuali Financial System Project relies heavily on its Statement of Philosophical Principles and Scope Documents to guide its operations. “Our principles statement helps remind people on a daily basis what the target is,” states IU’s McNeely. Changes to the project’s scope are analyzed with the reality triangle and documented in the Project Scope Document.

Maintain balance throughout each project. “The organization layers represent layers of power,” states Cornell’s Godert. “If you don’t have balance at each layer, things tend to get problematic at the out-of-balance layers.” The democratic voting style at the Kuali board level facilitates equitable power sharing at the governance level, but the collaboration has been less successful at the operational level. Each partner contributes software developers to the project, but the project depends on the number and quality of the software developers that the partners can actually

22


provide. During KFS development, uneven institutional representation occurred on the various technical development teams due to some partners’ lack of resources. Dowdy notes a similar problem as work begins on the Kuali Research Administration System.

Collaboration provides new ways to enhance operations at home. Working in a multi-institutional collaboration introduces an IT organization to new technical and orga-nizational ideas. “Take a humble approach because there’s always someone out there doing a better job,” states The University of Arizona’s Hollamon. “Because of our work in Kuali we’re able to bring better practices back to our campus and improve our work here. Our involvement also builds a pool of talented people we can bring back to the university when the development period is over.”

Don’t underestimate the impact of a collaboration’s transformative properties on your IT organization. Kuali, according to IU’s Wheeler, is a transformative organization in its impact on institutional members. The Kuali work changes structures and ways of doing business within the collaborators’ institu-tions. Such power comes from discovering common problems and seeking common solutions without losing institutional identity. Participants repeatedly remark that they do things differently within their Kuali work or that their institution has found new ways to solve familiar problems. Cornell’s Godert reports that “a number of Kuali developers have begun to apply their new skills to develop software in a similar fashion for Cornell’s homegrown systems. For example, we use Apache products more frequently. The Kuali software developers like the project’s methods, which now shape their thinking or work on non-Kuali projects at Cornell.”

An IT collaboration’s impact can expand beyond IT. Kuali is at once a collaboration among IT units and a collaboration among institutions. As the scope of Kuali projects expands, Kuali’s impact on higher educa-

tion will increase. That vision informs the link between IT and other institutional functions. Looking at the role of IT within higher education, IU’s Wheeler suggests that “IT leaders have to understand how to deal their institutions into collaborations and communities. Your staff has to learn how to do this; you have to decide where it fits into your strategy, and where it detracts from your strategy. So you must begin to be purposeful about where to collaborate and how to leverage everything.”

These lessons from the Kuali Project reflect the conclusions reached in Chapter 7, “Succeeding at Collaboration,” of Goldstein’s report. For example, “flexible and adaptable management processes that all participants buy into”5 and “open and frequent communication”6 are hallmarks of Kuali projects. Kuali projects meet all of the 20 factors listed in the Wilder Foundation study.7 For example, participants’ voluntary collaboration to meet their needs for a stable financial system (KFS) is marked by a highly structured decision-making system. The emphasis on action to achieve results replaces structure to reflect organiza-tion. Goldstein’s finding of “a relationship between formal governance and more successful outcomes”8 is confirmed in the Kuali collaboration as a formal deci-sion-making process rather than a written governance document. This also confirms the finding that formal agreements do not seem invariably to lead to success.

ConclusionThe Kuali Project continues to function

and evolve. Work on the initial project, the Kuali Financial System, continues as its initial implementation goes live. New projects are under way, adapting KFS’s best practices in software development and governance. Underlying that growth is the core structure of collaboration. The interviews for this case study reveal strong support for collaboration



between the participating institutions, espe-cially as a means to solve old problems and transform old patterns of doing business.

So what are the keys to the Kuali Project’s effectiveness? “It is partly technical expertise, partly project architecture, partly the people, and partly the organizational structure,” explains UC Irvine’s Wendell Brase. “The infrastructure seems to be very effective, and the formal agreements hold everything together.” Through foresight and discipline, the Kuali Project partners have combined these collaborative practices and elements with admirable results.

Endnotes1. Philip J. Goldstein, IT Collaboration: Multi-Institutional

Partnerships to Develop, Manage, and Operate IT Resources (Boulder, CO: EDUCAUSE, 2007), 53. Also available at http://www.educause.edu/ecar/.

2. We are indebted to the following for information about the Kuali Project’s background and orga-nization: Martin E. Wainright et al., Managing Information Technology, 6th ed. (Upper Saddle River, NJ: Pearson Prentice Hall, forthcoming 2007).

3. Ibid.

4. Goldstein, IT Collaboration, 53.

5. Ibid., 68.

6. Ibid., 68.

7. Ibid., 68.

8. Ibid., 71.

The Kuali Group: Effective Practices and Structures Foster a

Documents

Transcript of The Kuali Group: Effective Practices and Structures Foster a