GCC/OIT - Software Request SLA

Uploaded Image (Thumbnail)

GCC/OIT - Software Request SLA

This document details the GCC Software procurement process. It starts with the software's Subject Matter Expert (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. If they have been working with the vendor, they can obtain a quote and additional supporting documentation.

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 purchase requests may vary based on the time of year and workload. The procurement timeline heavily depends on the complexity and cost of the requested agreement. Any software licensing purchase exceeding $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, a reference MCCCD IFB/RFP Contract and/or DO Purchasing-approved Cooperative contract, or a competition waiver. This should be filled out 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 licenses are purchased for the project's scope, promoting fiscal responsibility, integrity, and due diligence.

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 (PSQ) must accompany this check

    • A completed Higher Education Community Vendor Assessment Toolkit (HECVAT) will need to be provided by the vendor, or the can fillout one from MCCCD.

  • 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)

  • Americans with Disabilities Act (ADA) - student-centric

    • In coordination with the GCC DRS department, ensure that any software purchased for students includes Americans with Disabilities Act (ADA)-compliant accessibility features.

    • In approval notes, the client will be notified whether the product is ADA-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 the 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 (PSQ)

      • Higher Education Community Vendor Assessment Toolkit (HECVAT)

      • Signed/Unsigned contract or purchasing documentation

      • Terms and Conditions (TCs)

      • Approval

    • Create a requisition and/or request ProCard/Pcard approval from Fiscal Services. (If requesting to use ProCard for purchase, being paid by ProCard, contact Fiscal Services to obtain approval. Please note that ProCard is prohibited for CLM contract payments unless Fiscal Services and the District ProCard Team have granted prior approval.

    • Submission of Requisition through the 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 PSQ, 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.

  • The vendor must submit a HECVAT for review if one is not already on file with MCCCD. Certain vendors may already have HECVAT available to deliver.

  • If the documentation in the record does not require a signature and the PSQ has been approved (with or without a signed DCSA), the document will be approved, and a note indicating that TC review is only required will be added to the record. The record 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, if needed, to the vendor).

  • 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 an additional day for the MCCCD-only signer, and more if the vendor must sign as well.

  • As long as the vendor is responsive to our questions and requests to sign the DCSA or countersign, 1-2 weeks should be sufficient time to complete the process through CLM from start to finish. During rush periods, please give us advance notice so we can expedite reviews. However, keep these requests to a minimum whenever possible. Ideally, we would like TCs reviewed with no PSQ implications and no signatures required, and returned 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. Additionally, if counterparty (vendor) signatures are required, this can extend the approval time.

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

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

  • Requisition Review / Approval

    • Once CLM contract has been executed, provide CLM# in the Line Description of the requisition and upload documentation. This can include quotes, executed contracts/agreements, and the CLM approval email for the contracts with no signatory requirements.

    • Reviews 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 ensure the final payment remittance is accurate. The vendor may not deliver the deliverables until this step is complete.

    • If there are any discrepancies, corrections may take up to two weeks, depending on the vendor's 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 undergo three layers of testing before being published.

    • All freeware is tested for malicious code.

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

  • User Acceptance Testing

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

 

Other considerations

Timelines

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

When no request form is necessary

If you have installed software that requires an update and the update is free, you don't need to submit a software request. Instead, you can submit a request via our Service Desk to create a ticket for the work. For example, if you're upgrading from version 12.5 to 12.7 and that update is already included in our version, 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 with licensed applications, where OIT doesn't publish them for all users to install due to licensing restrictions. By submitting a service request, OIT admins can make the application available in the appropriate self-service center or deploy 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 extensive software requirements, OIT will work with the department in a hybrid manner, utilizing both Software Request Forms and a spreadsheet. Anything that needs to be reviewed by CLM will require the form to be completed, which automatically creates a ticket to track the work and update the requester.

EULAs, PSQ, and free software

Many free applications still have terms and conditions. For example, an app may be free for individuals but not for businesses or schools. Sometimes, an app may be free for individual educational use but not intended for use in a lab environment. This is where knowing the End User License Agreement (EULA) becomes essential. 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 contain suspicious components during testing, 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. In the event of a conflict, the campus security officer will be consulted. If an exception can be made without compromising the endpoint's security, it will be documented and implemented. If an exception cannot be made, OIT will review the request and work with the requester to determine the appropriate 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, suppose a student requires an accommodation for the application. In that case, the requester will be responsible for collaborating with DRS to ensure an accommodation is provided in accordance with ADA guidelines.


 

Glossary of terms

CIC           Confidential Information

CLM         Contract Lifecycle Management

DCSA       Data Confidentiality and Security Addendum

EULA        End User License Agreement

HECVAT    Higher Education Community Vendor Assessment Toolkit

IFB            Invitation for Bid

PII            Personally Identifiable Information

PSQ      Privacy and Security Questionnaire

RFP         Request for Proposal

SOC 2     Service Organization Control Type 2

TC          Terms and Conditions

 

Uploaded Image (Thumbnail)

 

 

 

 

Print Article