/
IT Project Process

IT Project Process

Owned by Esmé Cowles
Jan 28, 2025
2 min read

How to get started?

If you would like to propose an IT project or a project with a significant IT component, please consult with Library IT early in the process to get a sense of the dependencies and impact your project may have. We are happy to help you explore options, evaluate technologies and vendors, and think creatively about ways to achieve your goals.

Please contact Stephanie Ayers or Esmé Cowles for guidance on making a request or proposing a project.

Routine requests and small projects

  • Many routine IT requests should be directed to L-Support:

    • Desktop hardware requests (new desktop/laptop, printer, webcam, etc.)

    • Desktop software requests (Windows/Mac desktop applications or web-based applications, licensed for a small number of Library staff to be used internally)

    • Adding storage or access to server-based storage (e.g., Isilon shares)

  • Software development in existing applications should be directed to the Product Owner of the application and/or the manager of the development team that maintains the application.

  • Digitization projects have a separate proposal process.

Large IT projects

To propose a large IT project, complete a copy of the IT Project Proposal (Draft). This form is appropriate for projects that have a significant IT component and meet one or more of the criteria below:

  • Audience: used by students, faculty, or the public

  • Budget: annual cost exceeding $10,000

  • Sensitive Data: used for managing Restricted or Confidential data, including financial information, student records, personnel records, or patron borrowing records.

  • Operational capacity: creating a new IT service, including locally installing and maintaining commercial or open source server software

  • Software development: creating a new, locally-developed application

Expectations for third-party software

Commercial or open source software that is provided by or hosted by a third-party, particularly if they meet the large project criteria, should be reviewed by the Architecture and Security Review process and contract review (if purchases/licensed):

  • Architecture and Security Review (ASR)

    • Vendors are expected to provide documentation of their security and accessibility practices (HECVAT, SOC-2, VPAT) and participate in the ASR meeting to answer questions from the Information Security Office and OIT staff.

    • If the vendor or project team is unable or unwilling to provide documentation and participate in the ASR meeting, Library IT can consult on alternatives, such as contracting with a service provider to host the software.

  • Contract negotiation

    • Work with Library Finance to coordinate review of contract language with vendors and Procurement.

    • Vendors are expected to mark up Princeton's standard Software Services Agreement (available in the list of standard contracts).

    • Procurement can work with vendors to negotiate a contract based on the vendor's standard contracts, but this typically takes longer.

  • Software development standards

    • Open source software should generally follow our standards for the applications we develop internally. For closed source software, uptime guarantees, update processes, and other things that impact reliability should be covered by the ASR.

    • Software should show evidence of a healthy community, such as activity in Github, discussions in a community mailing list or Slack workspace, community events and training, etc.