Alumni

Alumni Development Information System RFP

Request for Proposal

Alumni Development Information System

Glassboro, NJ

April 19, 2001

Table of Contents

1Executive Summary

1.Overview of University Advancement12.Objectives of the Alumni Development Information System23.Scope of the Project24.Current System Statistics35.Expected Timetable36.Requirements46.1. Instructions for Completing Requirements46.2. Technical Requirements46.2.1. Hardware66.2.2. Database Management System (DBMS)66.2.3. System Administration and Security76.2.4. Application Performance86.2.5. Customization and Programming96.2.6. Vendor Support (Implementation and Ongoing)106.3. General/Overall System Requirements116.3.1. User Interface and Data Entry126.3.2. Names, Addresses, and Biographical Information146.3.3. Searching and Constituent Lookup176.3.4. Reporting, Labels, Mailings, and Holds186.3.5. Links with other Systems206.3.6. Documentation and Training216.4. Functional Module Requirements226.4.1. Events Management226.4.2. Alumni236.4.3. Organizations246.4.4. Campaigns256.4.5. Prospect Management266.4.6. Planned Giving296.4.7. Stewardship316.4.8. Pledge and Gift Processing327. Instructions to Vendors377.1. Outline for Submittal377.1.1. Company Information377.1.2. Product Information377.1.3. References377.1.4. Proposed Implementation377.1.5. Sample Agreements387.1.6. Costs387.1.7. Response to Requirements387.1.8. Appendix387.2. Technical Questions397.3. Procedural Questions and Proposal Submittal Address397.4. Deadline for Submittal398. Evaluating Approach and Criteria399. Proposal Conditions40

Executive Summary

Rowan University seeks a comprehensive information management system to support alumni and fund-raising activities. This document is the Request for Proposal (RFP) for that system and is being sent to selected vendors of non-profit fundraising systems and administrative systems which include a fund-raising component. Vendors are asked to review this RFP to determine if they believe their system can be used to meet the needs of Rowan University and respond according to the guidelines within the document.

1. Overview of University Advancement

The Division of University Advancement is the Universitys central planning and coordinating office for activities and relations with prospects, donors, alumni, and the community.

The Executive Vice President for University Advancement oversees the offices of Alumni Relations, Development, University Relations, University Publications and University Marketing. In addition to securing support from private sources, the Division also involves in developing proposals for government grants.

1.1. The Alumni Relations Office sponsors a number of programs for a network of 55,000 living alumni of Rowan University. These programs include reunions, homecomings, regional events, luncheons and receptions, professional sports events, educational programs, golf outings, and distinguish alumni awards. This office manages alumni directories as well as special projects such as alumni credit card and a membership club for young alumni who graduated during the past decade. Through the alumni web site at http://www.rowan.edu/alumni, this office communicates with alumni through web announcements, e-mails, and web submissions. This office can also send out mass e-mail to a targeted group of alumni, normally by a radius from the event venue, for event announcements. The Alumni Relations office is involved with a twenty-five-member Alumni Board. The director, an associate, and a secretary staff the Alumni Relations office which endeavors to maintain communication with alumni, correspond with regular mailings, and gather updated information.

1.2. Development functions consist of Major Gifts, Corporate and Foundation Relations, Annual Fund as well as Development Information and Research.

1.2.1. The Major Gifts area includes gifts which are made through wills and bequests, with trust instruments, annuity agreements, insurance policies, and forms of giving in addition to outright gifts. This office sends out a planned-giving publication called Hollybush Herald three times a year to alumni graduated before 1960 as well as retired faculty and administrators. The Director of Major Gifts and a secretary staff this area.

1.2.2. The Corporate and Foundation Relations area solicits support from corporations and foundations. A proposal writer prepares and works with faculty and administrators to develop the solicitation documents. The Director of Development oversees this area as well as the Annual Fund. A secretary supports this function.

1.2.3. The Annual Fund office solicits funds through mail and phonathon programs from alumni, friends, graduating students, parents of students, faculty and staff, and corporate matching gifts for current operations. Students staff the phonathon operations. The Coordinator of the Annual Fund operates the program.

1.2.4. The Development Information and Research area directs and administers services that assist and support alumni and development officers with information systems designed in FileMaker Pro (FMP), including phonathon tracking, alumni activity log, gift and pledge acknowledgements, pledge reminders, and prospect tracking. The Office also uses FMP to provide graphical user interface for alumni development data maintained in the mainframe SCT IA-Plus system to enhance multiple-field searching and keyword searching. By adopting AccuZip bulk mail software as well as Zip Select zip codes by radius software, the Office saves the Division a lot of resources through target mailing and bulk rate processing. This Office identifies and profiles individual donor prospects for cultivation and solicitation of gifts. The Information Resources Manager performs all these functions. Two program assistants enter pledges, payments, and gifts as well as produce daily acknowledgements and weekly reminders.

1.3. The Alumni Development System used by the Division is a module in the SCT IA-Plus integrated administrative system. The ADS module is supported by a programmer in the Management Information Systems Department under the Division of Information Resources. University Advancement staffs use FOCUS programming language to pull data from the SCT application and then incorporate the data in FMP for data manipulation and routine printouts. We use bar codes and hand held scanners to process pledge and gift forms.

1.4. All University Advancement staff are equipped with Macintosh Power PCs (G3, G4, iMac) and the machines are connected to the campus-wide network via ethernet protocol. We use Novell Groupwise for e-mail.

2. Objectives of the Alumni Development Information System

The Alumni Development Information System is intended to meet the following objectives:

Provide a contemporary centralized base of information that is easy to use by fundraising and alumni relations officers.

Aid the Development Office in the attainment of its fund-raising goals by providing timely and efficient monitoring and analysis of activities and programs, gift and payment acknowledgements, pledge reminders, solicitation tracking, and other analysis for campaigns, special projects fund raising, and annual fund with support for matching gifts.

Provide efficient standard reporting and ad hoc reporting capabilities at the user level.

Provide timely and easily obtainable information on screen as well as printouts on donors and prospective donors through online inquiry and selection.

Provide uptodate biographical information, especially addresses, affiliations, and relationships for donors and prospective donors.

Provide systematic prospect management (moves management) tools for planning, tracking, and reporting.

Provide a flexible system that supports the business rules of the University (without dictating those rules) and one that will change with the needs of the University and the users.

Provide a means for supporting the management of special events.

Provide a means for managing membership clubs.

Provide a means for linking and interfacing other information systems on campus.

3. Scope of the Project

The scope of this project is wholly on selecting the best possible system for University Advancement. With that in mind, we are NOT tied to a solution for the Macintosh platform only. Rowan University is amenable to purchasing a system that is exclusively fund raising in nature or part of an integrated administrative system. Rowan University has no preference for either a stand alone or integrated system provided that the fund-raising module(s) of an integrated system can act equally well as a stand alone product.

The Alumni Development Information System that Rowan University seeks must include but need not be limited to modules or functionality in these major areas:

alumni relations management

pledges and gifts management

annual fund and phonathon management

capital campaign management

prospect management

planned gifts management

events management

stewardship management

4. Current System Statistics

Pertinent statistics for the current Alumni/Development system follow:

DESCRIPTIONNumber of RecordsApprox. Number 1999-2000

Constituents65,0001,800 (new alumni)

Gifts & Payments70,0007,000

Pledges25,0004,200 (annual fund only)

Solicitations---35,000 (annual fund only)

Funds400--

Number of Users15-20--

5. Expected Timetable

Rowan University expects to have a new Alumni Development Information System selected in advance of June 30, 2001, with conversion, implementation, and training lasting through April 30, 2002, the target date to discontinue processing in the existing environment.

6. Requirements

6.1. Instructions for Completing Requirements

In prioritizing the requirements for the Alumni Development Information System, the following ranking was used:

RankMeaning

mustDescribes a critical requirement essential in the system because of its impact on the overall functionality needs of the university.

shouldDescribes a requirement which is expected in the system though not critical to the overall functionality.

desiredDescribes a requirement which would be helpful but is neither expected nor critical.

Vendors should review the following requirements and answer the narrative questions with short sentences, a paragraph, or a segment of the system documentation that is included within the vendor response to the questions. Unspecific references to vendor documentation shall be treated as a non-response. For the itemized entries, ranked must, should, or desired as above, please fill in the column Always, Sometimes, or Never with the ending to this sentence: Our system can provide this function Use the comment section for further explanation as desired. At the least, most "sometimes" answers should have qualifying comments. Samples follow:

#RankRequirementAlways, Sometimes or NeverVendor Comment

1shouldprovide expert user shortcuts or drilldown menus (e.g. go right to a favored report or screen with minimal key strokes).Savailable in next update due to be released in January, 2002.

2musthave easily accessible documentation which is searchable, indexed, printable, etc.A

For the convenience of vendors, this portion of the RFP is available in Microsoft Word 97 format via e-mail (request from [email protected]) or via http://users.rowan.edu/~au/rfp.doc. The vendors must use this document to record their answers, using an appendix if necessary for figures, comments, etc. Both a printed and electronic version (Microsoft Word 97 or Excel preferred) are required with vendor responses.

6.2. Technical Requirements

1. The system must be of an open architecture as design based upon industry standards. That is, no part of the system or database should be "locked out" and accessed only by the vendor. We expect to be able to add tables, fields, etc. and to connect to the database via industry standard methods (e.g. ODBC). The vendor must describe the implementation of their database in this area as well as describe the "openness" of their system regarding industry standard compliance, portability, scalability, and interoperability.

2. The system must be technically stable and have regular updates and enhancements to fix bugs, grant user requests, etc. The vendor must include a history of recent release dates for upgrades or enhancements. Please include the top 5 items from your user wish list. How does an item make it to the wish list? How are they addressed?

3. The system must run on a multi-tasking network-enabled operating system over our existing Ethernet backbone with Ethernet LANs running under TCP/IP. The vendor must describe the network and server operating system requirements of their system.


4mustprovide ROWAN the ability to add and store business rules as objects (e.g. via database elements, table driven, program library, middleware, etc.)

5mustallow for the running of background or detached processes (e.g. batch jobs).

6musthave a report writer or have inherent third-party tools for same; the report writer must include formatting for titles, headings, totals, subtotals, etc.

7mustmust have a unique system assigned ID as well as alternate IDs (SSN, and others).

8mustprovide the ability to use alternate IDs in an update of current records from imported data (e.g. use SSN as the key).

9mustallow connectivity to Excel & Word via downloads and uploads.

10musthave connectivity to database via the network which is seamless to users.

11mustbe a 32 bit application on the client side (i.e. native to newer clients).

12mustallow SQL database access, preferably non-proprietary.

13mustuse at least level 2.0 ODBC support (both client and server).

14shouldallow connectivity to office productivity tools (e.g. Excel & Word) directly (e.g. via ODBC).

15shoulduse table driven custom business rules.

16shouldbe a heterogeneous system providing us the ability to write reports/queries against multiple databases.

17shoulduse an intuitive, GUI environment for ad hoc queries and report writing.

18shoulduse integrated file and print services for NT if Unix-based.

19shoulduse 3-tier client/server architecture with ability to divide system processing for optimization.

20desireduse OLE capabilities (if on a Windows machine).

6.2.1. Hardware

1. The vendor must have well-documented and tested choices for server machines (memory, speed, etc.) including benchmark tests for upgrading, etc. The vendor must describe the recommended server hardware for their system. Please detail how upgrades in the system can be accomplished, including increased memory and additional disk storage, CPUs, connection, etc., as well as indicate maximum upgrade potential.

2. The vendor must list the requirements for the installation environment: temperature range, humidity range, power requirement, space requirement, external connections for work stations.

3. The vendor must describe the typical client machine.

4. The vendor must list the types of printers that are supported/suggested? Currently, the Division has HP networked printers, including a LaserJet 5SiMX with an envelope feeder.

5. The vendor must list other hardware that is required (e.g. tape drives, modems, etc.)?

6.2.2. Database Management System (DBMS)

1. The system must run on a current version of a fully relational, widely used and stable database, which will continue to be upgraded and supported. Rowan University must be able to administer the database without additional staff. The vendor must describe the database management system used by their system and how it meets these requirements.


2mustprovide standard, proven, and efficient system for backup and recovery, preferably implemented via vendor supplied application and/or vendor provided user customizable script.

3musthave minimal causes for record locking, and should have user-recoverable procedures for locks caused by other users.

4mustallow for the addition of tables, fields, and indices including the application of security features on those additions.

5mustuse permission groups, preferably operating system level groups (rather than application level groups).

6shouldprovide for easy backup & recovery at a transaction level.

7shouldhandle improper disconnects easily or via automation.

8shoulduse a data dictionary, linked to or part of database table definitions that automatically stay in sync.

9shoulduse flexible ROWAN-determined security at the database level, by table, by record, and/or by field which can be assigned by OS-level group or individual.

10shouldhave no disabled database management system features.

11shouldhave vendor-supported database upgrades.

12desiredbe a multi-platform database (runs on multiple OS/platforms).

13desiredallow database mirroring.

14desiredhave a single point vendor support.

6.2.3. System Administration and Security

1. The system must be of an open, yet secure architecture with multiple security features that may be incorporated per ROWAN's choice. The vendor must describe the available security features of their system. Describe the methods used to set security features, especially those outside the network or operating system level. Describe the level of upkeep and staffing required to incorporate both the most and least stringent security settings.

2. The vendor must describe the staffing and knowledge or training required for system administration.

3. The vendor must provide a description of the auditing capabilities of their system. Identify what audit data is stored (e.g. user ID, time, date). Is this auditing part of the database or the application? Can auditing be turned on/off and/or tailored by the system administrator? How does auditing affect performance?#RankRequirementAlways, Sometimes or NeverVendor Comment

4mustbe able to set security restrictions by group or individual, preferably using OS level groups.

5mustallow access to specific components of the database to be restricted on the levels of: no access, read-only access, and update access.

6mustuse follow through of security settings to applications, output media, batches, etc. including those written by the user.

7musthave queue management tools for night queue, prioritizing of users and reports, automating run-times, etc.

8mustnot allow overriding of database security by any program or process.

9shoulduse a single, network level password for password security.

10shouldhave simple data warehousing-type features and summary fields and tables available.

11shouldhave a means for backing out transactions and restarting failed batch processes without a complete system recovery.

12shouldhave tools available for maintaining metadata and/or warehousing extracts and loads.

13shoulduse consistent security from application to database to OS, preferably same and settable at OS level (i.e. database and application use OS level security).

14shouldsupply end-user and report usage statistics (i.e. who, what, how often).

6.2.4. Application Performance

1. The system must support up to fifteen simultaneous users with at least the response time in our current system, ie mainframe and FMP applications (see examples below). What benchmarks are applied to predict system performance? What factors have the hardest hit on system performance?#RankRequirementAlways, Sometimes or NeverVendor Comment

2mustcomplete a search for a constituent lookup in no more than 2 seconds.

3mustcomplete a search and produce a ready-to-print report with home and business addresses of, for example, 1,000 alumni (two classes) in about 3 minutes.

4mustbe able to run up to 3 reports (e.g. daily gift transaction report of about 100 records, biographical profiles of 1,000 annual fund prospects, and quarterly fundraising report of about 1,500 records) without affecting performance of other functions (e.g. drawing/loading user screens and data entry).

5mustbe able to run on the client with at least 2 other client applications without significant performance degradation.

6.2.5. Customization and Programming

1. We do not anticipate a need for pre-installed vendor customization of the system. However, should this situation arise, please describe how it would be carried out and how these changes will be supported into the future. Are customizations covered under an additional maintenance agreement? If so, how are upgrades handled?

2. The system must allow for the use of vendor-provided or third party programming tools with which to manipulate data, create screens, menus, batches, etc. as desired by Rowan University. These tools can include but are not limited to programming languages, 4GL, SQL, helper applications, etc. Please describe the programming tools provided with your system or available through a third party. Describe any additional enhancements to third party tools such as existing libraries for macros, applets, scripting, etc.


3mustbe able to build custom views (screens) of the data to be used as Rowan standards, speed data entry, and allow easy checking and entry from existing paper forms.

4mustbe able to create menus and sub-menus.

5mustbe able to add whole new modules (with their own sub-menus, reports, screens, tables, fields, etc.).

6mustbe able to design multiple step processes (scripting).

7musthave the ability to do inner and outer joins.

8musthave the ability to join multiple tables (at least 10).

9musthave the ability to do set operations (e.g. union, intersection, subtraction).

10mustallow for multidimensional arrays of any data type.

11mustallow the creation and use of stored, reusable code (e.g. objects, applets, macros, sub-functions) to be used later in a query or program.

12mustallow for the creation and management of code libraries.

13musthave reporting extension capabilities for building complex reports.

14shoulduse a debugger to help the user to set breakpoints, print out values, etc.

15shouldallow for both production and testing environments.

16shouldhave additional user help by being integrated with or have vendor-enhanced features for third party vendor tools.

6.2.6. Vendor Support (Implementation and Ongoing)

1. The vendor must give evidence of being responsive to emerging user needs and having those needs reflected in future versions of the application. The vendor must describe a project currently in development that meets this requirement. How have users been involved in the development of this enhancement? How will it be tested? How will it be released?

2. The vendor must specify the software warranty period.

3. The vendor must be capable of providing training, custom programming, upgrades, and other services at reasonable rates. Please describe how your company handles these types of requests from clientele. What are the basic rates? 4. It is expected that the vendor will have knowledge of and provide some level of support and troubleshooting for the hardware, operating system, database, security at all levels, backup and recovery procedures, systems management, and all devices used in the operations of the entire system. The vendor must describe their offerings in this area as covered by "subscription service" and those services that are optional or fee-based. At what point does a customer "question" turn into a billable item?5. The vendor must identify, sponsor, or support a users' group to foster shared ideas for using the application, database, etc. at both the user and technical level. It is expected that the vendor participate in the sharing of information with the users' group via the group's activities--involvement in list services, web site development, user meetings, etc. The vendor must provide pertinent information regarding the users' group(s) for your system.6. Software bugs reported by users must be acknowledged by the vendor and reported to other users. (Each customer must not be left to discover the bug independently.) Patches or upgrades to address these problems should be distributed as soon as possible. The vendor must provide a description of the companys procedure for dealing with user-reported bugs.

7. The vendor must provide a telephone response time for problems and questions. What are the hours for your help line?


9mustprovide timely (less than a day) help for emergency problems.

9mustprovide printed/printable end-user help which is both screen and process oriented.

10mustprovide printed/printable technical and user-level documentation.

11shouldallow technical questions to be answered directly by vendor's technical people.

12shouldprovide technical documentation separate from end-user documentation.

13shouldprovide searchable, indexed online technical and user-level documentation.

14desired

utilize a user panel to determine program weaknesses and to prioritize future enhancements.

15desiredprovide additional support options via e-mail or fax, searchable web site, periodic FAQ, etc.

16desiredprovide support for the entire database engine, even for unused features.

6.3. General/Overall System Requirements1. The system must be a contemporary Alumni Development information system, combining demographic, biographic, and financial data into a single relational, normalized database, linking together all the information therein. The vendor must describe the basic design of your system.2. The system must be cost-competitive with other systems having similar capabilities and features. Describe what you believe gives your system a distinctive advantage over similar priced system.3. There must be consistency in the design of the system, in the programming approach throughout the system, and in the user interface, including screen formats, documentation, and help facilities. The vendor must describe the consistent "look and feel" of your system.4. Currently, we can filter records with a temporary file of zip codes in FMP to identify alumni within a certain radius from the event venue. Also, we can use a file in FMP with SSNs provided by another system to filter records in our system. The vendor must provide a description of how the system works with temporary tables and filters.

5. Exceptionally good multiple address management is of utmost importance. The vendor must provide a description of how the system deals with multiple addresses for individuals. How are the unique situations for businesses and organizations handled (e.g. with multiple locations, branches, etc.)? Which features are automated and which must be manually set? 6. The system should have features built in that will help eliminate duplicate record entries. We would also expect a report or batch job to help flush out possible duplicates (e.g. using matching logic to identify duplicate address). What preventive measures are incorporated into your system to prevent duplicate records? How is the system checked for possible duplicates?7. The system should have web interfaces available. These interfaces should run on a web server (hardware and software) chosen, owned, and maintained by the University. The web-interfaces can include output files but must be more than mere output files (e.g. reports saved as HTML and copied to a web server). In other words, web interfaces must include data input, lookup, or other interactive access to the database (or a mirror or copy). Examples of such interfaces might include:

security-enabled constituent lookup for executives, on-the-road access, or volunteers who will not have access to our network or vendor client software

electronic change of address form for constituents (placed in a hold area or table for review before being committed to database)

The vendor must include a list of web interfaces available. Are the web interfaces add-on items with separate costs? Are additional client licenses required? What drives the interfaces (e.g. C, Perl, Java, etc.)? Are they enabled for Intranet (secure), Internet, or either? Are templates available?


8mustbe capable of managing 70,000 constituents to begin with, and expandable to three to five times that number over time.

9mustsupport unlimited addresses per constituent.

10mustsupport unlimited contacts for businesses and organizations.

11mustallow for multiple contacts in single company or organization and use contact relationships with links to company address(es).

12mustbe able to override all of the automatic functions to address the exception.

13mustallow alternative methods of entry of information (e.g. optical scanning, bar code reading, web forms, batch entry, etc.).

14mustsupply user-definable and user-maintainable tables of codes used throughout the system.

15mustprovide for mail merges directly to Microsoft Word or create tab or comma delimited ASCII files.

16shouldprovide interactive processing, allowing updates to be immediately reflected across the entire system.

17shoulduse a zip code table to fill in city, state with ability to turn off and/or override for multiple towns in same zip.

18desiredcreate a contact record automatically (on demand) from e-mail in or out.

6.3.1. User Interface and Data Entry

1. The user interface must be GUI (i.e. non-text based) and use interface standards accepted for computer platform (Windows/Mac) on which it runs to allow users to transfer knowledge from PC tools to the system. Please describe the features of your system which mirror the standards of desktop productivity tools (e.g. menu at top of screen, "file" choice being left most, tabs to move to additional screens/data, etc.).2. The user interface must be clear, intuitive, "friendly," and encourage user self-reliance. Consistency in commands and icons must be used throughout the product. Please include several screen snapshots of different parts of the system which illustrate "friendliness" and consistency. Include narrative with the snapshots if desired.#RankRequirementAlways, Sometimes or NeverVendor Comment

3mustprovide ways to navigate easily from one place to another (e.g. from prospect rating to giving records, to report templates, to financial accounting entry, to campaign pledges, etc.).

4mustinclude shortcuts (e.g. backwards, forwards) and keyboard equivalents for mouse movement.

5musthave the ability to put a running report/query in the background (multi-tasking).

6mustallow the user to preview queries and reports before printing.

7mustprovide coded, table-driven fields that facilitate customizing of applications, and speed data entry.

8musthave data integrity checks, table-driven when appropriate.

9mustuse a verification process to validate the entry of coded values.

10mustallow user to view and search all possible responses for coded fields.

11mustsupport wild card lookups and searches anywhere within fields

12mustbe accessible from off-campus/on-the-road.

13shoulduse smart search for "sounds like."

14shouldsupport Rowan University data entry standards via data checks at time of entry (e.g. auto correct "street" to "ST" or "Street").

15shouldbe a visual (drag and drop) and object-oriented environment.

16shouldprovide customizable macros for frequently run tasks.

17shouldprovide expert user shortcuts or drilldown (e.g. go right to a favored report or screen with minimal key strokes).

18shouldprovide ability to view table values for non-data entry end-users (i.e. view available codes and translations in pull-down menu even without write access to data or while in view-only mode).

19shouldallow seamless integration (direct connection) to desktop applications (Word, Excel, FileMaker Pro, etc.).

20shouldhave the flexibility to change or add additional code values on the fly (i.e. add to code/translation table while entering data) provided the user has the permission to do so.

21shouldprovide ability to set custom business rule triggers (i.e. data entry or modification triggers entry of something else).

22shouldassist the user with "smart" data entry (e.g. fill-in, series completion, etc.).

23desired

use customizable toolbar buttons, tab order of fields, color, font, and other visual configurations.

24desiredhave convenient integration to PC/Mac products such as mail clients and calendar programs.

25desiredallow user to set repeating value defaults at the start of a session (i.e. all elements being entered during a particular session will be coded same).

26desiredhave off-line compact versions with reconnect merge capability for on-the-road productivity.

27desiredallow "clickable" opening of external documents (e.g. word processing documents) stored within application.

6.3.2. Names, Addresses, and Biographical Information

1. The system must allow for joint as well as individual constituent options (e.g. allow one record to represent 2 people) so that one ID can be used to represent a couple where only one is the constituent (or both are one constituent together). Both single and joint names must be stored (e.g. John Smith is the constituent but "John and Mary Smith" are the couple) and joint or single salutations (Mr. or Mr. and Mrs.) used as chosen by the user, with ROWAN chosen defaults. Salutations should be viewable on screen and alert the user if missing data is being replaced by defaults. Non-spousal relationships must be allowed as well (friend, parent, etc.). The vendor must indicate any limitations their system has in this area.2. The system must allow for recording unlimited involvements such as student activities (social organizations, sports, band, etc.), start and stop dates, status (current/former), office (e.g. club president), and comments. In addition, an unlimited number of accomplishments such as awards, scholarships, graduation honors, fellowships, professional awards, etc. must be allowed with the same sort of additional information recorded. Thirdly, an unlimited number of interests such as hobbies, cultural, athletic, and civic interests, again with the same sort of additional information recorded. All must be differentiated between ROWAN and non-ROWAN items. The vendor must provide information on the capability of their system to perform this task.3. An unlimited number of external affiliations (DAR, Elks, etc.) must be allowed, with hard links to the organization where desired (may qualify as a matching donor) as well as start and stop dates, status (current/former), office (e.g. board member), and comments. The vendor must provide information on the capability of their system to perform this task. How are external affiliations treated similarly to employers? How are they treated differently?4. The system must accommodate home, business, seasonal, and reference addresses that are definable in terms of preferred mailing address and can hold up to 4 street address lines and allowing for foreign addresses. Telephone, fax, and e-mail addresses must be able to be stored with each along with which address is preferred, seasonal routing schedules, etc. The vendor must provide information on the address storage features of the system.


5mustallow for the storage of multiple names (unlimited number preferred) of virtually any type: nickname, maiden, birth, ROWAN name, current name, preferred name, former name, professional name, doing business as, formal, informal, special names, aliases (A.K.A).

6musthave separate fields for first name, last name, middle name, suffix, title and professional suffix mapped to a full name.

7musthave table driven suffix, title and professional suffix.

8mustallow hyphenated names.

9mustcapture gender, ethnicity, marital status (including ROWAN Couple), birth date and place.

10mustrecord death and date of death.

11mustallow general comments.

12mustrecord number, names, birth dates, gender, status (deceased, lost, active), SSN and comments for non-ID children of alumni.

13mustallow multiple class years (actual college, preferred, honorary, prep school, seminary), multiple majors, multiple degrees (bachelor or graduate degrees).

14musthave ability to mark and easily determine couple as "ROWAN Couple."

15mustallow gender-based relationships (e.g. father-daughter), handle all possible family relationships, handle friendships, roommates, etc. and allow histories.

16mustallow full spouse information storage (i.e. education, employment, etc.) tied to spouse link with ID.

17mustallow non-employment business affiliations with hard link to organization record.

18musthave hard-link between employee and employer but not required (ability to store employer name without an associated ID).

19musthave generic business information, matching gift policy, and ratio included automatically (e.g. translate or "flow through") on the gift entry screen.

20mustallow primary/secondary/former employer designation, status, dates of employment, flag self-employment, field of work and specialty, position description, title, position level (e.g. manager), with comments.

21mustallow employee links to local business address of employee and employer's headquarter address.

22mustallow storage of additional schools and degrees (unlimited in number), table driven with degree, degree year (year graduated), majors (up to 3), honors (up to 3), start and stop dates, non-grad flag, school-type indicator, and allow comments.

23mustallow both CAE and ROWAN-chosen affiliations (e.g. alumnus, parent, trustee), unlimited in number, with ROWAN-chosen primary affiliations.

24mustbe able to record source of address change and date for changed addresses (e.g. call-in, forwarded mail, etc.).

25musthave the ability to flag address as non-mailable or mail eligible (e.g. flag an address as correct, incorrect, temporarily away)

26musthave fields for e-mail (home and business), www page (home and business), phone and fax number (business and home) with extension, unlisted flag, and ability to include foreign phone and fax numbers (e.g. extra digits).

27musthave the ability to see all addresses for one constituent at the same time (via scroll through if necessary).

28musthave record usability status (lost, active, deceased, purge-able) and status date with status stored only once but follow through entire system and the staff who makes changes.

29shouldhave automated past-naming and addressing; system takes a new name or address just entered and makes it current and takes the old name or address and makes it past.

30shouldhave choice of free-form or coded comments which would indicate general type, author of comment and one line description.

31shouldhave automatic update or on-screen calculation of age based on birth date and current date.

32shouldhave ability to add non-spousal/child relationships without needing to create a new constituent record (e.g. deceased parents, grandparents, aunts, uncles, sisters, brothers etc.).

33shouldhave the ability to add multiple relationships between people and organizations.

34shouldhave the ability to easily change non-ID relationships to ID-based relationship if non-ID person becomes constituent (e.g. grown child, widow of constituent now becomes constituent).

35shouldallow for storage of research data for lost alumni to store degree of "lostness," status of research, etc.

36shouldlink employment information to individual's business address upon update of either employment or business address information.

37shouldhave security options to determine who can review comments based on type.

38shouldhave security options to keep address available to only select people.

39desiredhandle "private addresses" which are in the system for reference but not normally used in mailings except when specified (e.g. when a constituent asks for alumni magazine but doesn't want anyone knowing his address).

40desiredallow someone to appear to be anonymous in the system with storage of the actual name in a secure area open to only select people.

41desiredallow soft links to multiple IDs for ROWAN relationships (e.g. students to advisors).

42desiredallow general comments and comments based on names, addresses, salutations, etc.

43desiredallow SSN, nickname, class year, secondary school, other college for non-ID'd other relationships (i.e. store same data as for ID'd relationships).

44desiredbe able to store name of administrative assistant/secretary for executives.

45desired"build" an address from company records and constituent records (for several constituents within same company and location but different mail stops).

46desiredvalidate address according to USPS standard

47desiredlook at stop and start dates on home addresses automatically with ability to add a future home address.

6.3.3. Searching and Constituent Lookup

1. The system must provide name search features allowing us to find entities under a variety of names, such as birth, former, married, and corporate names, first, middle, and last names, nicknames, etc. Virtually any field must be available for searching as part of the standard online lookup capabilities. The vendor must provide information on the searching features for a standard lookup screen. Are "smart searches" available to non-power users that can be used to search multiple fields? Are "smart-searches" available for handling variations in the data (e.g. IBM vs. I.B.M. vs. International Business Machines)? How do these work?2. The system must be able to provide users with multiple field searches which include combinations of tables and fields and using boolean and comparison operators (and, or, not, greater than, etc.). These searches must be able to be saved globally as well as by an end-user for future use. The vendor must provide a description of or a snapshot of a complex search screen or example.

#RankRequirementAlways, sometimes, or neverVendor Comment

3mustmake search results immediately available on-screen.

4mustallow user to choose one record from a search from which to proceed to other parts of the online system (e.g. gift history).

5musthave the ability to subtract, intersect, or join populations of selected records.

6mustprovide critical information in the match list including, for example, but not limited to: name, address, address type, alumni/ae class year, primary constituency, lost/active status.

7mustbe able to search and/or select records on virtually any data element contained in the records.

8shouldallow user to switch between case-sensitive/case-insensitive queries.

9shouldmake the match list from a search available for input to a report.

10desiredsupport searchable full text and keywords (e.g. for trip reports).

6.3.4. Reporting, Labels, Mailings, and Holds

1. One of the primary needs for the new system is to go beyond traditional transaction processing. Thus, reporting tools will play a critical role for each and every user of the system and will be widely used for decision support. The system must use flexible user-oriented reporting tools (rather than programmer-oriented tools). These may include vendor-written or third party tools. Vendor templates, macros, or examples must support the use of third party tools. Reporting tools should be menu-driven, use context-sensitive help, and/or wizards to assist users in a step by step manner. Users should be able to write many of their own ad hoc reports (after a day or so of training). Please describe the reporting tools used by your system and how they meet these goals.2. Reports should be definable in terms of format, location of data elements, sort order, totals and subtotals, and selection and exclusion of data. Reports should be available on paper, on screen, and in files. There should be a library for standard reports that can either be used as is or serve as templates for the development of new reports. The vendor must provide a description of how the system's reporting meets these goals.3. The system should come with a variety of pre-defined biographic, giving, and financial reports, all of which are user modifiable. These should include but not be limited to daily phonathon report, year-end performance, balance reports, campaign reports, audit reports, accounting reports, and CAE reports, available on-demand or system-scheduled to run automatically at set intervals. The vendor must describe the "canned" reports included with the system. Include a list if desired.4. Output format for reports must allow for virtually any type of user-defined form, eg pledge form, reminders, payment receipts, mail merge, standard and custom-sized labels, envelopes, badges, and cards. Other desirable features include font settings, text color, italics, etc. Do your reporting tools support these types of formats and features? Are direct connections (e.g. ODBC) to PC productivity products available to achieve these types of output?5. The system must provide the ability to choose virtually any population or combination of populations for label and envelope. The user must have the choice of fields to print (e.g. class year, ID#, etc.) and be able to view labels on-screen before printing. The vendor must provide a list of system-provided label and envelope formats and outline the procedure a user would go through to produce non-standard labels or envelopes. If a third party tool is used, please indicate preferred tools and what vendor-supplied templates are available.6. The system must be able to create an unlimited variety of readily accessible presentation-ready reports (e.g. individual prospect reports for various audiences, fund raising progress reports, prospect tracking reports). This will require that the system store useful summary information about a prospect or campaign and that it provide the tools to retrieve this information easily and in a visually appealing way. Are special reports for summary information included with the system? The vendor must provide a sample.#RankRequirement

Always, Sometimes or NeverVendor Comment

7musthave ability to produce address labels or envelopes fully adhering to postal regulations (including bar codes) for best pricing options.

8musthave the ability to join mailings for couples (one mailing per address).

9mustallow single line and split lines for joint labels.

10mustprovide ways of dealing with exceptions (e.g. names too long for label).

11mustallow the use of bar codes for ID Numbers

12mustallow use of all types of industry-standard labels for mailings (i.e. some post cards require smaller labels).

13mustallow an unlimited number of holds (no solicitation, no mail, no contact with ROWAN, no mail solicitation, no phone solicitation, no e-mail contact) with dates, status, source of information, and comments.

14mustallow hold histories with dates and Staff Name.

15shouldhave flags and dates for tracers sent and returned mail (bulk vs. first class return vs. magazine); source of information (e.g. self reported, post office, etc.).

16shouldkeep records of mailings and who received what (e.g. via mailing history records).

17shouldhave ability to queue reports for execution immediately or at a later time (i.e. night queue).

18shouldinclude a cover or trailer sheet with selection details and other user-chosen properties which determine the outcome.

19shouldconstruct foreign addresses in acceptable, mailable format, not simply "retro fitted" into USA address format.

20desiredprovide report usage statistics to identify what reports are used by who, when, etc.

21desiredhave the ability to access additional databases in report creation.

22desireduse "smart" sorting of names to deal with deMarco, Smith-Jones, etc.

23desiredprovide for user-designated sorting options such as a user-chosen sort name to allow for exceptions such as foundations known better by last word name, corporations by first word in name, government agencies by second word in title, etc.

6.3.5. Links with other Systems

1. Procedures for data sharing and links with other offices/systems would need to be established. The anticipated scenarios are listed below. At the current time, some electronic "transfers" are possible through the integration of and among the SCT modules (e.g. Student Information System and Financial Records System). The vendor must provide information on how their system might be used to handle the following needs for sharing and linking data. Indicate the level of complexity to automate each (easy, moderate, or difficult) as pertaining to your system and which can be accomplished directly through open systems (e.g. ODBC).

DirectionOfficeSystemWhatComplexityDirect

(Y/N)Comment

fromregistrarSCTnew alumni (including vitals, degree, honors, student activities, and contact information)

fromhuman res.SCTemployees

tobusiness off.SCTdaily gifts and payments

tobusiness off.SCTyearly pledge summary (FASB)

2. The system must allow easy integration with other applications, e.g. no more than two steps to import into a desktop application with direct connection being preferable over import. Current standard applications are Microsoft Office Professional Suite (Word, Excel, and PowerPoint) and FileMaker Pro database software. The vendor must describe how the system integrates with desktop tools.3. The system must provide for auto/mass load of new records (including ID records), matching on IDs where necessary (non ID records) to obtain data from external sources. Users must be able to perform the load, preview it online, and set additional rules before committing it to the database. It is preferable that a wizard or other user aid be available for this purpose. Some "uploads" may be updating existing records (e.g. obtaining new addresses from a credit bureau), adding new records (e.g. adding involvement records for attendees), or both (e.g. obtaining an updated employee feed). Please describe a typical scenario for mass updating existing and new records and the steps the user takes to accomplish this.#RankRequirementAlways, Sometimes or NeverVendor Comment

4shouldhave automated import information from directory publishers (e.g. Harris) or other sources such as DIALOG, Lexis/Nexis, Econometrics.

5desiredautomated updates to corporate information, matching gift information, prospect screening and research information, from services like HEP, Marts & Lundy, CDA/Investnet.

6desiredaccept information from other software electronically (e.g. trip reports from a word processor).

7desiredhave ability to link to digital phone system for automatic dialing of phone number chosen on screen.

6.3.6. Documentation and Training

1. A user who has been thoroughly trained must be able to perform simple queries, run a simple report, and be able to attempt more complex operations. What can users expect to learn during basic training? Do the training materials support the documentation and vice versa? The vendor must describe how the documentation for your system enables users to continue to learn on their own after training, particularly for reporting and output of data. 2. The vendor must describe the training options and environment(s). Is it a hands-on session in a lab environment? If so, who are the instructors and how are they trained? Do you use third-party trainers? Are there any self-paced training programs (e.g. computer-based training, videos, etc.)? What levels of training are offered (e.g. general user, system administrator, executive, power users, technical, etc.)? The vendor must include a schedule with one year's worth of offerings (current or past year).#RankRequirementAlways, Sometimes or NeverVendor Comment

3musthave easily accessible documentation which is searchable, indexed, printable, etc.

4musthave independent learning and review resources available (in addition to or in lieu of classroom training) particularly to jumpstart new learners or re-learning.

5mustbe targeted at specific levels of expertise.

6musthave data element dictionary available for reference online.

7shouldprovide detailed, online help which is linked to related help text topics and an online index.

8shouldallow for a train-the-trainer approach so that the University can develop its own trainers.

9shouldhave integrated training for third-party applications or tools with emphasis on specific use of vendors system.

10desiredallow for the addition of Rowan custom help, either by the end-user or by technical staff.

6.4. Functional Module Requirements

6.4.1. Events Management

1. The system must maintain a variety of events of many types (e.g. receptions, building openings, graduations, reunions, breakfasts, lunches, dinners, media events, public events, etc.) for many purposes (e.g. stewardship, cultivation, recognition, tradition, public awareness, communication, etc.). Events may last hours or days and may include many mini-events within the whole. The vendor must provide an overview of the events management function of the system.


2mustgenerate invitation lists, invitations, reply cards, envelopes, name tags, name cards, etc.

3mustbe able to track attendance (numbers) and/or names of guests (may or may not have an ID record on the system).

4musttrack budget information and revenues such as: item, type, budgeted amount, amount expended, status (paid, unpaid, committed, available).

5mustmaintain facility management information, such as: reserve room, catering, staging, tables, chairs, decorations, parking, etc.

6mustgenerate followup correspondence.

7musttrack event evaluation information.

8mustbe able to record attended/invited/declined, dates, comments.

9musthave the ability to link event attendance with giving details for reporting.

10shouldhave batch entry mode (ability to enter event attendance efficiently for information that repeats from record to record).

11desiredmaintain seating assignments, dietary requirements (vegetarian, allergies, etc), and special instructions (handicapped, wheelchair, etc.).

12desiredcan associate people attending special events with the event, but not actually be part of the main database.

13desiredmaintain event plan (task list), such as: activity, date, person responsible, status (i.e., completed, to be done, canceled, etc.).

14desiredhave comments for everything.

15desiredhandle pre-registration (e.g. through web interface) and actual registration (e.g. on site at the event).

16desiredmaintain records for contact information for external vendors and internal offices (phone, mail, dining service, rental company, etc.)

17desiredhave an events and planning calendar.

18desireduse a preexisting event as a template for a new one ("clone" an event setup).

19desiredmaintain historical records for comparisons between similar or repeating events.

6.4.2. Alumni

1. The alumni module must be capable of maintaining multiple ROWAN degrees for individuals.


2mustbe capable of maintaining all of the degreerelated information for each individual, including the school from which the degree was obtained, type of degree, area of study, honors, and date the degree was conferred.

3mustprovide for the recording and maintenance of memberships and payment information for sustaining alumni association memberships (e.g. GOLD Club).

4mustable to manually change the reunion year which is different from the year when the Rowan degree is conferred.

5desiredallow multiple class agents per class with one identifiable head agent.

6desiredautomatically assign alumni regional chapter clubs by system based on table-driven zip code regions but allow override and secondary manually assigned clubs.

7desiredshow alumni distribution in the state of New Jersey and in the US

8desiredallow unlimited committee assignment (e.g. trustees, admissions recruiter, phonothon volunteer, alumni club officer, alumni council, reunion committee, class agent, etc.), term dates, office (e.g. president, associate agent, etc.).

6.4.3. Organizations

1. Users must be able to easily distinguish multiple records which appear to belong to the same organization but instead identify the corporate headquarters, subsidiary or branch offices, matching gift foundation, etc. particularly in search results. The vendor must provide information on how the system can accomplish this task.


2mustbe able to easily distinguish organizations, corporations, and foundations, from individuals.

3mustlink matching gift information: ratio, show where matches are processed, distribution dates, min/max matched.

4mustshow subsidiary relationships (parent corporation, etc.), link unlimited number of contacts to organization (who gets mail for that organization, officers, directors).

5mustshow gift summary of an organization including its subsidiaries on screen or on printout.

6shouldstore holdings, nature of business (text), comments, number of employees.

7desiredallow organizations to have all the same linked information as individuals (e.g. invitations, holds, etc.).

8desiredmaintain organization contacts (relationships to people) for alumni/ae matching gift company coordinators, who to mail to, foundation contacts, etc.

6.4.4. Campaigns


1mustsupport alumni regional campaign management.

2mustdetermine regions by zip code ranges (noncontiguous and contiguous).

3mustbe able to assign staff and volunteers to regions.

4mustbe able to create regional goals and results scenarios.

5mustaccommodate gift clubs with years; allow multiple gift clubs for a given year; lifetime, annual and capital gift clubs, type of gift club.

6mustbe able to choose constituents by region based on their home and/or work address (mailable or not) and their relationship to the college (alumnus/a, parent, etc.) and their prospect level (major gift, special gift, annual gift).

7mustmatch regional goals against results.

8mustmaintain history of proposals, solicitations, etc. for each campaign or proposal.

9musttrack solicitation techniques (e.g. phone, mail, personal visit).

10musttrack and maintain prospect base and designate constituent status (i.e. corporation, foundation, alumni, parent, friend, etc.)

11mustmaintain fund status and fund transfer status (i.e. hold, pending, transferred, etc).

12mustmonitor and track annual vs. campaign vs. planned giving for all constituents.

13musttrack cash flow status by project.

14shouldprovide automated pledge analysis (pledge fulfillment rates).

15desiredmaintain fields for tracking cultivation and effectiveness, such as fund-raising results (# of donors, % of goal), participation rate, statistics (average gift, e.g.), evaluation of scheduling, attendance and/or satisfaction, trend analysis, dollars raised by constituent, effectiveness of staff, effectiveness of volunteers.

16desiredmaintain programs recorded with their associated activities, including: goals, methodology, results, evaluation, recommendations.

6.4.5. Prospect Management

1. The system must provide prospect tracking management (moves management) capability with detailed support for the identification, planning, segmentation, and tracking of cultivation and solicitation efforts. A donor may have any number of solicitations with each having any number of actions associated with it to store relevant information regarding planned contacts, actual contacts, proposal submissions and dates, etc. The vendor must provide a move management scenario as can be achieved with the system.


2mustdirectly link a gift or pledge received to the correct solicitation.

3mustallow the coding of activities that should take place or have taken place with an entity for prospect tracking (e.g. setting up reminders to send invitations for a special event, "call reports," etc.).

4mustbe able to assign up to 4 solicitors to a prospect; one primary staff solicitor, 1 other staff solicitors, trustee solicitor (sometimes), volunteer solicitor (sometimes).

6musthave the ability to distinguish between major and annual giving solicitor and volunteer assignments with room for both.

7musthave the ability to have a history of solicitor/prospect assignments with begin and end dates.

8mustallow multiple active solicitations in various phases of completion, distinguishing between annual and capital solicitations.

9mustmaintain solicitation/proposal: ask amount, status (e.g. solicit in current fiscal year), campaign and department assignments, segmentation (e.g. major gift, special gift, annual gift, etc.), solicitation method (letter, phonathon, etc.), purpose (linked to purpose table for gifts and pledges), and comment.

10mustbe able to identify LYBUNTS, SYBUNTS, New Donors and Non Donors.

11muststore phonathon status (i.e. pledge, maybe, refusal, no contact, or mail) with date, student caller or volunteer, campaign, appeal, ask amount, and pledge amount.

12mustprovide spouse linkage for joint and single asks.

13mustseparate historical (complete/deleted) solicitations from current/active solicitations.

14mustprovide profile information displaying a brief summary for each entity (person or organization) that is ROWAN customizable.

15musthandle electronic screenings (e.g. Marts and Lundy, CDA/Investnet), ROWAN screening programs (off-campus), suspect review screening(oncampus).

16muststore type and source, screener, rating, initial ask amount, prospect status (rejected, inprogress, accepted), comments.

17muststore unlimited screening estimates.

18muststore unlimited Prospect Management comments assignable to key areas (e.g. relations, historic research, business information, etc.) and allow some comments to be made "confidential" for viewing and printing only by selected individuals.

19musthave the ability to see and to print as much information about a prospect in one place as possible, without doing continual searches through different parts of the system for the same prospect.

20musthave the ability to easily see which prospects and solicitations are assigned to a solicitor and which solicitors are assigned to a prospect.

21mustautomatically determine what annual giving solicitation letter should be produced when solicitations are produced based on ROWAN defined criteria (e.g. previous gifts and demographics).

22mustallow for the setting of data entry triggers based upon critical paths and moves management (i.e. ability to set what is triggered and when).

23musthave the ability to automatically "roll" annual solicitations from year to year with the capability of basing default asks on an ROWAN-defined formula that may vary over time.

24musteasily reassign staff or volunteer solicitor prospects to a new person due to turnover (e.g. via batch entry).

25musttrack the productivity of individual solicitors (i.e. # of prospects, # of solicitations completed, # of solicitations declined, total amount raised, # of new pledges, etc.).

26mustallow trip and contact reports in essayform with unlimited text attached to solicitation.

27mustprovide a method for storing, sorting and manipulating trip reports.

28shouldallow for temporary coding of prospects.

29shouldstore and display solicitation status and date associated with pledge along with how it is progressing through the pipeline.

30shouldhave a proactive visit/travel tickler system including a system for entering and recalling next steps for prospects.

31desiredhave fields for lifestyle indicators (e.g. country club member, length of yacht, year of airplane and number of engines, etc.).

32desiredhave fields for philanthropic indicators (e.g. gives to cultural causes, environmental causes, etc., amount donated, etc.).

33desiredhave fields for securities summary across all companies (market value, dividend, past stock sales, net value of options, grand total, number of stock gifts, total stock gifts, largest gift, largest gift date).

34desiredhave links to companies for which holding stock: insider name, company name, ticker symbol, exchange code, CUSIP, industry code, industry description, title of insider, business address and phone, form144 address and phone.

35desiredhave links to companies from which stock gifts were given: number of stock gifts, total stock gifts, largest gift, largest gift date.

36desiredhave linkage from constituent to organization as stock holder with stock information from CDA/Investnet: last transaction date, current shares ownership, security type, ownership code, current share price, current market value, one year high price, one year low price, estimated dividend, vested shares, nonvested shares, average exercise price for vested, average exercise price for nonvested, vested transaction date, nonvested transaction date, vested shares to expire, nonvested shares to expire, possible vested net gain, possible nonvested new gain, vested expiration date, nonvested expiration date.

37desiredhave automated procedures for assigning staff to prospects via ROWAN chosen criteria and with override capability.

38desiredcan show potential connections (e.g. system shows if person is in same city, on same board, in same company, etc. as a major donor, staff member, or other ROWAN chosen individual).

6.4.6. Planned Giving


1musthave the ability to track bequests.

2mustdistinguish between realized bequest and bequest expectancies and track date of both.

3musthave the ability to handle outside managed trusts.

4musthave ability to record the amount of a bequest expected, as reported by a living donor and distinguish between a specifically reported amount and the default value.

5musthave ability to record the actual dollar amount of a matured bequest as reported by the executor and the actual dollar amount of the bequest when received at ROWAN.

6musttrack type of bequest (e.g. contingent, outright, pecuniary, residuary, unknown).

7mustbe able to associate a bequest with a campaign, purpose, and allocation.

8mustlink bequests to resultant distribution/gifts and distinguish between value expected and value received.

9mustbe able to distinguish between anonymous and known will provisions.

10mustmaintain bequest status (e.g. known copy of will, distributed in full) and maturity (e.g. formal notice, informal notice, no longer in will, verbal notice, written notice, etc.)

11musttrack historical bequest status with dates through the life of the bequest (i.e. each status change is recorded for historical purposes along with the date of status change); specific dates of interest include: the date ROWAN was first informed that a bequest is coming to the University and the date of any information updates (i.e. when the bequest was created, when updates occur).

12musthave the ability to track life income plans (LIPs).

13musttrack a trust, gift annuity, or pooled income fund (e.g. Charitable Lead Annuity Trust, Charitable Lead Unitrust, Charitable Remainder Annuity, Charitable Remainder Unitrust, Deferred Gift Annuity, Gift Annuity, Pooled Income Fund A, Pooled Income Fund B, externally managed trusts).

14musttrack the status of the trust (e.g. active, complete, matured, pledged, or refused).

15mustmaintain face value, present value, estimated maturity date and estimated maturity value.

16mustlink to trustee(s) and contact(s).

17mustmaintain pay-out rate, remainder interest (deduction factor).

18mustmaintain multiple contributions to the same LIP.

19mustmaintain beneficiary name and date of birth.

20musttrack life insurance.

21mustlink to resultant gifts and pledges with checks and balances to ensure referential integrity.

22musttrack planned giving inquiries (who requested what when).

23musthave the ability to produce receipts with planned giving language.

24shouldhave the ability to store and access text descriptions of endowed funds.

6.4.7. Stewardship


1musthave allocations that include ability to categorize funds, details of fund restrictions, date fund was established, full name of fund for acknowledgment and reporting purposes, stewardship status, original donor, stewardship action required, estimated donor value.

2musthave the ability to determine who signs the acknowledgment and what type of special handling a gift or pledge reminder receives.

3musthave tickler system for stewardship activities done and tobe done.

4musthave the ability to track and report on inactive stewardship funds.

5shouldtrack stewardship to show what forms of stewardship a person has received (invitations, campus visits, letters from recipients, etc.).

6desiredhave the ability to generate a report identifying the fund, criteria, budgeted and spendable amounts, students and their grant amounts which would require interfacing with both the financial aid and accounting modules in CARS as well as the fundraising system.

7desiredtrack all donors who gave in memory and in honor of to the Annual Fund or to a general endowment by the name of the individual in whose memory or honor the gift was made.

8desiredbe able to flag a person as being interested in a particular project (like a building).

9desiredhave a rulesbased system for defaulting in several standard scenarios of stewardship with ability to override. For example, standard stewardship for endowed scholarships is that the donor receives the annual report from Financial Aid and an invitation to the Scholarship Donors lunch.

10desiredlink students awarded prizes to the associated sponsors.

6.4.8. Pledge and Gift Processing


1mustsupport gift entry and posting, giving inquiry screens, reports of giving and maintenance of related information such as accounts, funds and campaigns.

2mustinclude comprehensive support for matching gifts, as well as facilities for joint, group, honorary and memorial credit for gifts.

3mustfollow established general ledger account structure and protocols and allow further breakdown of General Ledger account codes into "allocations" with name and ultimate purpose.

4mustmap allocations to CAE codes for reporting purposes.

5mustbe assignable to ROWANspecific: purpose, motivation code, campaign, project, solicitation to indicate what appeal elicited the gift or pledge (e.g. leadership letter).

6mustaccommodate hard and soft credit for any constituent, pair of constituents, or group of constituents.

7mustprovide for spouse or other splits and group gifts and pledges with total settable by group.

8mustprovide a way to determine amount due from each member of a group including over a payment schedule.

9mustprovide a way to identify the primary donor (for reminders).

10mustallow for special handling (e.g. no reminders, monthly or quarterly reminders, etc.)

11mustallow for anonymous donors which transfers from pledge, to gift, to associated donor and allow multiple levels of anonymity (show name not amount, show amount not name, don't show name or amount, etc.).

12mustbe able to automatically produce a gift acknowledgment based on information already on constituent's record.

13mustbe able to record different types of gifts, such as memorials, honoree, giftsinkind, credit cards, securities, quid pro quo, payroll deductions, and electronic transfers.

14musthave the ability to see summaries of all gifts and pledges received from a person and/or a couple with gift and pledge clearly identified as such, and relationships between pledges and pledge payments shown as well as date, paid status, and allocation.

15musthave the ability to see where matching gift and soft credits are coming from as well as the linked company without having to go through additional lookups.

16mustallow any number unfulfilled pledges to be supported simultaneously for any constituent.

17mustdisplay the donor's outstanding pledges during gift entry, so that the operator can indicate the pledge being paid (or create an outright gift).

18mustlink pledges and their payments.

19mustallow for daily posting of all gifts received.

20mustgenerate audit trails for all online activity.

21mustprovide for batch balancing reports, gift receipts, pledge acknowledgments, management summaries.

22mustinclude giving screens with composite giving record, gift summary, and gift totals. Additional views must include hard credit (actual dollars given), matching gift company, giving for a particular year, and recognition credit (soft) shared between parent/child, spouse, employee,

23mustbe capable of supporting multiple pledges for each entity and providing easy access to ancillary information, such as pledge payments and honored/memorialized entities.

24mustbe able to customize pledge acknowledgments and reminders.

25mustaccommodate multiyear pledges with or without payment schedules.

26musthave easily accessible amount due/paid together on one screen.

27musthave easily accessible link between payments on a pledge.

28musthave means to determine if claim received on anticipated match.

29mustprovide for regular posting to the University's accounting system.

30mustperform monthly reconciliation by project code for checking against general ledger.

31musthandle prior year gift error corrections without modifying original data.

32mustproduce pledge reminders or acknowledgments at any time of the year with any solicitation criteria for any specific fund(s) or solicitation code(s).

33mustdetermine what annual giving solicitation, reminder, or acknowledgement letter should be produced based on ROWAN rules and scenarios.

34mustautomatically prepare batch sheet for cashier for daily/periodic gift postings.

35mustmaintain donor summaries by year and campaign.

36mustmaintain donor summaries by year and allocation or purpose or project or challenge.

37mustmaintain lifetime giving broken into pledges, pledge payments, outright gifts, matching gifts, etc.

38mustmaintain annual, capital, lifetime and other gift clubs based on ROWAN rules and allow manual adjustments.

39mustrecord payment type (credit card, check, gift in kind, security, etc.), transaction type (outright gift, pledge payment, bequest, trust, etc.).

40mustaccommodate receipt date, date of record, and update dates.

41mustcalculate gift discount amount for planned gifts.

42mustinclude General Ledger postable flag; allow gifts and pledges to be entered into the system but not posted to the General Ledger.

43musthandle memorial and inhonor gifts with person being memorialized recorded.

44mustallow gifts from individuals to pay other person's pledge.

45mustbe able to store nonpostable recognition credit like accrued interest.

46musthave system generated receipt number.

47mustaccommodate gifts-in-kind with textual description, donor value, inventory reference, appraised amount, liquidated amount, date appraised, date liquidated, appraiser name.

48mustaccommodate securities with textual description, # of shares, donor value, daily high and low of value date, value per share, amount paid to brokerage firm, date sold.

49musthave temporary or preliminary pledge entry area for phonathon or other use which can be used by many volunteers. Regular personnel should be able to review, edit, and delete the preliminary records without further actions or ramification in the system.

50musthave batch gift/pledge entry with default settings for gifts and/or pledges entered in that batch (with ability to override desired).

51musthave the ability to book pledges with or without a payment schedule and the ability to customize that schedule.

52musthave the ability to indicate match form received.

53musthave the ability to store matching gift claims and use that data as input when matching gift arrives.

54musthave the ability to display match ratio on claims.

55musthave the ability to produce one receipt for the company sending multiple matching gifts in one check.

56shouldautomatically update gift clubs.

57shouldhave the ability to incorporate two payment schedules into one pledge (e.g. donors are: one employee with payroll deductions monthly, one alumnus/a who makes a onceayear gift to complete the pledge).

58shouldprepare cumulative receipts for donors who participate via payroll deduction or who have arranged to have their credit card automatically charged on a regular schedule to acknowledge several installments with one receipt.

59shouldhave the ability to change payment schedules even after a payment has been made.

60shouldhave the ability to modify a pledge that already has payments attached to it.

61shouldshow annual, campaign, and total giving separately or together as per the users choice.

62shouldhave the ability to make minor changes to a gift before it is posted to General Ledger without having to batch and change receipt number (e.g. outright gift to pledge payment, campaign wrong, purpose code change, split gift, etc.).

63desiredability to easily differentiate types of payments (e.g. color-coded).

64desiredhave the ability to have one total pledge split between several allocations.

65desiredability to credit two allocations on one receipt.

66desiredability to have the gift linked to undecided/unspecified pledge when entered.

7. Instructions to Vendors

7.1. Outline for Submittal

All proposals must be presented in accordance with the following outline:

7.1.1. Company Information

Include the following information about your company:

a) Vendor name and address.

b) Salesperson/Contact name, title, phone, fax, and e-mail address.

c) WWW site URL.

d) Company history and organization.

a) User group affiliations (e.g. CASE, EDUCAUSE, your product users' group, etc.).

e) A statement of financial stability.

f) Explain any Chapter 7 or 11 filings during the past 10 years.

g) Business partners related to this proposal (e.g. hardware OEMs, companies for which you redistribute software, use for contract training, etc.)

7.1.2. Product Information

Provide a profile of your product(s) including:

a) Detailed description of proposed hardware and peripherals. (Note: Rowan University reserves the right to purchase hardware from any vendor.)

b) Software

i) Software product name (including current or former aliases), description, and version number.

ii) Name, description, and version number of proposed add-ons, modules, or other software which is subsidiary to the above (e.g. web interfaces).

iii) Name, description, version number, and company name of any third party tools you wish to make part of this proposal.

c) Product list of non-hardware items you are not making part of this proposal (i.e. additional software) if desired.

d) Documentation sample (5-10 pages or one section/chapter).

7.1.3. References

The vendor must provide six references with complete address, telephone number, e-mail address, and contact name. Preferred references would be universities, similar in size and with similar administrative systems scenarios as described above.

7.1.4. Proposed ImplementationProvide a description of the proposed system implementation including the following:

a) On-site personal visit days for vendor support during installation, conversion, and training.

b) Site preparation necessary for installation, conversion, and training.

c) Timetable detailing proposed duration of installation, conversion, and training.

d) Detailed outline of proposed responsibilities for both vendor and the University.

e) Description of the recommended training program including:

i) Types (e.g. classroom, lab, video, computer-based, etc.)

ii) Levels (e.g. general user, casual user, power user, system administration, technical, etc.)

iii) Modules (e.g. pledges and gifts, events management, alumni relations, etc.)

iv) Location (e.g. on-campus, in your facility, etc.).

7.1.5. Sample Agreements

Provide a copy of your standard contract, product license agreement, and maintenance agreement for our review.

7.1.6. Costs

Provide itemized costs for:

a) Capital costs

i) Hardware and Software (itemize each)

ii) Software only (if different from hardware and software purchased together)

iii) Software add-ons, modules, or other subsidiaries (e.g. web interfaces)

iv) Third party tools

b) Maintenance costs

i) Software and hardware

ii) Software only

iii) Upgrades

Indicate the last 3 upgrade dates

Cost of each of the above upgrades

Any hardware changes required by any of the above upgrades

c) Training costs

i) Initial training

ii) Ongoing/regular offerings

d) Conversion costs

i) Costs not included with capital costs if any

ii) Rates for consulting, contract programming, vendor-performed conversion, vendor travel, etc.

7.1.7. Response to RequirementsProvide answers to our requirements statements (section 6) as described in 6.1 above.

7.1.8. AppendixProvide an appendix, if desired, for any information expanding on your company or offerings not requested in the above sections.

7.2. Technical Questions

Technical questions should be directed in writing by May 11, 2001 to:

Tony Mordosky

Associate Provost

Division of Information Resources

Rowan University

201 Mullica Hill Road

Glassboro, NJ 08028

Phone - (856) 256-4401

Fax - (856) 256-4404

E-mail - [email protected]

7.3. Procedural Questions and Proposal Submittal Address

Procedural questions should be directed in writing to Mr. Keith Duke, Director of Purchasing, at the following address. Send six(6) complete and identical copies of the proposal to the same:

Keith Duke

Director of Purchasing

Rowan University

201 Mullica Hill Road

Glassboro, NJ 08028

Fax - (856) 256-4443

E-mail - [email protected]. Deadline for Submittal

Proposals must be received by the Rowan University Purchasing Office, shown above, no later than 2:00 p.m. on May 25, 2001.

8. Evaluating Approach and Criteria

The University will use the following approach to evaluate the proposals:

1. Review the proposals and select the vendors who most closely fulfill our requirements.

2. Contact selected references.

3. Select finalists.

4. Schedule and attend demonstrations of selected finalists.

5. Conduct a site visit to see software and hardware in an operating environment.

6. Compare the general costs.

7. Select the vendor and negotiate the contract.

Lowest cost will not be the sole determining factor and the award made will be made to the vendor whose proposal, in the opinion of the University, represents the best proposal considering but not limited to the following evaluation factors:

1. System which most closely fulfills the fundraising and alumni relations objectives of the Division of University Advancement.

2. Proven operations in similar environments.

3. Overall cost of the vendor's services including purchase price, installation, conversion, expansion, operation, and maintain costs.

4. Vendor support and responsiveness as reported by references.

5. Installation, conversion, and training program proposed.

6. Quality of documentation and completeness of proposal.

7. Perceived strengths and weaknesses of vendors product.

9. Proposal Conditions

The following general conditions apply to this request for proposal:

1. Rowan University reserves the right to reject any or all proposals.

2. Rowan University reserves the right to select all or any part of equipment and software that is being offered in your proposal.

3. Rowan University reserves the right to purchase all or part of the computer hardware from any source deemed most cost effective.

4. Vendors will be responsible for all costs incurred in preparing their proposals and demonstrating their system.

5. All contracts and agreements will comply with the legal requirements of the Commonwealth of New Jersey and purchasing regulations of Rowan University.

6. This RFP will be made part of the contract.

Date post:	02-Sep-2015
Category:	Documents
Upload:	arang
View:	10 times
Download:	7 times

Alumni

Documents