Skip to content Skip to site navigation Skip to service navigation

Software as a Service (SaaS) Guidelines

Gartner defines software as a service (SaaS) as software that is owned, delivered, and managed remotely by one or more providers. The provider delivers software based on one set of common code and data definitions that is consumed in a one-to-many model by all contracted customers at anytime on a pay-for-use basis or as a subscription based on use metrics. For more information regarding SaaS, visit Stanford's Cloud Transformation website.

Note: These guidelines assume that solution requirements have been determined. The guidance below covers the Project Management Life Cycle and Software Development Life Cycle from a SaaS implementation perspective; for more detailed information on both see the Project Management Life Cycle guidelines.

1
Identify Potential Solution

Evaluate what is available on the market and/or used by peers that aligns with the high-level business objective.

Steps for Completion:

  1. Research what solutions are available on the market.
  2. Obtain feedback from peer universities that may have implemented a similar solution. If no peer universities have implemented a similar solution, obtain feedback from corporations who have.
  3. Shortlist 3 - 5 possible solutions based on ability to meet business objectives, feedback from other institutions, alignment with UIT technical strategy, alignment with high-level cost range, and maturity of product.
  4. If deemed necessary, complete a formal Request for Information (RFI) for this phase.

2
Identify Implementation Partner (if required)

If the solution requires an implementation partner, the the vendor selection may need two Request for Proposals (RFPs).

Steps for Completion:

  1. Obtain a list of recommended implementation partners from the solution vendor.
  2. Obtain feedback from peer universities or corporation who have worked with the implementation partner.
  3. Shortlist 3 - 5 possible implementation partners based on feedback from other institutions/corporations, high-level cost range, and implementation partner company structure and maturity.
  4. If deemed necessary, complete a formal RFI for this phase.

3
Vendor Selection

(Note: If an implementation partner is needed in addition to the software solution, this process must be completed twice; once for the solution and once for the partner.)

Steps for Completion of pre-RFP (Request for Proposal):

  1. Determine who will run the RFP and if it will be done internally or outsourced to an external company.
  2. Create a timeline for RFP. (Note: Entire RFP process may have its own project plan, depending on the project's size.)
  3. Define scoring and grading criteria. See an example.
  4. Determine who will make the final decision in the selection process.

Steps for Initiation of RFP:

  1. Notify vendor to confirm interest in participating.
  2. Send the vendor a formal invitation for RFP.
  3. Send both business and IT requirements; include any questions that should be asked of all vendors. Business requirements should be accompanied by a detailed checklist of features and functions expected from the solution for vendor to confirm as part of RFP submission.
  4. Send the applicable questions specified by the ISO Data Risk Assessment website to the vendor for submission of information required from them. It is also useful to review the ISO minimum standards for Software and Platform as a Service (SaaS/PaaS) and Infrastructure as a Service (IaaS) and containerized solutions to determine what additional security related information to request from prospective vendors.
  5. Request a 3rd party WCAG 2.0 AA certification (or equivalent) from vendor for ADA compliance.
  6. Send Stanford's Technical Services Agreement (TSA) example.
  7. Schedule and run Q&A sessions or clarification calls with vendors, either per vendor or anonymous group approach.

Steps for Completion of RFP Vendor Presentations:

  1. Determine who should attend vendor presentations.
  2. Reserve venue for presentations.
  3. Schedule and run vendor presentations (~2 - 3 hrs), which should include the following:
    • Introduction and agenda
    • Vendor solution demo
    • Review of in-scope versus out-of-scope
    • Proposed implementation methodology and timeline
    • Proposed functional design that aligns with business requirements
    • Proposed technical design, including infrastructure and environments, data security, approach for single sign-on, data integration with existing systems, data loading/setup, and data conversion. Note: Integrations should use API/web service approach and not offline batch files. Any data file transfers between Stanford and the vendor need to be automated with no manual intervention, use secure methods such as sFTP or PGP/GPG data encryption, and have error handling procedures with automated error notifications for file or processing failures.)
    • Methods for extracting data from the cloud database storage, including web services and APIs
    • Proposed account and project management, development methodology, status updates and tracking, and roles and responsibilities
    • Proposed support structure for development, testing, and production; change management methodology; and knowledge transfer and training scope
    • Scheduling of future releases, upgrades, and patches
    • Customer references, preferably from those in higher education

Steps for Completion of Vendor Assessment (bid analysis) and Final Decision:

  1. Discuss the following vendor selection considerations:
    • Costs
    • Data rights
    • Disaster recovery/business resumption for SaaS implementation
    • Documentation available for implementation and user aids
    • Ease of configuration and amount of additional customization required
    • Exit strategy
    • Experience and references
    • Importance of ongoing vendor relationship
    • Local/national user groups
    • Match to business requirements
    • MinSec adherence
    • Offering of test and production environments
    • Options/strength for professional services
    • Security assessment
    • SLA
    • Strength of employees
    • Support model
    • User experience with vendor offering
    • Version change management practices
    • ADA Compliance — EXTREMELY IMPORTANT: All projects involving a user interface must ensure accessibility by those with disabilities. UIT standard practice is compliance with WCAG 2.0, Level AA. For more information, see the W3C Web Accessibility Initiative Web Content Accessibility Guidelines (WCAG) Overview website. Note: Many software vendors with whom UIT is interfacing are going by the VPAT/508 standard rather than WCAG. Stanford Office of Accessibility Programs advises that the two are essentially the same; 508 regulations normalised with WCAG in Jan 2017, and the new 508 VPAT template, closely matching WCAG, came out in October 2017.
  2. Use previously defined criteria to score and grade each vendor.
  3. Check the references provided by vendor.
  4. Arrange presentations from business owner to stakeholders and technical team regarding vendor scoring.
  5. Decide on vendor and solution.
  6. Formally notify vendor and initiate contract process.

4
Project Charter

Follow the project charter process. Specifically identify risks related to the project, as cloud projects have different technical and project risks than internally hosted implementations. (Note: The charter must be approved before the contract with vendor can be executed.)

5
Contract

Determine if the vendor's consulting services agreement or Stanford's TSA will be used. The TSA is handled by Procurement and wording/format are already approved by the Office of General Counsel (OGC), but using the vendor's agreement will extend the contracting process.

If using the TSA, send the sample to vendor, assuming it was not already provided to all bidders in the RFP process. Follow up with Procurement Contracts Team on whether vendor has any issues with the Business Associates Agreement (BAA) that is now an addendum to the TSA. The TSA should be "not to exceed" for more than just time and material. If additional resource hours are required from vendor, you must complete either a Change Request or an additional Statement of Work (SOW).

Regardless of whose agreement template is used, confirm that the agreement contains a section on data retention if relationship with vendor is terminated; Stanford data must be purged within a certain amount of time.

(Note: The contracting process can run in parallel to project charter, but the charter needs to be approved before the contract agreement is executed by both Stanford and the vendor.)

Important Notes:

  • Service Level Agreements may need to be redefined for each vendor.
  • Be sure that the contract is clear regarding future upgrades, i.e., clarity and agreement of frequency, responsibilities, and support.
  • Be sure that the contract is clear regarding access to data for reporting outside of the software product.
  • Anticipate challenges and delays when finalizing a contract if there is a Business Associate Agreement or BAA (external link) required, especially regarding insurance and indemnification requirements.

6
Statement of Work (SOW)

The SOW details the scope, timeline, resources, deliverables, and costs for the agreement, and there can be more than one SOW throughout the life of the agreement. Prepare and execute the SOW jointly with the vendor, making sure to discuss the implementation considerations listed below. Do not post SOW to an unrestricted Confluence page, as it might contain sensitive information like financials.

  • Authentication, authorization, and roles
  • Business process changes
  • Change management
  • Data integration (how data is shared/updated) and data dictionary, indicating data sources
  • Definition of roles and who does what
  • Fit/gap to vendor offering
  • Potential staffing changes
  • Review processes/document requirements
  • User experience with vendor offering

The SOW needs to cover the following sections:

  • Costs (including payment terms)
  • Deliverables
  • Development and tracking tools to be used
  • Issue escalation process for both vendor and Stanford
  • Production support arrangement
  • Quality assurance and testing scope (include performance or load testing if appropriate)
  • Resources (indicate onshore/offshore)
  • Roles and responsibilities of project participants
  • Scope
  • SLA
  • Timeline
  • Updates to sponsors/stakeholders

(Note regarding SLA: SaaS/cloud vendors won't usually provide an SLA similar to what UIT typically expects and/or follows. Except for scheduled downtime, the vendor feels that their application and infrastructure has enough redundancy that it would never be down.)

7
Vendor Setup/PO/Invoicing

Steps for Completion:

  1. Confirm that the vendor does not already exist in the Oracle supplier database by searching for the vendor.
  2. If vendor is new and does not exist in the Oracle database, request new vendor setup. Requester of new vendor will receive a system email confirming that the new vendor has been set up.
  3. Procurement's supplier setup team will send a link to vendor to provide information including confidential tax and payment information; follow up with vendor to confirm that they received the auto-generated system invitation email from Procurement and have supplied the requested information.
  4. Issue a requisition using SU Internet Procurement; requisition amount should match SOW.
  5. After requisition has been fully approved, PO will be sent to vendor. Vendor can proceed to invoice Stanford based on the terms and schedule as detailed in the master contract and/or SOW; vendor is not to invoice Stanford until approve PO has been sent to them.
  6. The Project Manager and Business Owner will approve invoices, and payment is remitted to vendor after approval.

8
ISO Risk Assessment

Steps for Completion:

  1. Determine the data risk classification, which determines the level of security assessment and review required.
  2. Review vendor-provided data risk information, which was part of the RFP submission, for completeness and ask vendor to provide any updates.
  3. Collect the applicable information security documentation as specified on the ISO Data Risk Assessment website.
  4. Go to ServiceNow and complete the Data Risk Assessment pre-screening questionnaire.
  5. If the pre-screening questionnaire determines that a DRA is necessary, you will need to complete the Data Risk Assessment Intake Form found on the ISO Data Risk Assessment website.
  6. As instructed on the ISO Data Risk Assessment website, after you have completed the DRA Intake Form and gathered the necessary documentation, please update your existing ServiceNow ticket by attaching the DRA Intake Form and any other documentation.
  7. If you receive a request from ISO for a review session with the vendor, coordinate with the vendor technical team to attend the security review meeting via phone call or onsite visit. Follow up on any action items until ISO grants approval.
  8. Once the DRA is complete, you will receive a final joint report from ISO and the University Privacy Office. Perform the ISO-recommended follow-up steps after you receive the report, as detailed on the ISO Data Risk Assessment website.

Important Notes:

  • Single Sign On should be vendor initiated instead of Stanford initiated if possible. SUNet ID should be the key field. Shibboleth/SAML should be the authentication method. And user information should be interfaced from Stanford if there is a large user population.
  • During the ISO & Privacy Office security review, classification of the data drives much of what vendor needs to secure or to provide, e.g., 3rd party audit reports, technical diagrams, risk assessment questionnaire, etc.
  • For vulnerability testing, the ISO requires 3rd party verification, not just an internal Qualys scan.
  • For data storage, Stanford data cannot reside in a database that is shared with other clients or used for other purposes.

9
Project Planning and Management

Complete the Project Initiation Checklist, making sure to communicate roles and responsibilities to vendor team and invite them to the project kickoff meeting. Also, make sure that a conference call bridge has been added to all meetings.

10
Design and Development

Steps for Completion:

  1. Review all technical and functional requirements with vendor; business analysts and business teams should participate.
  2. Confirm the development methodology, either traditional waterfall, agile, or hybrid; development methodology determines approach and tracking needed.
  3. Confirm the development resources with Stanford technical manager and vendor technical or project manager. Most cloud projects have shorter timelines, and vendor resources are available at the time of SOW approval. Internal Stanford resources, however, are often not on board or are delayed on other projects.
  4. With vendor participation, create a development timeline, detailed by week.
  5. Schedule weekly development check-in meetings to track status of the development work.

Important Notes:

  • For IP addresses (impacts SSO and web services), if the vendor uses AWS, then there will likely be challenges keeping the IP addresses in sync because Amazon controls the addresses and they can make changes without warning. ISO/Infrastructure do not allow white-listing of the vendor domain.
  • For accessibility, request for a 3rd party certification for WCAG 2.0 Level AA compliance.

11
Testing

Steps for Completion:

  1. Create and configure a new Zephyr project for tracking SIT and UAT test progress.
  2. Develop an SIT plan and calendar/schedule.
  3. Set up an SIT Exit Criteria page in Confluence for formal sign-off.
  4. Create SIT test cases/scenarios (normally done by the AS QA team).
  5. Set up recurring meetings with QA team to track and review testing progress.
  6. Execute the SIT testing.
  7. Create a UAT plan and review it with business groups, making sure to clearly define UAT lead, tester, and sign off.
  8. Create a UAT calendar/schedule.
  9. Create a UAT Exit Criteria page in Confluence for formal sign off.
  10. Create UAT test cases/scenarios (normally performed jointly by AS QA and business).
  11. Execute the UAT and performance testing.

12
Implement/Rollout

Steps for Completion:

  1. Prepare a rollout plan and checklist, which should involved the project manager, business owner and analysts, technical and development teams, change management team, and the vendor team.
  2. Post the rollout checklist in Confluence.
  3. Determine the duration of command center and reserve a conference room for this purpose.
  4. Identify who will staff the command center and when.
  5. Set up a conference bridge.
  6. Communicate the command center information.
  7. For large implementation, vendor project manager and key resources should be onsite to support rollout, go-live, and for one week post go-live.
  8. Create a SNOW production change ticket for CAB and get required approvals. For more details, see Implementation and Change Management.
  9. Attend a CAB meeting the week prior to implementation.
  10. Present the project to Support Strategies Planning (SSP), which meets once a month, so it is important to get on the calendar early.
  11. Follow all SSP process to inform UIT Helpdesk and other support teams regarding new implementations. Depending on the impact of a project, a first review followed by a second review may be required.

Important Notes:

  • Be sure that the change management process is agreed between Stanford and vendor, e.g. the number of environments after initial go-live (dev, test, prod), etc.
  • Be sure that the Production Support process is defined and agreed among the vendor and all major stakeholders, e.g., escalation procedures, coverage (24x7, etc., ticket tracking, etc.).

13
Post Go-Live/Production Support

Steps for Completion:

  1. Ensure that the vendor provides more responsive support during the initial 1 - 2 weeks after go-live, which should be defined as part of the SOW deliverables.
  2. Arrange for knowledge transfer and training for production support team.
  3. Formally communicate to business stakeholders that the solution will transition from project mode to production support mode.
  4. Prepare to support vendor's patching schedule and required testing cycles. Cloud solutions normally have predetermined patching schedules or release dates that require customers to upgrade within a short period of time; this has implications for regression testing to ensure that all must-have features function properly for the business. This is especially challenging when custom logic has been applied on top of a cloud solution.
  5. Schedule a project retrospective.