Management Services

Procurement Services

Purchasing Policy Manual

604 Software Acquisitions Guidelines

Software and Computing Equipment

Software maintenance agreements and licenses over $25,000 and computing equipment over $100,000 which are not on a volume purchasing agreement require the approval of the Vice President for Information Systems. All software purchases must be in accordance with the University Software Acquisition Guidelines.

Software Acquisition Committee

The Software Acquisition Committee was convened in October 1997, by the appointment of representatives designated by the Administrative Management Council. Members included representatives from User Departments, Campus Computing and Information Technology, Procurement, and UM Business Services.

Goal

To formulate policy for acquisition of software and associated maintenance which will prescribe rational processes for obtaining the most suitable software in a timely manner, at the lowest cost, with adequate safeguards for the University, fairness to vendors, and which will meet users needs.

Types Of Software

The Committee identified four categories for new software acquisitions:

• Corporate Applications: Software to be used throughout the University System or at more than one campus.
• Campus Applications: Software to be used campus-wide or by more than one Division, or requiring network level support at the campus.
• Department/Division Applications: Software to be used in multiple Departments, either within a campus, or by similar departments at several campuses, that does not require campus-wide network level support.
• Limited Use Applications: Software to be used for specialized applications within a Department.

Although the guidelines have been designed to address the varying needs during the acquisition of these types of software, the Committee recognizes that not all software purchases will fit neatly into one of these categories. The degree of integration with the University's existing computing environment will greatly influence who should be involved in the process.

The Committee also prepared recommendations for Upgrades or Expansion of Existing Systems and for Software Maintenance.

Recommended Process

The following twelve steps have been identified for software acquisitions. For large, corporate systems, each step is expected to be detailed, and involve gathering and distribution of information from and to a wide University constituency and vendor community, and high level approvals. For the Campus, Department and Limited Use Applications, each succeeding process is expected to be relatively less detailed, quicker, and may require a narrower collection and distribution of information, and fewer approvals.

1. Recognize Need, Appoint Committee and/or Project Manager
2. Define Procurement Process
3. Define General Needs and Develop Budget Projection
4. Investigate the Market
5. Refine the Budget and Identify a Funding Plan
6. Define Detailed Needs
7. Prepare and Issue a Request for Bid (RFB) or a Request for Proposals (RFP)
8. Evaluate Bids or Proposals
9. Determine Details of Purchase
10. Negotiate Contract Language
11. Obtain Final Approvals
12. Execute the Contract

A matrix is attached which identifies who should perform each step for each of the four types of applications.

The following suggestions pertain primarily when the acquisition involves a major expenditure or affects a large group. They may be reduced or eliminated for less comprehensive acquisitions.

1. Recognize Need, Appoint Committee and/or Project Manager: For large systems, the majority of the appointed committee members should be users from functional areas and end users, joined by information technology staff. Throughout the process committee members should represent their constituencies and should inform and seek advice and input from a broad spectrum of users, and from specialists such as technical support staff, Procurement, and legal staff. The committee as a whole should represent the entire University community to be affected by the software.
2. Define Procurement Process: This document is comprised of policy, practices, principles, and recommended procedures. How these apply to a specific software acquisition should be addressed with Procurement.
3. Define General Needs and Develop Budget Projection: General needs should be identified based on the problems to be solved as well as what could reasonably be expected to be available in the marketplace. Care should be taken to avoid defining needs too narrowly too early in the process. Preliminary budget projections may cover only the cost of software and a general estimate of other expenses.
4. Investigate the Market: Investigating the market may involve site visits, communication with other institutions using the product, vendor demonstrations, or a Request for Information (RFI). A broad base of potential vendors should be given an opportunity to participate.
5. Refine the Budget and Identify a Funding Plan: Before proceeding with the project, a refined budget plan should be prepared which covers all costs of consulting, acquisition, licensing, hardware, additional staffing, implementation, testing, training, maintenance, and upgrades, for a three to five year period. Consideration should also be given to costs of integration with existing systems, and to savings which may be obtained from phasing out systems that are no longer needed. Identify funding sources and obtain appropriate approvals.
6. Define Detailed Needs: A thorough needs analysis of software capabilities should be conducted. For example, for a Human Resources system, this analysis should encompass the needs of functional staff (such as Human Resources), end users (such as general departmental users), and technical staff (such as IT staff responsible for maintaining the system). The analysis should distinguish between required and desired capabilities and should also cover such things as maintenance, support, training, upgrades, existing or proposed hardware, and the computing infrastructure. If necessary, the budget plan should be revised.
       Upon completion of the needs analysis, if it is determined that a required feature is only available from one vendor, and only from one distribution source, a designated committee representative should work with Procurement to justify a sole source purchase. If appropriate justification is provided, it will not be necessary to issue an RFP. Upon approval of the sole source by Procurement, a written offering should be sought from the sole source vendor and evaluated for its fulfillment of the identified needs.
7. Prepare and Issue an RFB or RFP: If not determined to be a sole source, an RFP (or RFB) should be prepared based on the required (and desired) capabilities identified in the needs analysis. Items to be included are life cycle costing, maintenance, hardware requirements, service/support, availability, implementation schedule, installation/training, financial viability and experience of company, price (basis), the evaluation process and criteria, documentation to be provided by vendor, source code escrow, example contract, and options such as lease/purchase. Evaluation criteria, points and process should be identified.
       Procurement should assist the Committee or its designee in preparing the specifications which will be issued by Procurement. Upon issuance of specifications, all contacts with vendors must be through or with the advice of Procurement.
8. Evaluate Bids or Proposals: Evaluation methods should be summarized in the specifications, and evaluations should be conducted by a designated evaluation committee. For major acquisitions, a Procurement representative should observe and advise the evaluation committee regarding the evaluation process. In addition to reviewing technical and financial responses in the written proposals, activities that may occur as part of the evaluation process include: product demonstrations, site visits, contacting references, determining responsiveness (e.g. all questions answered, required submittals provided, etc.) The evaluation process must be well documented.
9. Determine Details of Purchase: Finalization of the purchase involves a determination of the exact software and services to be acquired from the vendor. This may be done in several ways, which should be predetermined:
   
      • no negotiation
      • negotiation with only the bidder receiving the highest evaluation points, or
      • negotiation with several bidders receiving highest evaluation points.
   
   Generally, negotiation with only the bidder receiving the highest evaluation points is desirable when an RFP is used. Some items to be negotiated may include optional modules or additional services or equipment. Favorable payment schedules should also be sought which tie the payment schedule to a successful implementation schedule.
10. Negotiate Contract Language: Typically the software vendor will provide a contract to be used. A Procurement representative, and if appropriate, a committee designee will work with the General Counsel's Office to remove or modify language which is unacceptable to the University, and to add provisions to safeguard the University's interests.
11. Obtain Final Approvals: Appropriate approvals should be sought and availability of funds verified.
12. Execute the Contract: With the proper approvals, the contract should be executed.

Upgrades Or Expansion Of Existing Software

• Review benefits of replacement vs. upgrade (Project leader and/or designated individuals).
• Provide sole source justification to Procurement (Project leader), if applicable. If not, refer to the steps identified for other software acquisitions.
• For a major acquisition, possibly inform the Board of Curators.
• Obtain the necessary approvals.

Maintenance

If appropriate, the initial periods of maintenance should be included in the RFP (RFB) specifications and life cycle costing should be used in the evaluation. Beyond this period,
maintenance costs should be reviewed as part of the decision process to continue or replace a system. Approval of maintenance contracts will be in accordance with delegated levels.