Evolution of SOLAR, Harvard's Client/Server-based Fundraising Management System Copyright 1995 CAUSE. From _CAUSE/EFFECT_ magazine, Volume 18, Number 1, Spring 1995. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, the CAUSE copyright and its date appear, and notice is given that copying is by permission of CAUSE, the association for managing and using information technology in higher education. To disseminate otherwise, or to republish, requires written permission. For further information, contact Julia Rudy at CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301 USA; 303-939-0308; e-mail: jrudy@CAUSE.colorado.edu EVOLUTION OF SOLAR, HARVARD'S CLIENT/SERVER-BASED FUNDRAISING MANAGEMENT SYSTEM by James E. Conway ABSTRACT: Harvard University's central computing and development office personnel joined forces to develop a prototype of a client/server fundraising system. SOLAR provides management and fundraising personnel the ability to access and share summary and prospect information. Its successful development can be attributed to the employment of some traditional project management principles and practices. The rapid development of personal computers, network capabilities, and the software that ties it all together has made it possible to apply technology to support major fundraising and other development efforts. Harvard University recently took advantage of these new technologies to support a $2 billion fundraising campaign. The campaign is unique for Harvard, not only because of the size of its goal, but also because it is the institution's first "University-wide" campaign. For most of its history Harvard has followed a decentralized organizational model: "Each tub on its own bottom" is the saying here. This model also applies to development. Each of the University's schools has its own development staff and computer system; each occasionally runs a campaign to raise funds, defining needs and goals, soliciting gifts, and ultimately retaining most of the funds raised. Harvard also has a central development office and computer system; this unit consists of the University Development Office (UDO), Faculty of Arts and Sciences Development (FAS), and the Recording Secretary's Office. UDO staff act as consultants to the individual schools in areas such as fundraising, research, and major-donor coordination. UDO also maintains biographical records of all University alumni/ae and donors. FAS's charge is to raise monies for the Faculty of Arts and Sciences, while the Recording Secretary's Office is responsible for processing and depositing all gifts to the University. Although decentralization has many strengths, it produces duplication of effort in the areas of gift processing, maintenance of prospect biographical information, and development computer systems. Each school can only work with information contained in its system, not knowing what a prospect's total University giving has been or what another school's fundraising plan may be. Also under the decentralized structure, each school makes its own decisions regarding its computer system--retain or build its own, choose a package to suit its individual needs, or use the central system. With the impending University-wide fundraising effort, the central development office realized that campaign success would demand changes to the central computer system. Installed in the 1980s, the existing legacy system employed excellent COBOL-based transaction processing. This system supported over $200 million in gifts and easily processed over 300,000 biographical changes a year, but it needed improvements in its support of fundraising efforts: critical reports, for example, could only be run centrally, creating delivery delays of up to one week. SYSTEM DEVELOPMENT STRATEGY Early in 1993, a Development Steering Committee consisting of central and FAS development management was formed to lead the system development project. This committee asked the central Development Computing Services department (DCS) to propose a system that could support central fundraising efforts and also easily be expanded to support a University-wide user base. DCS proposed a two-stage strategy. The first stage called for retaining the investment in the existing transaction system while moving forward with client/server technology to support the central office's ambitious fundraising efforts. The second stage called for the inclusion of those schools desiring to be part of the system. In the first stage, the transaction-processing legacy system would be extended to a client/server environment. This environment would make fundraising information readily available for integration into the fundraiser's overall scheme for information display and analysis. By following this strategy, Harvard could preserve its investment in its existing system and current desktop computers while giving administrators and development/alumni support personnel access to information through their microcomputers. Alumni, prospect, and gift information would be available directly from the server, in report or online, and could easily be extracted to desktop spreadsheets and word processing documents. The legacy system would continue to process gift and biographical information. As the transactions were applied to the old database, information would be transferred to the relational database located on the database server, providing secure, efficient access to current biographical and gift information. The day-to-day gift and biographical transaction process would be separated from the more ad hoc inquiry and reporting process. This separation of data- gathering and data-access functions would lead to a more efficient use of the legacy system. It would also improve reporting by enabling fundraisers to generate their own reports quickly and locally. As shown in Figure 1, the objective of the second stage of the strategy was the introduction of the new system to schools desiring system access. During this stage, the individual schools would maintain alumni and prospect core information on desktop computers connected to the central development office's legacy system. Other departments, such as the Harvard Alumni Association, the President's Office, and the Office of the Governing Boards, though not directly involved in fundraising efforts, would have access to the parts of the system related to their activities. (FIGURE 1 NOT AVAILABLE IN ASCII TEXT VERSION) ORGANIZATIONAL STRUCTURE The eventual successful development of the client/server system, called SOLAR (SOLicitation and Alumni Records), demonstrates an important point about the strategic use of information technology in support of the University's overall objectives. Harvard needed to develop an overall strategy that leveraged existing technology. Critical to the success of the new system was a committed, informed executive management that understood both the needs of the University and the value of information technology. Figure 2 illustrates the SOLAR development project organization. In addition to identifying critical high-level support, the organization identified several key team members, including a project sponsor, project manager, and user coordinator. The project sponsor needed to be a high- level manager with overall responsibility for both the new system and the primary function it would support: fundraising activities. The SOLAR project sponsor was therefore the UDO director. The project manager needed to be both technically competent and knowledgeable about fundraising, able to match the business problems with a variety of solutions--not all of them automated. This person was responsible for developing estimates and schedules, preparing funding recommendations, managing the project team, and communicating project status to the project sponsor and Steering Committee. The SOLAR project manager was a full-time, highly experienced consultant who reported to the director of DCS and the project sponsor. The user coordinator's responsibility was to ensure that staff from interested departments were available, as needed. Working at the manager level, this person reported to the director of FAS developmentand kept the project sponsor informed of any problems in allocating user resources. (FIGURE 2 NOT AVAILABLE IN ASCII TEXT VERSION) The project team itself was composed of the best available personnel, staff members who understood fundraising requirements and objectives and who had years of development experience and were responsible for raising funds from the University's major prospects. Finally, a Quality Review Committee was established to review the project at specified milestones and make appropriate corrections to the project's direction throughout system construction; this group consisted of senior staff and supervisors from affected departments. PROBLEMS ENCOUNTERED AND PROGRESS TO GOAL During the analysis of requirements in summer and fall of 1993, it became clear that some problems were at the managerial level rather than at the operational level. Although it was not difficult to define the day-to-day needs of the fundraising staff, it was difficult to grasp campaign organization and goals. The changing of the University culture was proving to be significant. Defining which University organizations would participate and what constituted a campaign gift was a lengthy process. Realizing this dilemma, the project sponsor charged the SOLAR team with developing a full prototype of the system, meeting all defined day-to-day fundraiser needs and including ideas on how to present management information once it became finalized. The expectation was that by the time the prototype for day-to-day operations had been completed and reviewed, management requirements would be known. During the next few months, the project team constructed a fully operational prototype of the online portion of the system. In-depth reviews of the prototype were provided for the entire 200-person user base active in stage one. Problems and requested changes raised in each review session were applied to the prototype prior to the next review, demonstrating to the users that the project team valued their input. Although time consuming, this approach raised overall morale, increased desire for the new system, and minimized the trauma commonly associated with change. By December 1993, the prototype had been completed and accepted, but work on finalizing campaign management issues continued. The project team now had an opportunity to improve the graphical user interface. Steering Committee members suggested that a professional graphic artist be temporarily added to the team to work on screen aesthetics. The artist established a number of GUI standards, including the shades of gray to be used in each screen, the use of off-white for data entry areas (suggesting the color of blank paper), button formats and operation, fonts for labels and buttons, separators and frames, text, scrollbars, and screen-to-screen flows. By March 1994, the campaign structure had been fairly well defined. The technical members of the project team could now proceed to develop all sections of the prototype with the exception of online management charts. Once development was completed, in the fall of 1994, the user members of the team tested the new system and proposed corrections. THE SYSTEM GOES LIVE During system testing, the project team was expanded to include a group of individuals charged with developing a system-introduction package. This team consisted of members of the University's Publishing Office, a professional writer, a graphic artist, and a professional trainer. They raised user community awareness of the system through a series of communications that discussed SOLAR, why it was developed, the benefits it would bring, and the planned implementation schedule. A multimedia SOLAR "kickoff" event was held the day before the system was introduced. During this event, each attendee was presented with a package of material containing a letter about SOLAR's significance from the vice president of alumni affairs, professionally printed copies of screens shown during the system's demonstration, and Post-ItTM notes printed with the SOLAR logo. DCS had trained some of the fundraisers to be trainers themselves. Each day, these fundraisers provided in-depth training for the twenty users scheduled to be added to the system the following day. This would continue until all 200 users had been added. The client software was loaded to each user's personal computer, and each new user received a SOLAR user guide. THE SOLAR APPLICATION The new client/server system, unlike many warehouse systems, is not designed for data access only. SOLAR contains two categories of information: core and fundraiser-specific. Core information is entered and maintained by the legacy transaction system: individual gifts, pledges, and matching gifts. Fundraiser information is entered and maintained directly by the SOLAR system. Fundraisers work with prospects in much the same way that marketing personnel in the business world work: rating the prospect's ability to give, researching the prospect's background and interest, developing cultivation activities and events, and completing solicitation of an actual gift. In addition to the prospect management function (prospect tracking, research summaries, prospect clearance, gift and gift history tracking, volunteer and committee activities and membership, and the future functions of planned giving and event management), SOLAR provides data extracts, ad hoc report writing, and the ability to merge selected prospects to word processing documents. Using the graphical interface, a fundraiser can obtain all relevant information on a prospect simply by entering pertinent search information, e.g., prospect's name. The resulting Main Prospect Screen (see Figure 3) displays the prospect's name, identification number, and giving rating; names of family members; and preferred address. The user may view other addresses--e.g., business, home, seasonal--by pressing the buttons B, H, and S. (To save the fundraiser's time, a button related to a specific address will only appear when the prospect has that particular address type.) Also available is information on prospect's school, degree, concentration, honors, years of attendance, and house of residence, as well as related solicitations. Buttons located on the bottom of the screen allow the fundraiser to access or enter more in-depth information on the prospect. A sample screen of research information (produced by pressing the research button) is shown in Figure 4. (FIGURE 3 NOT AVAILABLE IN ASCII TEXT VERSION) (FIGURE 4 NOT AVAILABLE IN ASCII TEXT VERSION) One of the most popular SOLAR features is the tracking function. Fundraisers can use this feature to enter and date specific comments or to request that the system send them reminders of a certain event at some specified future date. Fundraisers can select pre-programmed reports directly from their desktops, view reports on their screens, output reports in Microsoft Excel or Word formats, and print directly on a local laser printer. The system also provides a powerful report-writing facility for ad hoc reports with the same choices of output. With over forty local laser printers throughout the organization, report turnaround has been reduced to minutes, paper volume has been decreased, and users can select the specific information and sort sequence they wish to see. BEHIND THE SCENES A client/server environment is a complex one because each segment of the architecture needs to work well with all other segments and each affects overall performance. Architecture components were therefore chosen for compatibility and speed. The SOLAR server stores information on nearly 600,000 prospects and two million individual gifts. The server is a Sun 690MP utilizing Sybase System 10 relational database. The Sun 690 has four co-processors and is configured with 640 megabytes of memory and 20 gigabytes of disk capacity; it is connected to the clients over an Ethernet network. At the time of SOLAR hardware/software evaluation, all central development office fundraisers were using Apple Macintosh SE and SE/30 computers and were comfortable with the ease of use commonly found with Macintosh computers. Selection of desktop hardware was therefore rather straightforward; the only concern was that the Macintosh SE and SE/30 computers lacked processing and storage capacity. To provide the required computing capacity demanded in a client/server environment, all 200 SEs and SE/30s were replaced with Macintosh 610s, 650s and PowerPC 7100s configured with 20 to 40 megabytes of memory and 230 to 500 megabytes of disk. Selection of client software was also simplified by the fact that although there are a number of vendors' products available for the Macintosh or Windows environment, there are fewer available for both environments. The project team decided it would not evaluate products based on vaporware. The two major considerations used in the evaluation were ease of portability and software distribution. Distribution of the client application becomes significant when the client software needs to be distributed to hundreds of users spread over a large geographical area every time a modification occurs. Blyth's Omnis 7 product was selected because it operates in both Macintosh and Windows environments in a nearly seamless way and because it provides efficient software distribution. When a client logs onto the system, Omnis checks the application version number on the client against the version number of the centrally stored master application. When the version numbers differ, the system automatically updates the client only with the current changes, not with the entire application. CRITICAL MANAGEMENT FACTORS A number of factors were critical to the success of SOLAR. Obtain senior management support--Without the guidance and understanding of management during times of delay due to culture changes, the SOLAR project most certainly would have floundered. Management helped keep SOLAR moving forward, thereby underscoring the importance of information technology to campaign success. Consider total costs--The SOLAR team needed to consider costs for a wide range of areas: server hardware and software, database management system (in the case of Sybase, the cost of the database software on the server and on the clients), upgrade of the desktop computer hardware, Omnis client software (developer and client copies), network hardware and software, network and database management software (resource monitoring), and training and consulting. The construction of SOLAR could be equated to setting up a computer department from scratch--without the need to build an actual computer room. An area of future concern is the cost of maintaining and upgrading such a wide range of hardware and software: the hardware and software need to be compatible during the initial installation and they must remain so as individual vendors upgrade their products, throughout the system's life. Although application software development of systems such as SOLAR may be quick, time and care will need to be exercised during testing and installation of vendor upgrades. Follow a methodology--The development and introduction of a mission-critical system is difficult and should be approached carefully. The characteristics of systems development and installation of a client/server system are the same as those found in the development of mainframe systems. It was therefore decided that the existing project life cycle used by DCS in other projects would be followed. This life cycle contains four phases: proposal, requirements, development, and implementation. * Proposal phase. During this phase the idea of SOLAR was explored and evaluated. The current environment was reviewed, a statement of objectives was developed, possible alternatives were identified and evaluated, and preliminary costs and time estimates were prepared. The main purpose of this phase was to develop a proposal for management's review and approval. * Requirements phase. This phase provided the system's foundation. Initial emphasis was devoted entirely to an analysis of user operations, both present and future, with the intent of developing a detailed definition of the requirements the system had to meet. During this phase the prototype was constructed. * Development phase. This phase included a number of steps encompassing detailed design specifications, writing of application programs, preparing user and technical procedures, training, and testing the new system for compliance. * Implementation phase. During this phase, existing computer files were converted and new programs and procedures were initiated. After the new system was in stable operation, a post-implementation review was conducted to compare actual results to original concepts and plans. Achieve and maintain buy-in through listening and communicating--Management support and involvement are critical to the success of any information technology project, but buy-in from the people who are expected to use the system is just as critical. If users feel a system is being forced on them without their input, they will not use the system to its full potential or, in the worst case, they may not use the system at all. The SOLAR team included fundraisers as well as computer specialists. All screens and their content were developed by the fundraisers. Support the users--A system should support the institution's mission and goals, not just use the latest in technology. The design team must consider the production environment and the final operators of the system. The users will need training in how to use the system and help when something goes wrong. Following the model described by Kelly McDonald and Brad Stone in a Winter 1992 _CAUSE/EFFECT_ article, the SOLAR project established a network of customer support representatives (CSRs).[1] Located in and coming from the user area, CSRs are responsible for first-line training and support. When CSRs are unable to resolve a problem, they are backed up by phone support from a Customer Support Coordinator (CSC) located in DCS. If on-site support is necessary, the CSC is further backed up by DCS technicians who can be dispatched to the problem area. Another area of support that needs to be considered is user documentation. Due to SOLAR's ease of use and intuitive design, the project team was able to design a simple and compact user guide. The guide was designed to unfold and rest on a support base, standing upright next to the user's computer. The guide provides pictures of the most frequently used screens with simple how-to-use text located on each page, and with a wire binding and index tabs to ensure easy flipping of pages. Establish standards and procedures--Many of the methods used in developing a client/server system are the same as those used in developing mainframe systems. We all use accepted project methodology in developing systems, talk with and include our users, and at least attempt to include upper management in the process. The establishment of standards, preferably before development begins, is also important. Among the standards and procedures established by the SOLAR project team were new standards for the GUI and procedures for the movement of software and database changes from the development environment to the production environment. Provide technical training--SOLAR was the first client/server application designed and built by DCS staff and most of the technologies used were new. Training was therefore a requirement. Considerable time and funds were allocated to training in UNIX, Sybase, Omnis, and networking. In addition, the project team sought help from experienced consultants. CONCLUSIONS Although SOLAR has been in operation only a short time, it has been enthusiastically received and widely used. Overall benefits have been proven by the widespread demand for its implementation from other units of the University. The advantages achieved with SOLAR are many, but chief among them are the following: * Fundraising personnel have a quick and easy mechanism for accessing and reporting data. The client/server architecture can respond to queries more completely than a terminal-oriented system. * Fundraisers have access to current information, since queries are accessed in real time rather than against data residing in a file that has been previously downloaded. * Ease of system use has resulted in a sharp decrease in the amount of training required for new staff. * The amount of time required for computer staff to develop programs for various functions and reports has been significantly reduced. Fundraising personnel have information at their fingertips, when and where they need it, without waiting for central computer staff to write reports or extracts. Thanks to this direct access to critical information, fundraisers can now answer donor queries while still on the telephone, improving personal relationships between individual fundraisers and donors. In conclusion, SOLAR is expected to contribute to a success unequaled in the history of fundraising in higher education. Working with 600,000 prospects, Harvard plans to raise $2 billion over the five-year life of the University-wide campaign. These critical funds will help provide a first-rate education for Harvard's student body into the next century. ============================================================= FOOTNOTE: [1] Kelly McDonald and Brad Stone, "Distributed Computing with Centralized Support Works at Brigham Young," _CAUSE/EFFECT_, Winter 1992, pp.13-18. ************************************************************* James Conway is Director of Harvard University's Development Computing Services department, which provides computing services for the University's Alumni Affairs and Development offices. Prior to joining Harvard, he was responsible for fifteen computer sites world-wide as International MIS Manager at Nashua Corporation. ************************************************************* Evolution of SOLAR, Harvard's Client/Server-based Fundraising Management System 2n0.H2.HҀ0.H??.Word Work File D 686 TEXTMSTEXTMSWDǦB-@gpU?.0< 0TO``=|d`=|d^/.^HmHmzp?Hnr/Hn?<nbnc-ndJ.gU?.p/HnHnh0<RTOJ.bgT APPL Jeff Hansen22STR