Project Charter

Yüklə 34,74 Kb.
ölçüsü34,74 Kb.

Project Charter

Request Tracker 4 (RT4) Implementation Project

Lisa Tomalty

Last Updated: 12/17/2013

SharePoint site:

Exchange/connect group: “UW-RT4”,


The implementation of the newest version of Best Practical’s Request Tracker 4 (RT4) system was recommended by the RT Investigation Project (2012-13).

To continue to provide and improve the quality of IT service on campus, the IT Strategic plan and the RT Investigation Project (2012-13) made a number of recommendations. The recommendation to implement RT4 is in line with a number of strategic objectives from the IT Strategic Plan, version 6.4:

  • RM1 "Make the necessary technology infrastructure and resource investments"

    • Investing in helpdesk and staff support technology

  • OC2 "Take a University-wide perspective to IT"

  • OC3 "Build a cohesive knowledgeable IT community across the campus"

    • Enable communication, collaboration

    • Knowledge sharing through requests and knowledge base

  • IP5 "Continuously improve and optimize IT processes, workflow, and platforms"

    • Collaborative, structured approach to improving processes and workflow

  • U1 "Empower the user and optimize the user's experience"

    • Improve responding to requests, allow users to check progress

    • Knowledge base feature would help "build our users' knowledge and capabilities"

The Request Tracker 4 (RT4) Implementation Project will use the results of the RT Investigation Project (2012-13) and input from the IT Best Practices (ITBP) Project (2013-14) to implement Best Practical’s Request Tracker system, version 4.2, in such a way that it will:

  • Continue to provide a reliable system for request tracking

  • Enable processes to improve effectiveness of IT support

    • Regarding processes, the RT4 Implementation Project will be dependent on the ITBP project for direction

      • The ITBP project will make recommendations for IT service and support processes (It was identified in the RT Investigation Project, that some of the issues related to the current RT system are related to processes)

      • As appropriate, where possible, enable workflow and functionality as defined by the ITBP Project, especially service desk operations processes for IT service support

    • Processes to be consistent (e.g. new hire; new laptop)

    • Processes to catch lost tickets (no owner, categorized incorrectly)

  • Meet the most important request tracking needs of the IT areas on campus

  • Enable collaboration between IT areas (and non-IT areas as appropriate)

  • Implement a knowledge base

  • Integrate with the service catalogue (create forms that can be linked to from the IST Service Catalogue, and other service catalogues on campus)

This project will follow a phased approach and implement incremental changes so as to keep the RT system operational and functional throughout the project.

The information contained within this Charter is high level and will be continually expanded and modified in the Project Management Plan for this project. The RT4 Implementation Project Management Plan and other supporting documents will be stored on the RT4 SharePoint site.


The RT4 Implementation Project has the following primary goals:

  1. Work together with IT units on campus to leverage the many benefits of RT4, and enable all IT units on campus to share and collaborate on IT incidents, requests and problems using the RT4 system.

  2. Upgrade the current Request Tracker version 3 system to the most recent Request Tracker version 4 system and:

    1. Install appropriate plug-ins, based on current needs, and needs identified in the RT Investigation Project

    2. Ensure disaster recovery (including backups, failover machine and testing machine) is in place.

  3. Move the existing user request forms into RT4 and ensure usability and accessibility of these forms

  4. Import existing data into the new RT4 system.

  5. Provide clear, simple, consistent training, documentation and communication around the new RT4 system (for users, issue solvers and queue managers)()

  6. Expand use of RT4 system to IT units on campus including the IT units in all of the faculties, Housing, the Library, and any other IT areas who collaborate with the IT units or would like to use the system.

  7. Implement new functionality and configure the new system based on:

    1. Requirement information gathered in the RT Investigation Project (June 2012-June 2013) including:

      1. Knowledge base

      2. Reporting and metrics

      3. Improved search feature (and/or create canned searches)

      4. Automated workflows

    2. Requirements that will come out of the IT Best Practices project (TBA)

    3. Other requirements that are deemed necessary for IT support on campus

  8. Non-IT areas use of the system:

    1. Non-IT areas may use the system. They may or may not be provided with assistance in importing data from other systems into this system.

    2. RT is used by non-IT areas, and the intent is for this to continue; modifications and configuration for non-IT areas will be assessed on a case by case basis and will depend on cost/time as well as keeping RT’s functionality reasonably consistent between areas

  9. Clarity, consistency, transparency, ease of use and simplicity (for users and issues solvers) are end goals to encourage and enable successful use of system.


What is in scope:

  1. The objectives listed above are in scope.

  2. Improve user request forms.

  3. Form an RT administrators group to:

    1. Define standards and procedures for changes and development, including use of change requests

    2. Configure and administer the system and permissions

    3. Develop add-ons that are needed by IT support areas

  4. Develop the Knowledge Base capability including defining permissions and fields for the knowledge base.

  5. Install, configure and assess the SLA module for RT4. Configuration and use of SLA module may vary between queues.

  6. Testing before initial go live date and during incremental changes (system updates, configuration changes, add-ons/development implementation)

  7. RTIR will be installed and configured to work as it does currently.

  8. Follow Best Practical best practices for development to ensure that the project codebase remains compatible with future vendor releases.

What is not in scope:

  1. Writing SLAs.

  2. Importing data for non-IT areas into the system.

  3. Importing data for other IT areas into the system, if deemed too complex.

  4. Developing the system beyond the needs of IT areas on campus

  5. Modification of source code or database structure

  6. Asset Management

  7. Integration with other systems on campus is possible with RT4, but the development/configuration for these integrations is not in scope for this project.

  8. Requirements that require development beyond what is reasonable for the project group (in terms of development time and expertise required)

  9. Requirements will need to be prioritized based on need and impact to IT support on campus.

The RT4 Implementation Project Management Plan outlines the scope of this project in more detail.

Constraints, Assumptions and Risks

Preliminary, known risks and constraints

  1. RT 4.2 is expected to be released in October 2013. Delays in the release will result in delays in the project. Bug fixes and small updates may be needed early on.

  2. Documentation and free support for RT 4.2 may be limited and may impede the progress of the project.

  3. Limited or no budget may result in a slower implementation due to support and consulting not available.

  4. Information from the ITBP project will influence the project’s scope and progression.

  5. The project will require a significant amount of time from the current RT administrators and support staff.

  6. Staff availability:

    1. Staff are very busy, which could affect their ability to participate fully in the project.

    2. Staff resources available for the project may limit the amount of development that can be done

  7. Non project team staff availability for:

    1. Testing system and features for their area before production

    2. Help develop and configure for new workflow, processes (or custom workflow, processes) for their area

    3. Assisting in migrating their request tracking operations into the new RT4 systems

    4. Note: Enabling RT4 to work for some IT areas and to meet their needs may require significant development/configuration time from the project team and/or from the specialized IT area.

  8. A risk register will likely be created and hosted on the RT4 SharePoint site.

Preliminary, known assumptions

  1. Able to engage enough staff to participate fully in the project and assist with development, testing and feedback.

  2. Able to communicate with ITBP project and implement recommended process changes

  3. RT4 can meet the needs of campus IT support, with configuration (and development, in some cases)

  4. There exists sufficient hardware for the system, testing machine, failover machine and backups


  1. IT Best Practices project will make recommendations to this project for workflow, processes, knowledge base, etc.

  2. If RT 4.2’s built in reporting/metrics are not sufficient, reporting/metrics may be dependent on the Cognos 10 Reporting Tool being available (dependent on Cognos EBI environment); expected sandbox in November 2013; expected availability January/February 2014 hopefully. Pam Fluttert is the current contact for this.

  3. Timeline for the project maybe dependent on budget for monthly support from Best Practical.


There is currently a limited budget for this project. As of September 2013, there is no additional guaranteed budget money available for this project.

A budget for support/consulting from Best Practical will be requested. Also see the RT Budget spreadsheet.


The timeline will be included in the RT4 Implementation Project Management Plan.

Start date: Sept 2013

Anticipated end date: Aug 2014


Phase 1A (Nov-Dec 2013)

  • Project planning and documentation

  • Clean up user accounts in RT3

  • Install and configure newest release of RT 4.2 (and version 4.0 if necessary for migration)

  • Configure/activate/use plugins

Phase 1B (Jan-Apr 2014)

Configuration/development/system setup

  • Decide what behaviors of RT should be consistent across queues and what we would expect to be different across queues (e.g. Autoreply email, ticket re-opens on reply, etc.)

  • Configuration/development/system set up

  • Set up versioning in GIT or similar system for development (or this may be moved to Phase 2)

  • Arrange consulting/support from Best Practical as needed

  • Clean up users/groups/queues (names and descriptions)/permissions in 4.2 as needed

  • Develop forms for client interface for clients

  • Set up Reminders in new system (as they are in RT 3.8)

  • Set up feedback forms in new system

  • Other configurations:

    • Ensure initial request information is included in Autoreply email for all

    • In list of users requests: list the most recent request at the top

    • Ticket display: show newest ticket history first (document this and show in training)

  • Disaster planning

  • Accessibility review

  • Security review

  • Spam detection

  • Update theme to identify it as a University of Waterloo site

  • Install and configure RTIR (version 3.2 (hopefully by Dec) to work with RT 4.2)

  • Decide on consistent naming conventions for queues and groups (to implement gradually throughout project, queue by queue basis)


  • Import all data (users/queues/tickets/etc.) into rt-dev for testing on eve before go live date

  • Test system configuration with current workflows

  • Test data migration

  • Request that current queue owners test their processes on RT 4.2 development machine


  • Implement automated process to ensure requests are owned by someone/ some group, soon after submission


  • Ensure permissions are configured to allow collaboration between and within IT groups

  • Make comments internal and not visible to requestors or CCs

Documentation, Training, Communication

  • Document difference between RT3 and RT4 (during setup and implementation) to include in documentation and training

  • Determine timeline for go live

  • Communicate go live date, project plan of phases and available training and documentation to all stakeholders via web site, mail lists, Waterloo Daily Bulletin, etc.

  • Prepare documentation and training for all internal users of RT

  • Prepare documentation and training for requestors

  • Offer training and seminars in advance of go live date

New Features (would be nice to have in Phase 1B):

  • Reporting

  • Workflows

  • Knowledge Base (“Articles” in RT4) –internal/external , self-serve

  • Custom templates (used by scrips for email sent from the system) for different areas

  • Implement first priority requirements from the RT Investigation project

  • Implement first priority requirements from IT Best Practices project

  • Searching: canned searches, improve usability of search interface

  • Recurring tickets: Install the plug-in for scheduling recurring requests

  • Improved time tracking

Phase 2 (May-Aug 2014) (Migrations and Continual Improvement)

  • Plan for go live of new changes

  • User interface for issue solvers

  • Form RT administrators group, for any areas who would like to be more heavily involved in the administration of their queues in the system.

  • Arrange admin training as needed

  • Migrate areas into RT4

  • RT customizations and changes – procedures, where to document differences in queues

  • Revisit requirements from RT Investigation project

  • Implement recommendations from ITBP project

  • Prioritization and escalation

  • Make recommendation for maintaining and keeping RT current (system versions and meeting needs)

  • Plan for ongoing RT updates

  • Training/Documentation for changes

More details on the strategy are included in the RT4 Implementation Project Management Plan.

Resource Roles and Responsibilities

Project Sponsor: CTSC and IST Directors/Management

  • Acts as champion for the project

  • Guides the project through any major business and administrative issues

  • Commits to the allocation of human resources

  • Approves formal project management documents

  • Monitors high level project progress

  • Ensures that project activities are appropriate, cost-justified and effective

Project Management: Lisa Tomalty (0.5 FTE)

  • Prepares project management documents, creates project plan, and manages the entire project from initiation to closure

  • Monitors and controls project

  • Manages execution of project

  • Facilitates meetings with the project team to discuss schedules, conflicts, issues, and risks

  • Enforces proper change control procedures for scope, change requests, and schedule

  • Provides regular status updates/performance reports and escalates issues to Sponsor

  • Supports the project team in all efforts towards this project

  • Plans and ensures quality objectives are met

  • Ensures proper communications amongst team members and other stakeholders

  • Plans for appropriate team member training and team building initiatives

  • Manages budget

  • Works with stakeholders to ensure RT4 will meet their needs

Technical Lead: Jeff Voskamp (0.9 FTE)

  • Take ownership of assigned customizations, configurations

  • Write appropriate documentation in the form of specifications

  • Ensure developed customizations meet all stated requirements, quality standards and work as expected and don’t restrict the ability to upgrade to new versions of Request Tracker

  • Install and assist with configuration of RT4 system

  • Create, install and maintain any development, test and demo environments required for the project

  • Ensure application security requirements are met

  • Ensure technical infrastructure is configured properly for project requirements and meets all quality standards

  • Enforce standards

  • Enforce and participate in change management processes for customizations and configurations

  • Create any required database environments

  • Monitor database and provide database support

  • Perform backups and recoveries

  • Troubleshoot and tune database, if required


  • Learn new technology available through RT4 to provide solutions for requirements identified by the IT Best Practices project and in the RT Investigation project

  • Configure, develop and do initial testing for new requirements implemented on the RT4 development server


  • Perform thorough testing for new requirements implemented on the RT4 development server

  • Perform testing for new requirements immediately after putting into production on the RT4 live server

  • Work with project lead to determine requirements for different areas


  • Assist in documenting new features and procedures for new RT4 system

  • Assist in group or one-on-one training for new RT4 system

Developers and testers will not be backfilled. Their availability to the project will vary, depending on other responsibilities within their departments.


Area: Name


IST: Lisa Tomalty


IST: Jeff Voskamp

Technical lead

CECA: Joe Radman

Configuration, Development, Testing

CEL: Anuja Bajaj

Configuration, Development, Testing

ENG: Mike Hurst

Configuration, Development, Testing

ENV: Mary Burden


Housing/IST: Mike (Hoang) Huynh

Configuration, Development, Testing

Management Sciences: Vu Huynh

Development, testing

IST-IS: Vivienne Ballantyne


Library: Adam Savage

Configuration, Development, Testing

St. Jerome’s: Tait Kelly

Configuration, Testing

MFCF: Lori Suess


Area: Name


CSCF: Lawrence E Folland

Mail list only

IST-IS: Mike Gaspic

Mail list only

IST-Security: Terry Labach or Patrick Matlock

Security Review (will not attend regular meetings)

IST-Security: Mike Paterson

Mail list only

IST-ITMS: Daspina Fefekos

Testing/Requirements; mail list; cannot attend meetings

*Areas not represented on the project will be consulted through their representative on the IT Best Practices project, or a representative from their area. All areas using the RT system will be communicated with regarding upcoming changes, documentation and training.

The amount of time required for participation in this project will vary by area, and will be estimated early in the project. At minimum:

  • October 2013-June 2014:

    • Kick off meeting (2-2.5 hours)

    • 1.5 hour meetings every 2 weeks

    • An additional 1-2 hours every two weeks

    • Additional time, based on

      • Requirements for each team member’s area

      • Amount of configuration, development, testing required for team member’s area

      • Amount of additional configuration/development/testing team member is interested doing


This charter formally authorizes the RT4 Implementation Project, based on the information outlined in this charter. Should any of this information change throughout the duration of the project, it shall be discussed by IST Directors and CTSC members and documented in the “Revision History” section of this charter document.

Approved by: IST Management and Dave Wallace

Approval Date: Oct 21, 2013

Presented to: CTSC

Presented Date:

Presented to: UCIST

Presented Date:

This approval was discussed by IST Management (Oct 21, 2013), CTSC (Nov 14, 2013), UCIST (Nov 22, 2013) in MC2018A, University of Waterloo, and documented at:

  • IST Management:

  • CTSC:

  • UCIST:

Revision History

Revision made by

Revision date

Revision details

Reviewed/approved by

Date reviewed/approved

Yüklə 34,74 Kb.

Dostları ilə paylaş:

Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur © 2022
rəhbərliyinə müraciət

    Ana səhifə