RTM Transferred Scope - Campus Solutions

Purpose: This guide provides an archive record of the portion of requirements outstanding from the ctcLink implementation project.  Of the 2488 original requirements, 250 were transferred to the Project Management Office to review and determine if action is needed.

Audience: All ctcLink system users

Record of Governance Decision

On the May 31, 2022 meeting of the ctcLink project Steering Committee a decision was made to transfer the outstanding scope in the Requirement Traceability Matrix (RTM) for which no record could be confirmed of delivery (requirements met).  Many of these requirements could simply be no longer needed by the college community, but it was determined that the Project Management Office (PMO) team should review those remaining requirements and move them through the Operational Governance model for a final decision.

Minutes from Steering Committee meeting:

Project Scope Transfer to SBCTC PMO:

Christy [Campbell] reviewed the need to transfer to SBCTC IT/PMO the 250 items identified in the RTM that have not been implemented for various reasons. The Steering Committee reviewed the items prior to this meeting.

Tim [Wrye] said he had a conversation with all the voting members in attendance today and everyone agreed they liked this approach as it provides SBCTC the flexibility and opportunity to look at and process these items.

Rich Tomsinski said it’s not unusual to see items transitioned or transferred to Operations at the close of a project.

Project Closeout Agreement with SBCTC IT/PMO: Transfer 250 Of 2488 Requirements from Project Scope:

The final review of the ctcLink Project Requirements Traceability Matrix (RTM) revealed 250 requirements that were either not implemented or partially implemented for various reasons (e.g., colleges don’t use; functionality not needed by the college system; requirement fulfilled with another solution). To close the ctcLink Project by June 30, 2022, the 250 items need to be removed (de-scoped) from the ctcLink Project Investment Plan and transferred to SBCTC IT/PMO for a more in-depth review and assessment of the 250 items as outlined in the RTM Final Request to Descope 250 of 2488 Requirements spreadsheet.

Following transfer of the 250 items to SBCTC IT, the PMO will work with the ctcLink Working Group to review the 250 items and determine which requirements are not needed and which ones need to be addressed as future enhancements and fixes.

Signed by Grant Rodeheaver to certify that the ctcLink Project Sponsor/SBCTC Deputy Executive Director of IT approves the transfer of the 250 items from Project to SBCTC IT/PMO for further review and action by SBCTC PMO and ctcLink. Project Closeout Agreement with SBCTC IT/PMO - Transfer 250 of 2488 Requirements from Project Scope.

ACTION:

Grant [Rodeheaver] moved and Choi [Halladay] seconded the motion, which passed with 7 votes (including Chad Stiteler’s proxy):

• Officially descope from the ctcLink Project the 250 of 2,488 items identified in the RTM and transfer those items to SBCTC IT/PMO for re-evaluation and prioritization by ctcLink governance as outlined in the signed Project Closeout Agreement with SBCTC IT/PMO.

Requirement Details

What is an RFP ID?

The codes that preface the module for each requirement listed below refers to the original Request for Proposals (RFP) identification number (ID) from article number 5 ("A5") of the RFP developed in 2012. (See attached original RFP Response submission from the System Implementation Vendor in 2012.)

 Requirement Definition History
These requirements were developed in 2011-2012 with the guidance of Gartner consulting, who were contracted to aid in requirement definition, drafting of the Request for Proposal (RFP) package and contract negotiation and refinement.  A series of requirement definition workshop sessions were held with broad college participation to react to and refine a stock set of common ERP requirements. The goal of the 2 month long workshop series was to ensure those requirements aligned to the needs of the Washington Community and Technical College system.

Requirement Validation Efforts
After the signing of the contract with the selected vendor, a series of Requirement Validation sessions were held in 2013 to clarify the requirements listed in the RFP. In some cases, college staff turnover was such that the RFP requirements were difficult to articulate an original intent. Some requirements were tabled as non-actionable due to the inability of college Subject Matter Experts (SMEs) to provide the specific need that drove the requirement. This may have been due to college SMEs lack of familiarity with an Enterprise Resource Planning (ERP) system.  Now that colleges have all converted and are actively using the ctcLink system, college SMEs are likely in a better position to determine whether the original requirements speak to current college needs or can be de-scoped.

Requirement De-Scope
Some requirements were de-scoped by project leadership in 2013-2014, but never brought before a governing body for official removal of the requirement from project delivery scope.  These items warrant review and confirmation by the PMO Team and to be brought before Operational Governance for confirmation after a period of college SME review.

College SME Feedback NOW
If upon reading the outstanding requirement list below you feel like you can contribute a perspective on the background or driving need that initiated this requirement please contact the PMO Team.  Keep in mind, the words shown below as the "original requirement text" are in many cases vague or unclear, hence the request for more words from our knowledgeable Subject Matter Experts!

Search Tip! Look to the left for under the Last Updated heading, click the Generate Article PDF. Once it changes to Download Article PDF you can click that link to download this guide in a searchable .pdf format.  This feature will allow you to open this guide in a .pdf reader, with  all folders expanded, for easy search capabilities! Try it!

CS Core
SR164 - Core (Student & Academic Records) [Slated for De-Scope 10/19/2022]

Original Requirement Text:
Create, maintain and interface with email distribution lists.

Reason Cited for Not Implementing During Project:
Per the original signed requirement validation certifications this requirement was recommended for de-scope as our college system does not have a shared email system, therefore there are no global email distribution list to utilize for such a customization. This requirement is recommended to go before operational governance for official de-scope.

Additional Background: Email subgroup formed out of Global Design Review determined a single email system or custom email types per college not feasible due to customizations across pillars that would be required. Emailing may be conducted via delivered 3Cs, Message Center, and/or notifications functionality or outside the system using local tools.

CR1 - Core (Course Scheduling & Registration) [Requirement Clarification Needed]

Original Requirement Text:
Manage and track user-defined, multi-step course and program development and "sunset" process (e.g., initiate, admin next step, committee deliberation, VP Instructions, State), including but not limited to tracking required components, creation of forms, approval workflow and attachment of required documentation.

Reason Cited for Not Implementing During Project:
System Implementation vendor defined this requirement as a modification with the addition of an approval workflow and noted it was a highly complex customization on December 2012.  There is evidence of activity during the requirement validation work with the system implementation vendor, where college input appears to refer to specific types of courses that must be incorporated in a solution: "Enable the configuration of experimental courses and waive course approval requirements for them based on user-configurable expiration dates (currently set at one year) and other user-defined criteria."  There is no decision log entry reflecting a recorded leadership decision to de-scope the requirement, but it is assumed that some agreement was undertaken with the vendor to de-scope the requirement as it was removed from all future CEMLI work lists and the RTM last provided by the vendor on July 2016 stated it was still a customization, but lacked any reference to M-184, the CEMLI assigned in 2012. Recommend verify with colleges today to determine if there is value in this requirement, or if all colleges are using third party products that satisfy this need.

CR46 - Core  (Course Scheduling & Registration) - [Slated for De-Scope 11/16/2022]

Original Requirement Text:
Provide the ability to create shared course catalog listings between colleges in support of Washington Online college.

Reason Cited for Not Implementing During Project:
Washington Online (WAOL) descoped. WAOL courses and classes are managed using delivered functionality. WAOL classes are designated with the Instruction Mode WA.

CR70 - Core (Course Scheduling & Registration) - [Slated for De-Scope 11/16/2022]

Original Requirement Text:

Support for cross-college pooled enrollments for Washington Online college.

Reason Cited for Not Implementing During Project:

Washington Online (WAOL) de-scoped. WAOL courses and classes are managed using delivered functionality. WAOL classes are designated with the Instruction Mode WA.

CR112 - Core (Course Scheduling & Registration) - [Slated for De-Scope 11/16/2022]

Original Requirement Text:

Allow the use of 'pass-codes' to manage reserved seats in registration into a section in support of Washington Online college.

Reason Cited for Not Implementing During Project:

Washington Online (WAOL) de-scoped. WAOL courses and classes are managed using delivered functionality. WAOL classes are designated with the Instruction Mode WA.

CR113 - Core (Course Scheduling & Registration) - [Slated for De-Scope 11/16/2022]

Original Requirement Text:

Allow cross-college registration into section to support Washington Online college's shared course functionality.

Reason Cited for Not Implementing During Project:

Washington Online (WAOL) descoped. WAOL courses and classes are managed using delivered functionality. WAOL classes are designated with the Instruction Mode WA.

CR114 - Core (Course Scheduling & Registration)[Requirement Clarification Needed]

Original Requirement Text:

Allow third party access to authorized accounts to permit bulk registration by an external party (e.g. contract or continuing education).

Reason Cited for Not Implementing During Project:
System Implementation vendor's original RFP response stated that this functionality was delivered (out of the box); however during the Requirement Validation activity in March/April 2013 the vendor stated that this was not current functionality within PeopleSoft and that in legacy colleges received a list of students to enroll from the third party. It was determined to be a 'Wish List' item during the requirement validation certification.  The requirement was never officially de-scoped.  Since that time, there have been observations that granting external party bulk load access might not be in the best interest for FERPA or Security reasons.  It is recommended that this requirement reviewed by the colleges and a determination be made to either take action or de-scope through operational governance.

SS65 - Core (Student Services) - [Requirement Clarification Needed]

Original Requirement Text:
Generate reports based on user-defined criteria, including but not limited to: Perkins Loans (Service)

Reason Cited for Not Implementing During Project:
At the time of the System Implementation vendor requirement validation discussions the college feedback was that only 4 colleges that award Perkins, 3 of them have less than 100 per year.  The vendor, in discussions with the Project Leadership Team at that time determined that the setup and maintenance outweighs the benefit of automating the process.  A Decision Log entry (#29) was recorded to de-scope the requirement.  This requirement de-scope decision was never brought before an official governance process and therefore it is recommended that college feedback be requested to confirm the decision and IF the colleges concur with the choice, only then would an official de-scope request be submitted for approval by Operation Governance.

Additional Note: This may need to be re-categorized under the Financial Aid section.

Room Scheduling (25Live)
RS3 - 25Live (Room Scheduling) - [Slated for De-Scope 10/5/2022]

Original Requirement Text:
Provide visibility of room inventory across colleges.

Reason Cited for Not Implementing During Project:
Each college has a stand-alone 25Live instance, therefore there is not capabilities for cross-college room inventory visibility. It is recommended to de-scope this requirement, as colleges did not opt for a single, shared instance of 25Live.

RS36 - 25Live (Room Scheduling) - [Slated for De-Scope 10/5/2022]

Original Requirement Text:

Provide room change updates to students via different communication modes (e.g., e-mail, text message).

Reason Cited for Not Implementing During Project:

Communications to students are managed through Campus Solutions, not 25Live.  It is recommended to de-scope this requirement, as colleges are not utilizing 25Live as their method for student logistics communication.

RS38 - 25Live (Room Scheduling) - [Slated for De-Scope 10/5/2022]

Original Requirement Text:

Incorporate room location logistics in communications.

Reason Cited for Not Implementing During Project:

Room logistics, such as whether a room meets accessibility requirements or has A/V equipment is an element of the scheduling software and colleges use this software to manage room scheduling. Communications to students are managed through Campus Solutions, not 25Live.  It is recommended to de-scope this requirement, as colleges are not utilizing 25Live as their method for student logistics communication.

Financial Aid
RA106 - Financial Aid (Recruiting & Admissions) - [Slated for De-Scope]

Original Requirement Text:
Support on-line financial assistance estimator tool to provide potential applicants the ability to estimate how much financial aid they would receive

Reason Cited for Not Implementing During Project:
System Implementation vendor modified the requirement from Recruiting and Admissions to Financial Aid module.  Then SI and original Project Leadership Team negotiated a decision to de-scope this requirement, citing "Changed from CEMLI - FA will setup and support the Federal  Government's Online Net Price Calculator (NPC). Data is coming from the IPEDS Institutional Research (IR) data analysis.  Each college will provide a link to the NPC on their website." Captured in Remediation Ticket 21203. Decision was not formally approved through governance. Recommendation is to de-scope this requirement through Operational Governance.

SR112 - Financial Aid (Student & Academic Records) - [Believe Requirement Satisfied]

Original Requirement Text:
Load potential award recipient data from admissions.

Reason Cited for Not Implementing During Project:
This requirement was unintentionally marked for scope transfer, but was in fact deemed satisfied during the remediation process. Listen and Learn feedback recorded that the requirement no longer has a gap with business requirement per Remediation Service Desk Ticket # 20885.

FA7 - Financial Aid - [Slated for De-Scope 10/5/2022]

Original Requirement Text:
Verify post-graduation employment to determine or monitor continued aid eligibility.

Reason Cited for Not Implementing During Project:

The System Implementation vendor, at the time of the Requirement Validation activity recorded the clarification of this requirement as having been included by Gartner Consulting and should have been removed prior to distribution of the Request for Proposals (RFP).  The requirement related to the days when certain health care programs required long term employment monitoring to determine if a grant award must be reverted to a loan when employment requirements were not met. Requirement was intended to be de-scoped, but did not go through a formal governance process. Captured in Remediation Ticket 20817. Recommendation is to seek a scope reduction for this requirement through Operational Governance.

FA62 - Financial Aid - [Slated for De-Scope 10/5/2022]

Original Requirement Text:
Generate Perkins notes and disclosures and capture dated comments for entrance and exit interviews for Direct Loan programs.

Reason Cited for Not Implementing During Project:
At the time of Remediation, it was determined that the majority of colleges ceased offering the Perkins Loan program due to the overhead.  At that time (2017-18) only 3 colleges still offered this program.  If there are colleges still offering this program and their system is not configured to support their ability to deliver the program then a discussion on whether to deliver this configuration is warranted.  Captured in Remediation Ticket  20828.

***Updated note as of 9/21/22:

IMPORTANT: Under federal law, the authority for schools to make new Perkins Loans ended on September 30, 2017, and final disbursements were permitted through June 30, 2018. As a result, students can no longer receive Perkins Loans. A borrower who received a Perkins Loan can more about managing the repayment of the loan by contacting either the school that made the loan or the schools loan servicer.

FA64 - Financial Aid - [Requirement Satisfied]

Original Requirement Text:
Print Direct Loan promissory notes according to federal standards.

Reason Cited for Not Implementing During Project:
As a result of FA WebEx Listen and Learn Session on Pell Grant and Direct  Loan Processing, all 3 FirstLink Colleges indicated there was no longer a gap with this business requirement. Remediation Ticket 20853 to Resolved. All reference materials for Financial Aid Loans are available in the ctcLink Reference Center.

SS41 - Financial Aid - [Slated for De-Scope 10/5/2022]

Original Requirement Text:
Establish scholarship fund based on user-defined business rules.

Reason Cited for Not Implementing During Project:
The System Implementation vendor, at the time of the Requirement Validation activity recorded the clarification of this requirement as "Creation of scholarships by any donor according to their eligibility requirements." Vendor stated that this requirement could be met with the purchase of the Scholarship module.  The original Project Leadership Team deliberated on the cost for the additional purchase and finally determined that the project would not pursue the extra software licensing purchase. Decision Log entry (#243) verbiage is captured in the response to RFP ID SS44.

Captured in Remediation Ticket 21447. Decision was not formally approved through governance. Recommendation is to seek a scope reduction for this requirement through Operational Governance.

SS42 - Student Services (Financial Aid) - [Slated for Scope Reduction 10/5/2022]

Original Requirement Text:
Provide online application and processing for scholarship funds based on user-defined business rules.

Reason Cited for Not Implementing During Project:
System Implementation vendor and original Project Leadership Team negotiated a decision to reduce the scope of this requirement, citing "Online application" portion of requirement has been de-scoped on 6/13/14.  "Processing for scholarship funds...." is met by FA Item Type setup and  usage.                            

Captured in Remediation Ticket 21411. Decision was not formally approved through governance. Recommendation is to seek a scope reduction for this requirement through Operational Governance.

SS44 - Student Services (Financial Aid) - [Slated for De-Scope 10/5/2022]

Original Requirement Text:
Track requirements of scholarships based on user-defined criteria (e.g., academic performance; refund policies; types of courses; expiration period; and reports to donor)

Reason Cited for Not Implementing During Project:
System Implementation vendor and original Project Leadership Team negotiated a decision to de-scope this requirement, citing Decision Log entry (#243) regarding de-Scope of CEMLI E-061, which states:

The reasons for de-scoping are as follows:

  1. Managing awards can be handled through External Award load.
  2. Managing disbursements based on many user-defined criteria will be handled through FA Item Type and Disbursement Rules setup.
    1. User-defined criteria that cannot be managed through setup can be managed through business processes; continued processes from legacy OR user-developed queries in PS to identify and monitor students by item type.
    2. Monitoring for continued eligibility will be captured during the SAP setup and processing since many colleges run SAP for most/all of the scholarships.

We are deciding not to deliver PS queries for 2a because the selection criteria are very broad with the large number of scholarships throughout our system (or even amongst  FirstLink Colleges). We would like to leave it to the colleges to decide, post go-live, if they feel the queries are necessary.

If this decision is executed, in lieu of CEMLI development and solutioning, we can provide the colleges with delivered business process solutions to tracking and managing scholarships.

Captured in Remediation Ticket 21455. Decision was not formally approved through governance. Recommendation is to de-scope this requirement through Operational Governance.

Student Financials
SR135 - Student Financials (Student & Academic Records) [Requirement Clarification Needed]

Original Requirement Text:

Allow payment on-line for transcripts.

Reason Cited for Not Implementing During Project:

This issue will be impacted heavily by the pending contract with TouchNET.  

Currently, ctcLink does have the ability to have students select from a collection of charges via the current Student Self Service.  This feature does not allow for the additional entry of substantial data which would be required for a transcript order, however.

Additional Note: The SF Support team thinks this request should be delayed until more is known regarding TouchNET.

SF4 - Student Financials [Requirement Clarification Needed]

Original Requirement Text:
Create and maintain accounts for prospective students to manage application fees and other pre-enrollment fees, including refundable student deposits. This is an auto account created based on specific charge types.

Reason Cited for Not Implementing During Project:
The SF Team’s current understanding is that payment is necessary prior to application submittal. More research on “prospective” ID's would be necessary.

Additional Note:  Auto build for student ID's could be risky. The SF Support team thinks this task would be a substantial undertaking, most possibly involving a third-party application system like OAAP. Again, the issue of TouchNET comes into play.

SF31 - Student Financials [Requirement Clarification Needed]

Original Requirement Text:

Charge all fees through student accounts.

Reason Cited for Not Implementing During Project:

During the system implementation vendor's requirement validation activity it was determined that this requirement was drafted to specifically ensure that even non-class enrollment related charges could be paid for and visible on the student account, (for example payment of Parking Fines, Library Fines, Bus Pass or Small Equipment Rental Fees.)

In ctcLink currently, all tuition and mandatory fees are charged through the student account. ctcLink does have multiple avenues for posting charges and payments, such as Group Posting for Library Fines. It is recommended that this requirement be considered as satisfied, and college feedback can confirm.

Additional Note: ctcLink does have multiple avenues for posting charges and payments. We would need additional needs built into this requirement to make a sound judgment as to its feasibility.

SF55 - Student Financials [Requirement Clarification Needed]

Original Requirement Text:

Calculate and assess interest charges.

Reason Cited for Not Implementing During Project:

During the system implementation vendor's requirement validation activity it was determined that this requirement was a desire to calculate a percentage based late fee.  It is recommended that colleges review this requirement and determine whether this is still desired functionality.  If so, concrete and actionable requirement details are needed to proceed. In addition, SBCTC Business Operation division regarding RCW’s and WAC’s is also recommended to ensure any solution approach aligns to state and federal regulations. If no longer needed, then a recommendation to de-scope the requirement through a formal operational governance process would be the appropriate path.

Additional Note: The SF Support team is prepared to take on this requirement as an enhancement and has experience implementing interest charges. We would like to have additional consideration and direction from the SBCTC Business Operation division regarding RCW’s and WAC’s.

SF78 - Student Financials [Believe Requirement Satisfied]

Original Requirement Text:

Access a complete history of adjustments and conditions at the time of disbursement.

Reason Cited for Not Implementing During Project:

This requirement was unintentionally marked for scope transfer, but was in fact deemed satisfied during the remediation process. The requirement no longer has a gap with business requirement per Remediation Service Desk Ticket # 21450 date of 2/15/2017. The following QRG is listed in the ticket: http://ctclinkreferencecenter.ctclink.us/m/56655/l/623204-view-customer-accounts

SF80 - Student Financials [Requirement Clarification Needed from FA]

Original Requirement Text:
Support "what if" scenarios for student to identify impacts on financial aid of proposed registration changes.

Reason Cited for Not Implementing During Project:
System Implementation Vendor and former Project Leadership Team determined that the customization needed to respond to this requirement was overly complex.  Decision Log entry #226 reflects their decision to de-scope CEMLI E-179 due to reasons cited below; however no formal governance decision was recorded. Seeking college feedback prior to submitting this requirement for de-scope to confirm whether a less complex approach could satisfy the requirement.

For context in 2011, during the requirement gathering sessions the requirement was determined to be 'Student Financials' related because of the common order of student drop behavior:

  • Students would appear at the 'Cashier' window asking to drop a class.
  • Cashier would direct the student to the Registration desk.
  • Registration staff would note that the student was a 'Financial Aid' student and direct the student to Financial Aid Office.
  • Student would go to FA to discuss the implications of their choice to drop from a class prior to actually dropping from the class.  
  • At the Financial Aid Office, they would help the student understand whether this drop would cause the student to be:
    • On FA Probation or terminated from aid
    • Drop in enrollment would reduce their aid amount eligibility causing a need for additional payments
    • Timing of a student's drop in enrollment would trigger an R2T4 calculation (student would owe money or would receive a partial refund)

The requirement was an attempt to automate the decision repercussions when student enrollments were now to occur fully online. The complexity involved in this requirement would have required the system implementation vendor to develop a highly complex extension to address all the possible 'What If's' in the scenario detailed above.

SF92 - Student Financials [Requirement Clarification Needed]

Original Requirement Text:

Allow parental access to student accounts in accordance with FERPA regulations.

Reason Cited for Not Implementing During Project:

College requirements were not clear and aligned to configure global functionality.

Additional Note: This requirement will be impacted by the TouchNET acquisition.  The SF Support team is not aware that ctcLink has this possibility as a baseline process. If it could happen, it may be associated with the relationship table and building a custom view/table (which would be a humongous undertaking.)

SF103 - Student Financials [Requirement Clarification Needed]

Original Requirement Text:

Support processing and reporting requirements for out of state on-line students in compliance with interstate agreements (e.g., State of Washington with State of California) and other user-defined criteria.

Reason Cited for Not Implementing During Project:

Not sure what these requirements are, but Residency is determined for the student.

Additional Note: The SF Support team believe this requirement to be a data reporting/warehouse issue. This requirement would need additional detail and clarification to properly disseminate next best steps.

Currently, ctcLink does have established processes regarding border or western exchange type setup, utilizing scholarships and/or waivers.

AR49 - Student Financials [Requirement Clarification Needed]

Original Requirement Text:

Support the transmission of past due A6 / Accounts and data to collections agencies based on user-defined criteria/ data (e.g., student contact information; description of debt).

Reason Cited for Not Implementing During Project:

College requirements were not clear and aligned to configure global functionality.

Additional Note: We do not have 100% of the CTC’s utilizing the collections module in ctcLink. That is the first step necessary to begin developing the second step of assigning students to third party collection agencies. The current recommended procedure for student’s being assigned to 3rd Party Collection agency is to simply have a service indicator assigned (which is also PeopleSoft’s recommended process). It is necessary for a CTC staff member to analyze each account prior to being assigned to a third party collection agency.

CR19 - Student Financials (Course Scheduling & Registration) [Requirement Clarification Needed]

Original Requirement Text:

Track cash receipts by origin (e.g., college, department, service, bank account) and by destination (e.g., bank account).

Reason Cited for Not Implementing During Project:

College requirements were not clear and aligned to configure global functionality.

Additional Note: This requirement is vague in nature and speaks to ctcLinks baseline item type ability to organize charges and payments by chart strings (accounting information). Additional configurations are needed between the Finance and CS Pillar to iron out a best practice.

CR21 - Student Financials (Course Scheduling & Registration) [Slated for De-Scope 10/19/2022]

Original Requirement Text:

Support integration with bank lockbox functionality.

Reason Cited for Not Implementing During Project:

At this time no college has identified that they are using or are planning to use a lockbox, so I think that it can be recommended to be de-scoped.

Working Group De-Scope Meeting Schedule

Requirements that have been recommended for de-scope are scheduled to go before the Working Group for their review and decision.  If a requirement slated for de-scope is of concern to a SME, please reach out to the PMO to express the concerns prior to the planned de-scope discussion date so these views can be included in the discussion of Working Group before any decisions are made.

 October 5th, 2022

October 19th, 2022

November 2nd, 2022

November 16th, 2022

December 7th, 2022

December 21st, 2022

January 4th, 2023

January 18th, 2023

February 1st, 2023

February 15th, 2023

March 1st, 2023

March 15th, 2023

April 5th, 2023

April 19th, 2023

PMO Team Contact Information

If you see an original RFP Requirement and feel you have insights to contribute, please feel free to reach out to the PMO Team via email and share your input:

Tara Keen - Director Project Management Office - [email protected]
Amy MacNeill - Project Coordinator - [email protected]
Bhuvana Samraj - Technical Project Manager - [email protected]
Christyanna Dawson - Project Manager - [email protected]
Reuth Kim - Project Manager - [email protected]
Sanjiv Bhagat - Project Manager - [email protected]

What is a Requirement Traceability Matrix (RTM)?

A Requirement Traceability Matrix (RTM) provides a means to connect a set of requirements to the project artifacts used to:

  • Clarify details associated to a requirement, either by system users or a vendor partner
  • Document how the requirement will be or was tested.
  • Train users on using the system to meet each requirement.
  • Denotes whether a customization was needed to satisfy the  requirement and connects to information associated with that  customization.
  • Cite any issues related to the requirement.

The RTM is used to prove that requirements have been fulfilled. In the case of the ctcLink implementation project, remaining requirements that could not be verified as having been either officially de-scoped or implemented were transferred to the PMO Team for review to ensure the proper action has been taken.

0 Comments

Add your comment

E-Mail me when someone replies to this comment

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.