Skip to main content

This guide assists university staff in effectively evaluating software solutions. Following these steps ensures that your chosen software aligns with business needs, complies with security and data regulations, and integrates well with existing Stanford systems and technologies.

Stanford may already provide the software you need. You can start by checking the Software at Stanford and Essential Stanford Software websites. If you find what you need there, just request it, and you are done! If you don’t find what you need, here are five steps to help ensure your success.

Infographic showing the summary of steps for software evaluation. Described below.
Identify business needs. Identify requirements and consult existing resources. Assess business capacity. Assess your budget and capacity for ongoing support. Shortlist and screen the vendors. Narrow down to 2-3 options and complete data risk and accessibility screenings. Check data and integrations. Request data permissions, and check data integrations and single sign-on. Select a vendor. Check the dos and don'ts before making the final decision. Prepare for purchase. Review the PCard policy and other purchase considerations.

Choosing the right software and managing a successful implementation can be an expensive and risky process. Engaging an expert IT partner at the very start is the best way to ensure success.

If you need additional support, consider these options.

  • University IT (UIT) provides project management support to lead and manage your software selection and implementation project. Request the services of a UIT Project Manager.
  • Improvement, Analytics, and Innovation Services (IAIS) is an in-house consulting and implementation partner in Business Affairs serving Stanford University organizations and departments. Learn more about IAIS services.

Your IT partner can help you determine your organization’s needs and capacity, which will help you identify potential software solutions and vendors (also called university suppliers).  

Key requirements

  • Assess your operational requirements and pain points. This typically involves engaging with stakeholders and departments to document, analyze, and suggest workflow improvements to existing processes and/or solutions.
  • Compile a list of essential features the software must possess to meet your business objectives. Compile another list of “nice-to-have” features that aren’t deal breakers as well to help refine your decision-making.
  • Prioritize the needs of the users and their experience. If the software doesn't meet their needs or is too difficult to navigate, they'll be less likely to use it and may look for workarounds or alternative solutions.

Budget evaluation

  • Determine your budget for software and ensure it accounts for potential annual cost increases that can vary anywhere between 5% and 25% (or more), depending on the software vendor.
  • Confirm if your budget can support service level tiers (such as enterprise) that include additional and typically necessary security features.

Roles

Determine the people in your organization to fill the following roles:

  • Work with the vendor's support team for initial setups and integrations.
  • Provide desktop support, write documentation, and help with onboarding and offboarding users.
  • Have administrative privileges in the system, and perform ongoing administrative tasks, such as adding new users.

Now that you know what you need and what you can support, work with your IT partner to identify multiple providers who can meet the requirements. Input from peer universities can also help identify the most promising solutions. Ask your top choice vendors to provide product demonstrations and provide written responses to your list of requirements. Use a structured methodology or tool to assess and compare the vendor solutions (e.g., a scorecard). See "Higher education resources" in the Additional resources section.

Once you’ve narrowed down your options to the two or three top solutions, work with your IT partner to screen them in four essential ways:

Risk, security, and privacy

When purchasing software that will use Stanford data, you must adhere to university policies and legal requirements to ensure Stanford’s data is protected and in compliance with applicable laws. Failure to comply may result in serious consequences, such as reputational/brand damage, financial loss, and even legal action.

Complete the pre-screening section of the data risk assessment (DRA) to help determine the risk classification of your data, and learn which policies and/or legal requirements may apply to your situation before you test and purchase software.

Digital accessibility

Evaluating accessibility of a software product to ensure compliance with Stanford’s digital accessibility policy is another important consideration. Initiate an Accessibility Risk Assessment pre-screening.

For more details about requesting vendor accessibility documentation, refer to procurement guidance on the Office of Digital Accessibility website.

Single sign-on

Your IT partner will help you ensure that software providers can integrate with one of the university’s existing single sign-on (SSO) methods. Stanford single sign-on protects the university’s restricted data, while enabling Stanford people and trusted external colleagues to access resources with one login.

Data needs

Work with your IT partner to evaluate your data needs and plan how to address them. This is a crucial step to ensure your selected software will function properly in Stanford’s environment.

SSO provides some basic registry data (people and organization data). If you need registry data beyond what SSO provides, your IT partner will provide a business justification and request permission from the business owners of the data to do so.

Your IT partner will help you determine data integration requirements and will work with UIT’s Middleware and Integration Services (MaIS) team to create an integration plan.

Check these Do and Don’t lists before making a final decision.

Do

  • Experience the software firsthand by implementing it in a real-world scenario, even if only temporarily. This hands-on approach will give you a clearer understanding of its capabilities and help you make a more informed decision when it comes to purchasing. Many vendors offer a sandbox environment where you can explore the software's features using sample data. Alternatively, consider a pilot program, which allows you to test the software with your own data and processes, albeit at a cost.
  • Request customer references to verify how the solution is meeting both business process and technical requirements.
  • Confirm the vendor's Service Level Agreements (SLA) terms align with your needs; most cloud agreements are not easily negotiable.
  • Request to see the vendor’s “blueprint” for your success. This should be in clear documentation that outlines the vendor’s implementation and support methodology .
  • Ask for educational discounts available for academic institutions. Leverage existing university memberships, like Internet2, for pre-negotiated contracts and discounted pricing for education.
  • When click-through terms and conditions are present in an agreement, utilize the university contracts team to negotiate the specifications of any legal terms. This way you avoid agreeing to contract terms you do not have the authority to agree to.
  • Learn more about selecting a supplier on Fingate.

Don’t

  • Avoid “freemium” versions of software. Your organization is responsible for securing Stanford's data, and freemium versions do not offer the protections you'll get with a contract.
  • Some SaaS products offer free trials, which may be helpful. Before taking advantage of them, be sure to fully understand trial commitments, terms, and conditions. Remember that adhering to data security and privacy requirements is your responsibility even within a free trial. 
  • Automatic subscription renewals are problematic. It’s easy to forget about a renewal, find you no longer need the software, and then find out your subscription has auto-renewed and you owe the vendor money. It is often extremely difficult to remediate these situations because you may have a legal agreement in place that allows for “auto-renewal.”

Additional considerations:

  • Be cautious about verbal assurances from vendors that are not documented in contracts, as they are not enforceable.
  • Smaller SaaS companies can provide the greatest risk to Stanford. Vendors with immature business practices and limited funds cannot support an enterprise customer with the complexity and compliance needs of Stanford. At Stanford, we pride ourselves on innovation, which is often found in smaller SaaS companies, but they need to be mature business partners too.

When it's time to purchase, review these considerations.

  • Users who are not authorized to sign legal agreements on behalf of the university must not accept any click-through agreements presented by cloud vendors. Purchases requiring signatures or click-through agreements must be submitted for review through the contract process
  • Unless it is specifically prohibited by that guidance or local school/unit policy, software that presents Low to Medium Risk may be purchased on a Stanford Purchasing Card (PCard) as long as the transaction is in accordance with PCard policy, (i.e., $4,999 or less), or with personal funds (reimbursement).
  • Please refer to the PCard policy to stay up-to-date on permissible and non-permissible PCard purchases. However, purchasing methods such as SmartMart Catalog Suppliers and Non-Catalog Requests in iProcurement may be preferred over these options because they provide the opportunity for financial review and approval to occur before the purchase is finalized.
  • Confirm that all relevant compliance, security, and operational terms are documented in the purchase agreement.

Higher education resources

Your IT partner or project manager may consider leveraging one of the following higher education community vendor assessment tools (HECVAT) by EDUCAUSE for an in-depth evaluation process:

Compliance

Adherence to laws, regulations, and university policies regarding data and software usage.

Higher Education Community Vendor Assessment Toolkit (HECVAT)

A questionnaire by EDUCAUSE that vendors complete that attests to the practices put into place by third parties regarding cybersecurity and privacy. HECVATs are associated with Higher Education Information Security Council (HEISC) and Internet2 consortia. Stanford’s Office of the Chief Risk Officer seeks a completed HECVAT when assessing the risk associated with third-party vendors.

International Organization for Standardization (ISO 27001)

Another well-regarded standard for information security. Like SOC 2, certification gives assurance that practices to protect information and privacy are in place, though it’s less common in consumer-oriented services.

Service Organization Control 2 (SOC 2)

A widely recognized cybersecurity compliance framework. It’s used between businesses and consumers to assure compliance with established cybersecurity and privacy practices. SOC 2, Type 1 is a point-in-time evaluation certification, while Type 2 is an assessment of the same controls over a period of time. Stanford’s Office of the Chief Risk Officer looks for SOC 2 certification whenever a Data Risk Assessment is conducted for third-party risk evaluation.

Service Level Agreement (SLA)

A contract that outlines the expected service levels between a vendor and a client.

Single Sign-On (SSO)

The ability to centrally authenticate once, then be authorized to automatically log into further resources. It’s commonly used in web applications. Stanford’s familiar web login system is an example of an SSO deployment.

Software as a Service (SaaS)

A software delivery model where applications are hosted in the cloud.

Voluntary Product Accessibility Template (VPAT)

A document that outlines how a product or service complies with accessibility standards. It helps businesses and organizations assess the accessibility of technology products for individuals with disabilities.