GCC/OIT - Software Request SLA

This article details the GCC Software request and procurement process, timelines, and details.

GCC/OIT - Software Request SLA

(DRAFT-Under Review - This is a test article)

This document details the GCC Software procurement process. It starts with the software's Subject Matter Expert, i.e., the requester, submitting a software request form via the GCC Service Desk portal. When the form is completed, it generates a Service Request that documents all process steps. The requester should have a good understanding of the software's functionality and purpose. They can obtain a quote and additional supporting documentation if they have been working with the vendor.

The teams involved in this process are the GCC Office of Information Technology (OIT), MCCCD Legal Services, GCC Fiscal Services, and MCCCD Purchasing. Each group's ability to process a purchase request may vary due to the time of year and workload. The procurement timeline heavily depends on the complexity and cost of the requested agreement. Any software licensing being purchased that exceeds $250,000 must be reviewed by the governing board. The college's president must review any software request above $50,000. Any software over $25,000 must have one of the following: three competitive bids, reference MCCCD IFB/RFP Contract and/or DO Purchasing approved Cooperative contract, or a competition waiver. This should be completed and sent to Fiscal Service for review and routing approval.

The OIT part of the software request process involves a series of thorough checks. These checks are designed to ensure that the correct licensing is being purchased for the project's scope, promoting fiscal responsibility, integrity, and due diligence in the process.

OIT Check List: Pre-Purchase ( Timeline 1-2 weeks Pending Workload)

• Security Check - Data integrity and verification of PII

  • A completed Privacy and Security Questionnaire for Screening form must accompany this check

• Enterprise deployment and licensing verification check

  • Verify the software meets our enterprise deployment standards for computer installation (unless it is cloud/web)

  • Verify the licensing count requested matches the installation number requested

  • Ensure the licensing type requested is compliant with instructional environments (if applicable)

• American Disabilities Act - student-centric

  • In coordination with the DRS department of GCC, ensures that any software purchased for students has Americans with Disabilities Act (ADA) accessibility compliance alternatives.

  • In approval notes, the client will be notified whether or not the product is ADA accessibility compliant. The client is responsible for coordinating with DRS if accommodation(s) are needed for a non-compliant title.

• Pre-Purchase Process -

  • Follow up with requester as needed

  • Obtain necessary quotes as needed (This is primarily an external step)

  • Contract Lifecycle Management Entry (CLM)

    • Requester and Vendor Contact Information

    • Privacy and Security Questionnaire for Screening Form (PSQS)

    • Signed/Unsigned contract or purchasing documentation

    • Terms and Conditions (TCs)

    • Approval

  • Create Requisition and ProCard/Pcard (If being paid by ProCard, before purchase, must obtain a ProCard/Pcard purchase exception from DO Procard Administrator Gloria Toscano at District Purchasing)

  • Submission of Requisition through FMS approval process to Fiscal

MCCCD DO Legal Review (Contract Lifecycle Management - CLM)(Timeline 3-4 weeks )

• MCCCD Legal reviews documentation included in the CLM record (proposal/quote/invoice/etc.); if any of the docs refer to a URL with additional terms and conditions, we'll download a copy, add it to the record, and review

• Based on PSQS, if Q1-Q3 are answered yes, we will also review the privacy policy and determine if their standard terms are sufficient for what data will be shared/accessed; if they are not, we will send the vendor a copy of our Data Confidentiality and Security Addendum to review and sign (this may incur additional review time)

  • As part of the security/data confidentiality review, the product manufacturer or service provider may be requested to provide a SOC 2 report. This step is subject to external response times.

• If the documentation in the record does not require a signature and the PSQS has been approved (with or without a signed DCSA), the document will be approved, and a note that TC review is only required will be added to the record, which will then be finalized.

• If a signature is required, the District’s General Council will route the agreement to our contract attorney for signature (and the vendor, if needed).

• The timeframe for review is a couple of days for standard TCs, no CI/PII shared with the vendor (requiring a privacy and security review), and a week for PSQS review as long as the vendor is responsive to our request to review/sign our DCSA—longer if they are not. Documentation requiring a signature to finalize adds another day for the MCCCD-only signer, more if the vendor needs to sign, too.

• As long as the vendor is responsive to our questions and requests to sign DCSA or countersign, 1-2 weeks should be enough time to get it through CLM from start to finish. During rush periods, you can give us a heads-up, and we can expedite reviews, but keep these to a minimum whenever possible. Ideally, we would like to get TCs reviewed, with no PSQS implications and no signatures needed, to be turned around the same day.

• Please note that some agreements are being held up not by Legal/PS review but by the College not launching the workflow as soon as a contract is entered in CLM. Legal can't start until the College approves the workflow.

  • The review submission and purchase request must be submitted simultaneously, per DO SOP, thus requiring all request information upfront before further processing can continue.

GCC Fiscal Check List - In Process Purchasing (Timeline 3-4 weeks pending workload)

• Reviews Requisition

  • This includes the executed contract/agreement and approval with no signatory requirements (CLM approval) and quote.

  • Review competitive quotes (If applicable)

  • Reviews Competition Waiver (if applicable)

  • Approves or Denies (requesting additional information)

• Dispatch Purchase Order

  • OIT Technology Support Analyst, or designated purchaser, submits the executed contract and purchase order to the vendor for invoicing to Accounts Payable. This step requires the requisition owner to review the invoice for billing accuracy and final payment remittance. The vendor may not send deliverables until this step is completed.

  • If there are any discrepancies, corrections can take up to two weeks, depending on vendor responsiveness. Billing corrections require updated documentation to be appended to the requisition for fiscal review.

Post Purchase

OIT development and delivery to desired location(s) (Timeline 1-2 weeks pending workload)

• Development

  • Systems Admins download and package software for delivery through management tools.

  • All applications go through three layers of testing before they are published.

  • Any freeware is tested for evidence of malicious code.

  • Applications are posted in the appropriate self-service area depending on the platform or pushed to the location as required.

• User Acceptance testing

  • OIT strives to deliver software with enough time for the requester or end-user to test the application(s) and verify that it meets the needs and functions correctly.

 

Other considerations

Timelines

The entire software request process can take 8-10 weeks to complete. However, renewals not requiring CLM review can be processed much faster. Planning is crucial, and requests should be submitted by the posted deadlines, which are usually around the 45th day of the semester before the semester in which the software will be needed.

When no request form is necessary

If you have installed software that needs an update and the update is free, you don't need to go through the software request process. Instead, you can submit a request via our Service Desk to create a ticket for the work. For example, if you're updating from version 12.5 to 12.7 and this update is already included in the version we own, a service request is all you need. The same applies to free applications unless their terms and conditions change or the product changes in a way that could affect data handling. Depending on the admin workload, it may take 1-2 weeks to deliver the updated application(s) to the required destination.

If you need a known GCC-owned application, you can request it via our Service Desk. This will create a service record, and the application will be provisioned to an endpoint or user. This is often the case for licensed applications, where OIT doesn't publish the application for all users to install due to licensing restrictions. By generating a service request, OIT admins can make the application available in the applicable self-service center or push it directly to the computer. This type of request doesn't require development time and can typically be completed in one business day.

Classroom/lab requests

For labs with a lot of software, OIT will work with the department in a hybrid manner, using both Software Request Forms and a spreadsheet. Anything that needs to be reviewed by CLM will require the form to be filled out, automatically creating a ticket to track the work and update the requester.

EULAs, PSQS, and free software

Many free applications still have terms and conditions. For example, an app may be free for an individual but not for a business or school. Sometimes, an app may be free for educational use by an individual but not meant for use in a lab environment. This is where knowing the End User License Agreement (EULA) becomes important. The EULA will state the terms and conditions for using the software. In such cases, the Office of Information Technology (OIT) will review the request and determine the best course of action with the requester. Free software can also be subject to Contract Lifecycle Management (CLM) review when Confidential Information (CI), Personally Identifiable Information (PII), and/or Family Educational Rights and Privacy Act (FERPA) data is processed, accessed or handled by a third party.

Security

Security will always be a top priority in OIT's software delivery to the campus. If a requested application is found to have any suspicious components during the testing phase, the request will be denied, and the requester will be notified. OIT will thoroughly examine software from non-standard download sites, including Github.

OIT will ensure that any requested application complies with our mandatory endpoint protection. If there is a conflict, the campus security officer will be consulted. If an exception can be made without compromising the security of the endpoint, it will be documented and put into service. If an exception cannot be made, OIT will review the request and work with the requester to determine the best course of action.

Disability Resource Services

If the DRS department determines that an application is not compliant with accessibility standards, the requester will be notified. This doesn't necessarily mean that the request will be denied. However, if a student requires an accommodation for the application, it will be the requester's responsibility to collaborate with DRS to ensure that an accommodation is made available within ADA guidelines.

 

Glossary of terms

CIC           Confidential Information

CLM         Contract Lifecycle Management

DCSA       Data Confidentiality and Security Addendum

EULA        End User License Agreement

IFB            Invitation for Bid

PII            Personally Identifiable Information

PSQS       Privacy and Security Questionnaire for Screening form

RFP         Request for Proposal

SOC 2     Service Organization Control Type 2

TC          Terms and Conditions