Skip to main content

Software Evaluation Guide

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.

Key requirements

Compile a list of essential features the software must possess to meet your business objectives.

Consider whether other departments have similar needs or existing solutions. Collaboration can lead to unified software purchases. Leverage the Campus IT Plan to find out.

Consult existing resources

Before purchasing new software outside of Stanford providers, search the Software at Stanford catalog to see if it is already provided.

For additional support, engage with UIT Business Relationship Managers, Software Licensing, or local IT support for insights into software already available or might become available soon.

Search Software at Stanford

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 even more), depending on the software vendor you select.
  • Confirm if your budget can support service level tiers (such as enterprise) that include additional and typically necessary security features on an on-going basis.

Software lifecycle management

  • Identify who will manage software contracts, licenses, and renewals when staffing changes occur.
  • Maintain a central inventory of software subscriptions and agreement dates.

It’s important to consider your ability to support users and workgroups throughout the duration of your software subscription, as this is a critical factor in any successful adoption of a new software tool.

 

What to consider

Here are some important questions to ask yourself before purchasing a software solution:

  • Who will work with the vendor's support team for initial setups and integrations?
  • Do you have ongoing access to IT support professionals who have been trained on how to use the software?
  • Who will provide desktop support, write documentation and help with onboarding and offboarding users and accounts?
  • Which groups will be assigned administrative privileges? Will the administrator(s) have the bandwidth to undertake the necessary ongoing administrative activities?

If you would like help thinking through these questions as you plan your project, consider consulting with a project manager through UIT Project Management for IT Projects.

Consult your local IT team

We highly recommend consulting with your local IT support during this phase, as they are experts who intimately understand the organization that you operate in and can help you ensure that the software product(s) you select will work best in your environment. By starting with discussions with your local IT support, they can also help ensure that this process goes as smoothly as possible for you and make hand-offs to other Stanford teams where appropriate and if necessary (depending on data risk/approvals, security, privacy, etc.). 

Data permissions

If you plan to use university registry data (this includes people and organization data), you MUST request permission from the business owner(s) of the data to do so. Please follow the link below to adhere to the process.

Request permission from Stanford business owners if you plan to use registry data. 

Failure to request permission to use registry data may result in your selected software of choice not functioning properly or at all in Stanford’s environment (depending on your business requirements).

Data integrations

1. Review the MaIS Data Usage and Integration Policies.

2. Determine service and/or data integration requirements. Some questions to consider:

  • What's the data input and output?
  • Is there any data transformation?
  • How often will data be updated?
  • Are there any data authentication or authorization requirements?

3. Contact the Middleware and Integration Services (MaIS) team to review the requirements.

4. Together, you and the MaIS team will decide on the best solution for your needs, which could include:

Your risk responsibility

By purchasing and implementing a software tool that uses Stanford data, you must adhere to university policies and legal requirements to ensure Stanford University’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.

To help you understand the level of risk you’ll need to accept, complete the following steps:

Complete the pre-screening section of the data risk sssessment (DRA) to help determine the risk classification of your data. This process will also inform you of any policies and/or legal requirements that may apply to your situation before you test and purchase software. This is a crtical step to complete that will set you up for success with your vendor engagement(s).

Accessibility responsibility

Evaluating accessibility of a software product to ensure compliance with Stanford’s digital accessibility policy is another important consideration. Regardless of the method in which software and services are purchased (contract, PCard, etc.) consult with your local IT team or department administrator to conduct an Accessibility Risk Assessment pre-screening.

For more details about requesting vendor accessibility documentation, refer to procurement guidance on the ODA website.

Minimum considerations

  • Confirm the vendor’s Service Level Agreements (SLA) terms align with your needs; most cloud agreements are not easily negotiable.
  • Ensure that software providers can integrate with at least one of the university’s existing authentication/authorization methods for administrative accounts:  SAML2, AD authentication, Shibboleth, or OpenID Connect (OIDC).
  • Request clear product documentation that demonstrates compliance with security and accessibility requirements.
  • Reputable vendors should be able to provide at least two of the following certifications:
    • Security: Service Organization Control 2 (SOC2 ) and/or International Organization for Standardization ISO 27001
    • Accessibility: Voluntary Product Accessibility Template (VPAT)

Dos

  • Request clear product demonstrations and documentation that demonstrate compliance with security requirements.
  • Request information regarding digital accessibility standards from the supplier, developer, or contractor. This information can be helpful in determining how responsive the supplier may be regarding the accessibility of their digital products or services (e.g., websites, web-based applications, design services, mobile apps, or other electronic content
  • Request to see the vendor’s “blueprint” for your success. This should be in clear documentation that outlines the vendor’s implementation methodology so you know what resources you need, and when you need them to have a successful implementation.
  • Understand where data will be stored and what legal frameworks apply based on the vendor's location.
  • 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.

Don’ts

  • Avoid reliance on free trials or “freemium” versions as your organization is still responsible for securing data during these periods.
  • 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.”
  • 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. All agreements must be submitted for review to the University Procurement Contract Group. 

Additional considerations:

  • Be cautious about verbal assurances from vendors that are not documented in contracts, as they are not enforceable.
  •  

Third-party plug-ins, add-ins, extensions

Before installing and using a third-party add-in or plug-in with a university Microsoft 365 account, a formal review must be complete to ensure Stanford data is appropriately protected. Refer to the M365 add-ins/plug-ins guide (coming soon) for more information about the review process.

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

  • Unless it is specifically prohibited by that guidance or local school/unit policy, software may be purchased on a Stanford Purchasing Card (PCard) or with personal funds (reimbursement).
  • Please refer to the PCard policy to stay up-to-date on permissible and non-permissible PCard purchases.
    • Purchasing methods such as SmartMart catalog and non-catalog requisitions 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.

Minimum requirements

At the very minimum, complete the following steps:

  • [ ] Compile key business requirements.
  • [ ] Assess your budget and management capabilities for the software lifecycle.
  • [ ] Ensure ongoing IT support and training are available.
  • [ ] Request permission to use registry data (where applicable)
  • [ ] Complete the DRA pre-screening form.
  • [ ] Complete the Accessibility Risk Assessment pre-screening and ask the vendor to provide you with this list of documentation.
  • [ ] Verify vendor compliance with university security/privacy, policy and legal requirements.
  • [ ] Confirm that purchase decisions are well-documented with clear terms and conditions, including all relevant compliance, security, and operational terms in the purchase agreement.

Vendor checklist tool/resource

If you’d find it more helpful to view all suggested requirements that you should be considering by line-item so that you can track them and know what to ask your vendor(s) for, consider leveraging one of the following higher education community vendor assessment tools (HECVAT):

Resources for further assistance

University IT resources:

Financial Management Services resources:

Glossary of terms

SaaS (Software as a Service)
A software delivery model where applications are hosted in the cloud.

SLA (Service Level Agreement)
A contract that outlines the expected service levels between a vendor and a client.

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

Need more help? Request a consultation