Enterprise Applications

LMS Project Workflow

The Division of IT is migrating to a new project intake and management scheme. We are not currently reviewing requests for new projects.

 DLT tracks the following categories of work:

  • Operational tasks typically involve 0-10 hours of work, and will be tracked via TeamDynamix tickets.

  • Projects typically involve 10+ hours of work and/or deep coordination with multiple teams. Operational tasks can be promoted into projects, as needed, or users can submit project requests.

Read below to find out more about our project workflows.

Project Intake

Chart showing project intake process.

Project Request

Once a new project request comes in, a business analyst will prepare a TeamDynamix project request ticket, which can be used to coordinate effort toward requirements gathering.

Once requirements are understood, the analyst will prepare a project scope document which includes the following:

  1. What is the project called?
  2. What is the business need that justifies the project?
  3. Executive summary of the project
  4. Benefits and risks
  5. Projected stakeholders
  6. Projected timeline
  7. How many people does this impact?
  8. How does this prepare us for the future?
  9. Does this make us more efficient?

Advisory Group

Depending on which systems are implicated in the project, the project request will be referred to an advisory group:

  • The LMS Advisory Group discusses projects which affect University learning management systems, such as Blackboard Learn.
  • The Enterprise Training Collab discusses projects which affect University staff and faculty training systems, such as DTS or SumTotal.
  • The DLT department may act as an advisory group for projects which are internal to DLT.

Project Plan

Once the advisory group approves the project request, it will be assigned to a project lead; this may be the business analyst, or another subject matter expert. The project lead will prepare a detailed project plan, identifying stakeholders, timelines, and itemizing action items.

For large-scale projects, an expanded and thorough implementation plan may be required.

Once the project plan is complete, the project's lead can move ahead to development and testing.

Development and Testing

Chart showing project development and testing process.

DLT's development and testing process is designed to maximize system reliability and stability for all users; it is better to delay a project than to risk the integrity of the entire system.

IT Procurement Review

The first step for any development project is to determine if it must go through IT Procurement Review (ITPR). The ITPR process includes reviews from several subject matter experts, including the Information Security department (ISEC) and the Office of Accessible Technology and Services (OATS). These experts may request additional documentation in order to complete their reviews.

If an up-to-date ITPR already covers the new project, there is no need to create a redundant ITPR request.

If an ITPR is created, certain portions of the ITPR must be completed before the project can proceed:

  • DLT will only install a project on staging environments once security review is complete
  • DLT will only proceed to deployment phase once accessibility review is complete
  • Any important notes or exceptions made during the security or accessibility reviews should be added to the project documentation

System Testing

Once necessary ITPR steps are complete, DLT will install the project on a testing environment and conduct system testing:

  • Does the project install correctly?
  • Does the project affect system integrity?

Functional Testing

Once system testing and necessary ITPR steps are complete, DLT will install the project on a staging environment so that functional teams can conduct usability and functionality testing:

  • Does the project work correctly?
  • Does the project meet the business need?
  • Does the project meet the original requestor's need?
  • Are there any areas of the project that may require extra support or documentation?
  • Are there any unexpected issues encountered during use of the project?
  • Does the project rely on any technologies that are nearing end-of-life, such as Adobe Flash?

Once all testing is complete, the project lead can move ahead to deployment.

Documentation and Communication

Before deployment can begin in earnest, the project lead will work with functional teams to ensure that any necessary support materials have been added to relevant knowledge bases and service catalogs. Functional teams may also choose to prepare a communication plan about any new services or changes to existing services.


Chart showing project deployment process


Once testing and documentation are complete, DLT will propose a go-live schedule that will be reviewed by the advisory group.

Request for Change

Once the go-live schedule is approved, DLT will file a TeamDynamix Request for Change ticket (RFC).

Once the RFC is approved by a system-specific Area Change Coordinator (ACC) and the Information Technology Change Advisory Board (CAB), the technical team can proceed with go-live in a production environment.


Once the RFC is approved, DLT will deploy the project on the scheduled date.

Post Mortem

After the project is completed, the advisory group will conduct a post mortem review to discuss any lessons which might be applied to future work.