The University of Texas at Austin

Current ITS Projects

Product Selection Methodology

Executive Summary

The ultimate purpose of a software selection project is to provide the university with an information system that will address the current and future needs of students, staff, and faculty. The Product Selection Methodology provides an overview of the steps and processes used to determine which product or solution set will best meet the needs of the university. The outcome of this process is the documentation of the solution recommendation. This methodology is not intended to provide detailed guidance for each step; it is intended to give the user an overview of the process and its steps. The methodology is accompanied by templates that teams can use and modify to document their findings and criteria.

Methodology

  1. Identify Business Need: Using information gathered from surveys, staff, governance groups, and users, define the business need to replace the current solution or create a new solution. The business need can be documented in the Project Charter and is used to describe the overall purpose and goals of the project.
  2. Form Team: Define the team that will participate in the selection. Include both technical and functional team members. Check with the Information Security Office (ISO) and Purchasing regarding their desired level of participation. Define the Customer Steering Committee (CSC) and review committee membership with appropriate leadership and governance groups. This information may be documented in the Project Charter.
  3. Determine Requirements: Document functional, technical, security, accessibility, implementation, and support requirements for the solution. Once requirements have been solicited, defined, and documented, they need to be approved by the CSC. Requirements should be prioritized and categorized; see the Requirements and Traceability template.
  4. Identify Solution Options: Using benchmarks with other universities, industry research, solutions in use on campus, and other research, identify potential solutions that may meet the requirements. This information can be documented in the Research Summary.
    1. Consider vendor packages, open source, and software as a service options.
    2. A custom solution is often an option that must be evaluated as well.
  5. Create RFP/RFI/RFQ (optional): Depending on the size and complexity of the solution, a Request for Proposal (RFP) / Request for Quotation (RFQ) may be needed to perform the final selection. For smaller projects or where there are low costs, this step may be optional.
    1. To both refine requirements and narrow the choices, the team may choose to release a Request for Information (RFI) first to determine what solutions and approaches are available.
    2. Define core evaluation team and discuss mandatory requirements and scoring with Purchasing, including HUB and other contracting requirements. See the Purchasing RFI web page for details on the RFI process.
    3. Determine what weighting will be given to requirements, costs, references, support options, etc.
    4. Include reference checks in evaluations.
    5. Define final evaluation criteria and selection process.
  6. Perform Initial Evaluation of Solutions: Identify the full set of evaluation criteria, including factors that may not have been included in the requirements document such as cost, licensing and support options, and timeline for solution implementation. Use product demonstrations, current user input solicited, product documentation, and industry reviews in analysis. For initial evaluation, it may be helpful to define a sub-set of mandatory or "show stopper" requirements which can be used for more efficient comparison and elimination of unsuitable options. Analyze solutions against requirements and determine which may meet the requirements. The results of this evaluation can be documented in the Research Summary.
    1. Mandatory requirements can be functional (the application must do 'x'), technical (the application must be in a Java-based technology), or support (the application must require no more than one day of training for end users).
  7. Evaluate Solutions Against Requirements: Based on the initial evaluation, define the short list of any solutions that meet all mandatory requirements, eliminating solutions that do not meet these. Evaluate the remaining solutions against all project requirements. You may use the Solution Evaluation Summary to document the results.
    1. Conduct vendor demonstrations and information discussions to refine evaluation.
    2. Consider installing a temporary or trial version of the product as part of the evaluation, if possible.
  8. Evaluate Costs: Create cost estimates for implementation and on-going maintenance and sustainment and document in the Solution Evaluation Summary. The estimates should include:
    1. Application costs, such as build/configuration, customization, conversion, interface implementation, and on-going maintenance.
    2. Licensing, including initial and on-going maintenance/subscription costs.
    3. Hardware and operating system or hosting costs.
    4. User support, help desk, sustainment, documentation.
    5. Training estimates, for the product, users, and help desk.
    6. Consideration for the fact that some products may have a low upfront cost but high maintenance or user training costs, while others may have a higher initial cost but lower maintenance and user support costs.
    7. Determine and execute the Best and Final Offer (BAFO) process if needed for cost evaluation.
  9. Make Recommendation: Using the evaluation criteria, determine the best solution for the university. You may document the recommendation in the Solution Evaluation Summary. Review recommendation and obtain CSC approval.
  10. Obtain approval from appropriate governance group and complete contracting effort.
  11. Create Implementation Plan: Define the overall high-level timeline for each phase of the project and detail out the next stage (for example, Design) for implementation.