RTM Transferred Scope - Finance
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
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!
Not sure where to start? Begin by reviewing the requirements slated for de-scope, based on the schedule they will be taken to governance for official decisions. Then scan those that are marked as satisfied and let the PMO Team know if you don't feel they are satisfied. Last, if you see an item that needs requirement clarification, let the PMO Team know what you know on that topic. Also, be prepared to participate in the College Collaboration Group discussions on those topics as we work to solidify those requirements for action.
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!
Original Requirement Text:
Supports foreign and domestic vendors with the Accounts Payable recorded in user-defined currency of Vendor (e.g., reports cost in invoiced currency amount and extended U.S. dollar amount with exchange rate in effect at the time of the transaction).
Reason Cited for Not Implementing During Project:
At the time of configuration during the implementation phase US currency was the only currency format requested. While the system can support other currencies, no others were configured. Unless a college comes back during this review phase and cites a need for another currency, the PMO Team will consider this requirement met. Moving forward, if a college should need an adjustment to their configuration, a service deck ticket would be the method for that request.
OFFICIALLY DE-SCOPED 10/19/2022
Original Requirement Text:
Enable merging of duplicate Vendor Accounts based on user-defined business rules.
Reason Cited for Not Implementing During Project:
This functionality does not exist within the delivered product, nor is there a means by which a merge tool could be developed. This requirement was inaccurately responded to by the System Implementation vendor and should have been marked for de-scope by governance. This RFP ID will be brought to the Operational Governance for de-scope.
Per Oracle Support:
PeopleSoft Financials/Supply Chain does not have a tool or feature to merge vendor / supplier records and relate all the transactions to the resulting merged entity.
One supplier vendor would be inactivated and the relevant information would need to be added to Below is a very high-level list of considerations for merging two vendors / suppliers in PeopleSoft:
- All configuration related to existing "Supplier A", "Supplier B", would need to be manually merged into a new "Supplier C"; and "Supplier C" would need to be related to all PO, AP and Inventory Business Units.
- In Purchasing, all open Requisitions, open Purchase Orders (PO), open Change Orders to existing POs would need to be related to the new "Supplier C" vendor. Additionally, all receipt accruals (received but not vouchered) would need to be related to the new "Supplier C" vendor.
- In Accounts Payable, all 'open' and 'in process' vouchers and 'open' and 'in process' payments would need to be related to the new "Supplier C" vendor.
- For reporting, it would be recommended to devise a Query which reports on supplier A, supplier B, and merged supplier C to confirm all transactional activity has been aligned to the new merged vendor.
NOTE: Oracle Support would not be able to provide detailed tasks, sequence of tasks, nor test plans - this would need to be done by customer.
Original Requirement Text:
Support the ability to match expense report line items to uploaded procurement card and credit card statements.
Reason Cited for Not Implementing During Project:
Procurement card usage is not currently enabled within Expenses module, as this feature (referred to as "My Wallet") was not originally configured by the System Implementation vendor. More work is needed to analyze the global and local divisions within this functional area and college input will be needed to determine if this requirement is still desired once all options and fully understood.
Original Requirement Text:
Configure and maintain criteria such as user-specified rules, amount thresholds, and merchant category codes (MCC) to identify, flag, and prevent unauthorized procurement and payment processing.
Reason Cited for Not Implementing During Project:
This is a manual process to dispute a charge, therefore the functionality exists, but further conversions are needed with colleges to understand whether this requirement was fully satisfied.
OFFICIALLY DE-SCOPED 10/19/2022
Original Requirement Text:
Support the use of lockbox functionality.
Reason Cited for Not Implementing During Project:
No College is currently using a lockbox.
Original Requirement Text:
Enable users to reverse receipts and receipt application.
Reason Cited for Not Implementing During Project:
This requirement will need additional clarification from college resources before it can be determined whether this requirement remains unfulfilled.
Original Requirement Text:
Enable users to assess late fees, penalties, or other sanctions against customers both manually on an ad hoc basis and automatically based on user-configurable business rules.
Reason Cited for Not Implementing During Project:
This requirement will need additional clarification from college resources before it can be determined whether this requirement remains unfulfilled.
Original Requirement Text:
Allow customers to access their account records online and have the ability to select charges and make payment, as well as access to their account history.
Reason Cited for Not Implementing During Project:
This requirement will need additional clarification from college resources before it can be determined whether this requirement remains unfulfilled.
OFFICIALLY DE-SCOPED 10/19/2022
Original Requirement Text:
Enable users to view archived transactions.
Reason Cited for Not Implementing During Project:
Not a current function in Finance as there is no archiving on transactions in the ctcLink system at this time.
Original Requirement Text:
Enable users to distribute funds and trust awards manually to external organizations based on organization policies and disbursement schedules.
Reason Cited for Not Implementing During Project:
System Implementation vendor stated that this functionality is delivered within the Cash Management module. CM does provide the ability to distribute funds to external organizations. Need college feedback on whether this requirement is satisfied with the delivered functionality.
Original Requirement Text:
Establish interest accrual and allocation schedules based on user-configurable business rules (e.g., trusts and endowment allocations for spending).
Reason Cited for Not Implementing During Project:
This requirement will need additional clarification from college resources before it can be determined whether this requirement remains unfulfilled.
Original Requirement Text:
Allocate interest earnings to the appropriate organization, trust, endowment, unitization, etc., based on any combination of fund source, fund owner, criteria, user-configurable allocation formulas, date ranges, other relevant criteria.
Reason Cited for Not Implementing During Project:
This requirement will need additional clarification from college resources before it can be determined whether this requirement remains unfulfilled.
Original Requirement Text:
Track and maintain interest allocations by date, owner, fund source, and other user-specified criteria.
Reason Cited for Not Implementing During Project:
This requirement will needs additional clarification from college resources before it can be determined whether this requirement remains unfulfilled.
Original Requirement Text:
Inquire on, view, and drill down on interest earnings and allocation by fund source, bank account, fund owner(s), and other user-specified criteria.
Reason Cited for Not Implementing During Project:
This requirement will require additional clarification from college resources before it can be determined whether this requirement remains unfulfilled.
Original Requirement Text:
Generate interest management reports detailing earnings and allocations by multiple user-specified criteria.
Reason Cited for Not Implementing During Project:
This requirement will needs additional clarification from college resources before it can be determined whether this requirement remains unfulfilled.
Original Requirement Text:
Maintain and track contract payment history and reflect the changing value of the required retainage, based on user-defined criteria.
[Retainage is a portion of the agreed upon contract price deliberately withheld until the work is substantially complete, also referred to as a Hold Back.]
Reason Cited for Not Implementing During Project:
Original System Implementation vendor determined at RFP response time that this requirement was met with delivered functionality in the Purchasing module. In PeopleSoft, you can create a voucher withholding a portion of the gross payment as retainage. Retainage is the percentage of a amount that is held until a specified date. For example, you pay the retained amount after the completion of the contract, service, or receipt of all items on an order. Need confirmation from college users that this requirement is satisfied with the delivered functionality in PeopleSoft.
Linking Oracle delivered documentation on this process as a general concept reference:
Original Requirement Text:
Define retainage percentage and perform the retainage calculation for contracts.
Reason Cited for Not Implementing During Project:
See response for RFP ID - CO59.
Original Requirement Text:
Distribute and report labor costs based on user-defined criteria, with full integration and reconciliation of data between GL, Payroll, and Student.
Reason Cited for Not Implementing During Project:
The Payroll process generates HR Accounting Lines to distribute labor costs to the specified cost centers entered in the Job Data record. This data at the time of payroll flows to the General Ledger for all payroll expenditures, including the expenditures attributed to benefits. For student labors cost, this same process applies, and further a Workstudy reconciliation process is available to the colleges to reconcile financial aid workstudy awards to the payroll expenditures. The outstanding element of this requirement is whether there are any additional 'user-defined' criteria not yet accounted for in a distribution or reconciliation process. Work must be done to clearly define any remaining 'user-defined' outstanding requirements to confirm the fulfillment of this requirement with the Business Operations division that reconciles centralized payroll processing.
Original Requirement Text:
Automatically generate user notifications for all journal processing violations.
Reason Cited for Not Implementing During Project:
Journal Edits errors and budget check errors displayed online with errors on the journal. Need confirmation that the delivered form of user notification satisfies this requirement.
Original Requirement Text:
Track hours expended for all grants by organizational unit, pay period, employee, account number and other user-defined criteria.
Reason Cited for Not Implementing During Project:
Numerous efforts were made during the implementation phase of the project to define a complete set of requirements for Time and Effort reporting; however each effort resulted in conflicting requirements that lead Subject Matter Experts to conclude that a solution was not achievable with the given understanding of ctcLink. Currently there is no Time and Effort reporting customization; however an effort will be undertaken again now that all colleges are on ctcLink to attempt to establish a complete and non-conflicting set of actionable requirements to meet the need outlined above.
Original Requirement Text:
Generate advance notifications of grant end dates, by user-defined process (e.g., prompt at point of user transaction; report), based on user-defined criteria, including but not limited to:
- Encumbrance Availability Date
- Grant End Date
- Grant Extension Date(s)
- Contract End Date
- Other
Reason Cited for Not Implementing During Project:
There currently is no advance notification process in ctcLink. More input from colleges is needed to establish clear and actionable requirements for all references to 'user-defined' and 'other'.
OFFICIALLY DE-SCOPED 1/18/2023
Original Requirement Text:
Generate grant/sub-grant detail transaction reports, based on user-defined time period (e.g., month, quarterly, YTD, inception-to-date), based on user-defined criteria, including but not limited to: Students/ Courses Funded by Grant
Reason Cited for Not Implementing During Project:
Student and Course information and associated detailed expenditures does not exist in the Grants module. The GL records transaction summary level data, but detail level data for students only exist in the Student Financials module in the Campus Solutions pillar. At RFP response, the system implementation vendor mistakenly responded that this capability was configurable, however No Student or Course data exists in the Grants module.
Original Requirement Text:
Provide the ability by authorized users to override appropriation control, and to track/review transactions which occur due to override.
Reason Cited for Not Implementing During Project:
Appropriation is a combo Edit rule, which you can't override. System is not capable of meeting this requirement.
This requirement relates to the prior requirement - BD141 "Reconcile allocations and appropriations, to monitor allocations levels versus appropriation levels, based on user-defined criteria (e.g., type of appropriation; general fund versus federal funds), to restrict release of allocations until final appropriation authority is approved." The requirement in RFP ID BD141 was to restrict the release of funds until the final appropriation authority is approved and the requirement in BD142 is to allow the user to ignore the restriction regardless of final approval.
This requirement must be reviewed for appropriateness by the Business Operations division and if not allowed, should be de-scoped by operational governance.
Original Requirement Text:
Compare authorized allocation authority to actual expenditures, based on user-defined criteria (e.g., by project; by any level provided by budget detail).
Reason Cited for Not Implementing During Project:
A comparison report has been developed that reconciles budget (allocations) entered into Commitment Control (KK) vs. the actual expenditures recorded in the General Ledger. Clarification is needed for the term "authorized allocation authority" before any action can be taken to fulfill this request or confirm that the requirement has been met. College input is needed to define the verbiage and confirm a solution approach is still needed.
Original Requirement Text:
Define multiple document approval stages and track a record of the budget at each user-defined stage.
Reason Cited for Not Implementing During Project:
This is advance Out of box functionality which is deferred to PBCS stabilization stage.
Original Requirement Text:
Identify and distinguish federal and state funding sources, and to support the authorization process for receipt of federal funds, based on user-defined criteria (e.g., by program, by project).
Reason Cited for Not Implementing During Project:
This will be analyzed in Stabilization period.
Original Requirement Text:
Record audit trail information (including user ID) when changes are made to budget information within a stage of the budget development cycle, including notations for reason for change, based on user-defined parameters (e.g., by department, by version).
Reason Cited for Not Implementing During Project:
This will be analyzed in Stabilization period.
Original Requirement Text:
Record audit trail information when information is moved from one stage of the budget development cycle to another stage, based on user-defined parameters (e.g., by department, by version).
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Include and/or exclude Accounts or budget items from the rollover process, and to specify amounts to roll over, based on user-defined criteria.
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Track requested, recommended and approved budget, and decision level, with the ability to rollover data from one budget version/stage to the next budget version/stage.
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Approve changes to the budgeted amounts in any budget version (e.g., development budgets, enacted budget), based on a user-defined process and audit trail.
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Provide budgeting capabilities, identifying and maintaining information related to positions including, but not limited to:
- Effective date of any action (e.g., date created)
- Grant Number
- Grant Status (Position Paid By Grant/ By Match)
- Position status (e.g., vacant)
- Position Location
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work. See RFP ID BD116 for clarity on Position Budgeting feasibility.
Original Requirement Text:
Track and summarize positions based on any user-defined stage in the budget process and on any level within the organizational structure, based on user-defined criteria.
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work. See RFP ID BD116 for clarity on Position Budgeting feasibility.
Original Requirement Text:
Reconcile position control with personnel records from the HR System.
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work. During design phase it is determined that Position budgeting can not be done in this phase because ctcLink doesn't have position management.
Original Requirement Text:
Provide a fully featured function for benefit and associated expense calculation based on user-defined criteria relevant to position attributes, incumbent employee attributes, and vacancy projections.
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work. See RFP ID BD116 for clarity on Position Budgeting feasibility.
Original Requirement Text:
Real-time access and updates (to salary, pay differentials, recruitment and retention bonuses, and fringe benefits) relative to positions and its attributes, by user-defined criteria (e.g., bargaining unit, classification, location, program).
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work. See RFP ID BD116 for clarity on Position Budgeting feasibility.
Original Requirement Text:
Project budgeted and adjusted salary and benefit projection (from YTD actuals or known pending adjustments) based on positions and other user-defined parameters.
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work. See RFP ID BD116 for clarity on Position Budgeting feasibility.
Original Requirement Text:
Report on budgeted versus actual personnel expenditures, including but not limited to overtime expenditures, based on user-defined parameters.
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work. See RFP ID BD116 for clarity on Position Budgeting feasibility.
Original Requirement Text:
Determine/calculate position counts, full time equivalents, employee counts, and automatically adjust the counts when position changes and employee changes occur, based on user-defined parameters (e.g., by organizational unit, by fund, and by bargaining unit).
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work. See RFP ID BD116 for clarity on Position Budgeting feasibility.
OFFICIALLY DE-SCOPED 2/15/2023
Original Requirement Text:
Report on actuals and to project future employer costs (e.g., state share of costs for social security, increases or decreases due to MOUs) for salaries and benefits for positions, based on user-defined criteria (e.g., percentage, flat rate per employee).
Reason Cited for Not Implementing During Project:
During design phase it was determined that Position budgeting can not be done in this phase because ctcLink is not able to utilize FULL position management. Not all positions (pooled positions) are affiliated with a specific and consistent position budget code combination.
In PeopleSoft, the Commitment Accounting module provides the capability to track each element of an individual position's payroll expenditure by storing the budget line for each deduction, benefit, salary expense. The overhead to maintain this data was determined to be overwhelming for long term college maintenance, as it would require every position to be fully maintained at the cost and budget line breakdown for every deduction (splitting out each tax line, each deduction, each salary expense, per person, per job). A customization was established, the ctcLink Earnings Distribution page, that allows college HR offices to track salary expenses to a set of Combo Codes aligned with the Earn Code values. Tax and Benefit combo codes are then managed by GL configurations to support payroll expense reporting to the HR Accounting Line.
Finally, once the HR Accounting Line is pushed to the General Ledger in Finance and a journal adjustment is made to correct the budget being charged for this expenditure, that journal adjustment does not sync back to change the HR Accounting Line data at the time of that payroll.
Because of these 3 constraints, this requirement is not feasible to fulfill as currently articulated:
- No adoption of full position management, due to pooled positions.
- Commitment Accounting not in use at colleges due to excessive long term overhead.
- No HR Account Line updates for journal adjustments to payroll expenditure lines, thus no single true source of actuals for all positions.
Original Requirement Text:
Budget and track casual payroll, based on user-defined criteria (e.g., actuals for the previous fiscal year).
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Calculate the lump sum payment due to staff upon retirement based upon user-defined criteria (e.g., age, leave balance, salary, and effective date of retirement).
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Track appropriations based on user-defined criteria, including but not limited to:
- Years That Expenditure is Available, With the Last Year Being the Final Year of Expenditure
- Period of Availability (encumbrance period)
- Period of Liquidation (for disbursement of funds)
Reason Cited for Not Implementing During Project:
The system implementation vendor at the time of initial deployment asserted that this functionality existed in HCM, but did not implement the functionality. This functionality needs to be reviewed for further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Allow for the draft allocation document to be routed for approval based on user-defined criteria.
Reason Cited for Not Implementing During Project:
The above requirement relates to the prior requirement on the RFP ID list (A6 - Budgeting Tab), RFP ID 144 - "Generate allocation documents to define the purpose of the allocation, rationale for allocation, guidelines for implementation, allocation of resources (e.g., how positions and funds are to be distributed by cost center and character), type of allocation (e.g., general, earmarked), key performance indicators, and additional user defined criteria." That requirement (RFP ID 144) was deemed by the vendor as requiring a CEMLI [R-214] to be satisfied. The system implementation vendor at the time moved the requirements in the RFP ID range of 140-145 to General Ledger because of the wording of 'appropriations and allocations', however they also moved this requirement to Payroll at one point as well. In essence, these two companion requirements were asking for the system to store documents relating to the budget reasoning at the time of budget development and then route those attachments for approval, to essentially 'approve' the choices around how an over-arching budget is divided up across various intentions for how to spend that budget. In Planning and Budgeting Cloud Solution (PBCS) there is the option to attach a document to a budget line and there is a method for 'approving' at line, but there is no controls that lock at approved budget or shows that it was approved, other than entering a 'note' on the budget line, but again, this note does not prevent anyone from changing the values after approval, so it is not an official approval workflow. More information from the colleges is needed to determine the true purpose (requirement) for BD144 and how should the routing for approval take place on a draft allocation document in order to satisfy this requirement.
Original Requirement Text:
Report on the timeline and current status of all stages of the allocation process, including but not limited to the creation and approval of allocation documents.
Reason Cited for Not Implementing During Project:
See notes for BD145 as this requirement is associated with the approval stated above.
Original Requirement Text:
Maintain all completed allocated documents and make them available for read-only access by System and colleges for a minimum of the current and three (3) previous bienniums.
Reason Cited for Not Implementing During Project:
See notes for BD145 as this requirement is associated with the approval stated above.
Original Requirement Text:
Sort completed allocation documents by program, allocation number, program title, and other user-defined criteria.
Reason Cited for Not Implementing During Project:
See notes for BD145 as this requirement is associated with the approval stated above.
Original Requirement Text:
Define required fields (e.g., cost centers) for the input of allocations into an expenditure plan.
Reason Cited for Not Implementing During Project:
Must clarify with colleges the meaning of 'expenditure plan' as it relates to budget development. The requirement appears to be within the capabilities of PBCS using 'Budget Scenarios' or "What If" budget modeling, but work is still needed to confirm that this approach will satisfy this requirement for the colleges.
Original Requirement Text:
Produce a report of Program Managers based on user-defined criteria (e.g., current year).
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Provide the ability for the final approval by electronic signature and to designate final approval as defined by the System.
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Provide a fully featured modeling function including, but not limited to:
- Regression (e.g., linear, based on historical patterns for various time periods)
- Adjustments for user-defined variables (e.g., seasonality, program implementation)
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Review and incorporation of regular historical revenue/receipt, expenditure, apportionment, appropriation and encumbrance patterns (e.g., current versus prior period actual)
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Growth/Reduction Model, based on user-defined criteria
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Perform "what if" budgeting modeling and analysis, at any user-defined level (e.g., individual employee, college, project, and program), for multiple user-defined criteria and parameters, including but not limited to the following:
- Percent
- Job Classification
- Bargaining Unit
- Enrollment Projections
- Population Projections
- Appropriations
- Bonds
- Object Code (Category/Object/Object Detail)
- Policy Changes
- Mandatory vs. Discretionary
- Federal Policy/Program Changes
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Forecast based on user-defined parameters, which include, but are not limited to the following:
- Object Structure
- Program Structure
- Fund
- Appropriation
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Export and import budget forecasting data from and to external systems (e.g., demographics).
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Assign effective dates to user-defined parameters (e.g., object detail), to create projections that support compounded increases or decreases, based on set value or percentage value, over multiple year budgets.
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Change projections at any time during the fiscal year, based on user-defined criteria (e.g., state economic forecasts), for user-defined parameters, including, but not limited to the following:
- Revenues/Receipts
- Expenditures
- Interest
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Save an unlimited number of forecasting models, with assigned model owner, maintaining them for historical purposes.
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Produce and maintain multi-year, long range forecasts, for a minimum ten year period.
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Provide the ability to model across-the-board budget changes for revenue/receipt and/or expenditures, including but not limited to:
- Excluding programs, appropriations, etc.
- If then else scenarios
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Produce user-defined budget documents (e.g., budget highlights at any level of the organization structure, fund condition at any level of the organization structure).
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Export and merge data and text (e.g., budget narrative) for the production of budget documents.
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Track and manage changes or revisions to the budget document narratives, including but not limited to:
- Redlining and strikeout modifications.
- Audit trail for tracking redlining and strikeout modifications.
- Option to print redlining and strikeout modifications.
- Support hyperlinks to external web sites
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Generate summary and detail level projection reports, by user-defined criteria (e.g. district, college, department), by user-defined time period, for user-defined parameters, including but not limited to:
- General Fund Expenditure Totals
- General Fund Revenues
- All Other Funds (e.g., Special Funds, Bond Funds, Trust Funds): Expenditure Totals, Revenues/Receipts, Fund Update
- User-Defined Criteria (e.g., earmarked fund)
- Federal Grants
- Appropriations
- Expenditures
- Revenues/Receipts
- Transfers
- Positions
- Budget Projections (e.g., revenues/receipts, expenditures, reimbursements, loans)
- Budget Forecasts
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Generate position control reports, based on user-defined criteria (e.g., filled positions vs. budgeted; projected salary savings).
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Generate budget revenue/receipt forecast reports, including but not limited to the following:
- Comparative reporting on prior year history
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Extrapolation, based on user-defined criteria (e.g., Straight line extrapolation based on YTD; straight line total encumbrance)
Reason Cited for Not Implementing During Project:
This requirement will be met with further clarification from colleges during the Stabilization Period after the completion of the PBCS deployment work.
Original Requirement Text:
Track and record transactions applicable to individual projects at all levels of the account classification (i.e., organization, program, object, fund, appropriation) by user-defined time period (e.g., month, YTD, inception to date), by organizational level for all projects, based on user-defined criteria, including but not limited to, the following:
- Required Project Reports (including dates required)
Reason Cited for Not Implementing During Project:
This requirement will needs addition clarification from college resources before it can be determined whether this requirement remains unfulfilled.
Original Requirement Text:
Track project-related salaries, benefits, and other non-salary, labor-related costs, based on user-defined criteria.
Reason Cited for Not Implementing During Project:
Numerous efforts were made during the implementation phase of the project to define a complete set of requirements for Time and Effort reporting; however each effort resulted in conflicting requirements that lead Subject Matter Experts to conclude that a solution was not achievable with the given understanding of ctcLink. Currently there is no Time and Effort reporting customization; however an effort will be undertaken again now that all colleges are on ctcLink to attempt to establish a complete and non-conflicting set of actionable requirements to meet the need outlined above.
Original Requirement Text:
Track hours expended for all projects and allow direct project-related charging by organizational unit, pay period, employee, account number, and other user-defined criteria.
Reason Cited for Not Implementing During Project:
Numerous efforts were made during the implementation phase of the project to define a complete set of requirements for Time and Effort reporting; however each effort resulted in conflicting requirements that lead Subject Matter Experts to conclude that a solution was not achievable with the given understanding of ctcLink. Currently there is no Time and Effort reporting customization; however an effort will be undertaken again now that all colleges are on ctcLink to attempt to establish a complete and non-conflicting set of actionable requirements to meet the need outlined above.
OFFICIALLY DE-SCOPED 1/04/2023
Original Requirement Text:
Automatically roll-forward into new budget year all previous budget appropriations, including but not limited to: expenditures/encumbrances (separated out by contract and dollar amount), progress payments throughout multiple years for the life of a project, and balances, based on user defined criteria. This include providing a report on the balances remaining that were rolled.
Reason Cited for Not Implementing During Project:
The system implementation vendor originally responded to the RFP that this requirement was delivered functionality, but in truth it is not. This is a manual process, as there is no automatic process in ctcLink to fulfill this requirement. This requirement is recommended for de-scope as it was not within the system capabilities at procurement time, nor is it a delivered capability today (9 years later).
OFFICIALLY DE-SCOPED 1/04/2023
Original Requirement Text:
Rollover or re-program unused project dollars into other projects and track the dollars based on the original and rollover/reprogram projects over multiple years, within user-defined criteria and parameters. This includes the ability to manually perform or bypass the rollover process, based on authorization.
Reason Cited for Not Implementing During Project:
The system implementation vendor originally responded to the RFP that this requirement was delivered functionality, but in truth it is not. This is a manual process, as there is no automatic process in ctcLink to fulfill this requirement. This requirement is recommended for de-scope as it was not within the system capabilities at procurement time, nor is it a delivered capability today (9 years later).
OFFICIALLY DE-SCOPED 1/04/2023
Original Requirement Text:
Display a warning message when trying to close a project with outstanding charges, open or outstanding purchase orders, or which has been over expended.
Reason Cited for Not Implementing During Project:
The system implementation vendor originally responded to the RFP that this requirement could be met through configuration; however there are not configuration options to enable warning messages in Project Cost for remaining open activity in other modules, such as Purchasing. The guidance is not to close the Project in Project Costing, but rather to close the Purchase Order. Users are recommended to address all closure activities at the source. Commitment Control (KK) is the module used to manage whether an expenditure is within budget; therefore that is module is where the warning message is triggered. This requirement is recommended for de-scope as it was not within the system capabilities at procurement time, nor is it a delivered capability today (9 years later).
Original Requirement Text:
Generate advance notifications of project end dates, by user-defined process (e.g., prompt at point of user transaction; report), based on user-defined criteria, including but not limited to:
- Encumbrance Availability Date
- Project End Date
- Contract End Date
- Other Phase
Reason Cited for Not Implementing During Project:
Currently there are no notifications available in ctcLink for the above requirement. More information is needed to define this requirement and determine if this requirement is feasible within the product, as there are limited notification capabilities in Grants, Project Costing, and Customer Contracts. The system implementation vendor originally responded to the RFP that this requirement could be met through configuration; however there are not configuration options to enable warning messages in Project Cost The system does not offer the capability for prompt at the point of transaction for the listed criteria; therefore the requirement at a minimum will need to be adjusted in scope. There is limited warning/notification, such as expenditure attempts before a project is started or after a project is closed will encounter an 'out of bounds' error, due to the project dates not aligning with the date of the expenditure attempt.
Original Requirement Text:
Generate a report, by project, by user-defined time period (e.g., month, year, inception to date), based on user-defined criteria, including but not limited to:
- Receipts
- Remaining Available Balances/Deficiency of Receipts
Reason Cited for Not Implementing During Project:
Will need to confirm with Data Services to determine if this requirement has been fulfilled and confirm with the colleges that those reports satisfy this requirement.
Original Requirement Text:
Generate a project distribution summary, by accounting period-to-date, with prior month comparison, actual to budget comparison, and inception-to-date.
Reason Cited for Not Implementing During Project:
Below you will find a list of some of the current Queries/Reports along with the descriptions. Will need to confirm with the colleges to determine if this requirement has been fulfilled and confirm with the colleges that these reports satisfy this requirement.
|
Query/Report
Name |
Description |
|---|---|
|
BFS_KK_GRANTS |
BI
Publisher report for grants that shows budget, expenses, encumbrances and
balances in several formats of varying details. |
|
BFS_GL_BEROP |
Report for grants, projects, or operational departments that shows budget, expenses, encumbrances, and balances in several formats of varying details. |
|
QFS_CO_HR_ACCTG_LINE_EE_DIST |
Shows
staff charged to projects for a specified period of time. Requires
additional security to view due to sensitive data. |
|
QFS_CO_HR_ACCT_LINE_PAY_PERIOD |
Shows
staff charged to projects for a specified period of time. Includes pay
period date. Requires additional security to view due to sensitive data. |
|
QFS_GR_GRANT_BUDGET_EXPENSES |
Shows
all expenses in a grant. Includes accounting period but not accounting
date. Also includes grant period. |
|
QFS_KK_BUDGET_OVERVIEW_GNT |
Shows
budget, expense, encumbrance, and balance for each budget item in a grant by
project and activity. |
|
QFS_KK_BUDGET_OVERVIEW_GNT_DTL |
Shows
all expenses in a grant. Includes supplier names when applicable. |
|
QFS_PC_PROJ_RESOURCE |
Shows
all grant or project data from the Project Resource table. May be most
helpful when filtering/sorting on analysis type and putting data into a pivot
table. |
|
QFS_PC_PROJ_RESOURCE_PAYMENT |
Same data as QFS_PC_PROJ_RESOURCE and also includes details on payments made to others (check/ACH, payment date, payment number, etc.) that were charged to the grant or project. |
|
QFS_PR_PROJ_BUD_EXP |
Shows budgets and expense totals by account/budget item. Includes full chartstrings for each project's budget item. |
|
CTC_PR_BILLABLE |
Shows billable data for cost-reimbursable grants. |
|
CTC_PR_BILLABLE_SUMMARY |
Summary level billable data for cost-reimbursable grants. May be helpful if you need to attach a list of itemized expenses to an invoice you send to a grantor. |
|
CTC_PR_BILLED |
Shows
billed data from a given grant. |
|
QFS_CO_HR_ACCTG_LINE_EE_DIST |
Shows payroll by employee by grant. Need higher level security to view this. |
|
QFS_GM_AWARDED_GRANTS |
Shows information for awarded grants - dates, sponsors, F&A rates, etc. |
|
PGFS_KK_BUDGET_OVERVIEW_GNT_PG |
Pivot Grid that displays how much of a project budget was spent in each budget category in graph and chart formats. |
Original Requirement Text:
Separate prior years expenditures and prior years budget for generally accepted accounting principles (GAAP) reporting, by user-defined period (e.g., Federal fiscal year, State fiscal year, calendar year, specific as-of date), by user-defined criteria (e.g., inception-to-date budget, remaining budget, multi-year budget).
Reason Cited for Not Implementing During Project:
Please see requirement PC140 for a list of Queries/Reports along with the descriptions. Will need to confirm with the colleges to determine if this requirement has been fulfilled and confirm with the colleges that these reports satisfy this requirement.
Original Requirement Text:
Track capital project funding, by source (e.g., bonds, loans), for user-defined criteria.
Reason Cited for Not Implementing During Project:
Tracking by source capabilities are limited to the FUND associated with the capital project; therefore only funds that have a direct correlation to the source are capable of being tracked by this method in alignment to the requirement.
Funds from a bond go into a larger "bucket"of fund codes for those funds. There is no way to track back to which bond the funding originated. If a unique fund code was created then one could use that to track expenditures. It would require a unique fund code for each bond. Reporting would have to be set up according to user defined criteria using the unique fund code.
Original Requirement Text:
Reconcile cash flow projections.
Reason Cited for Not Implementing During Project:
If the cash flow projections were captured through comparison with actual revenue in a revenue budget this could be reconciled in commitment control. More information is needed to confirm with the colleges that the requirement has been satisfied.
Original Requirement Text:
Define and maintain standard purchasing data, such as amounts, and costs.
Reason Cited for Not Implementing During Project:
Vendor catalogs or vendor pricing were not added into the system. This would require instituting eSupplier so that the system could connect to supplier online catalogs. More discussion is needed with colleges before determining we are ready as a system to undertake this effort.
Original Requirement Text:
Provide system notification when purchase order is scheduled to expire based on user-defined criteria.
Reason Cited for Not Implementing During Project:
This can be done manually from a report. Currently a purchase order doesn't expire, as there are no identified closed days for Purchase Orders. From PeopleBooks:
"The Close Days field on the Purchasing Definition - Business Unit Definition page specifies the number of days beyond a purchase order's last activity date during which the purchase order cannot be closed. The close days value creates a grace period during which you can change the purchase order before the purchase order closes. If you leave the Close Days field blank, the system uses zero close days."
If an expiration date was added, then we would need to research the possibilities of notification which might include adding the Virtual Approver model to meet this requirement.
OFFICIALLY DE-SCOPED 3/15/2023
Original Requirement Text:
Track contracts outside of purchase order (e.g., property lease, software license)
Reason Cited for Not Implementing During Project:
This is not part of ctcLink Finance. This would need to be manually tracked outside of ctcLink. This requirement is recommended for de-scope as these contracts are not maintained with the Finance pillar.
OFFICIALLY DE-SCOPED 11/2/2022
Original Requirement Text:
Ability to encumber in multiple currencies complete with currency exchange
Reason Cited for Not Implementing During Project:
Currently ctcLink is only configured for US Currency. This requirement is recommended for de-scope as there were not requests for additional currency values within the Finance pillar.
OFFICIALLY DE-SCOPED 3/15/2023
Original Requirement Text:
Support rent/lease requirements (e.g., notification of the upcoming lease expiration, etc.)
Reason Cited for Not Implementing During Project:
This is not part of ctcLink Finance. This would need to be manually tracked outside of ctcLink. This requirement is recommended for de-scope as these contracts are not maintained with the Finance pillar.
OFFICIALLY DE-SCOPED 3/15/2023
Original Requirement Text:
Support buy or lease decisions
Reason Cited for Not Implementing During Project:
While reports could be generated by supplier to see purchase history, there is nothing in ctcLink that would support making these types of decisions. This requirement is recommended for de-scope as these decisions are not made with data maintained within the Finance pillar.
OFFICIALLY DE-SCOPED 3/15/2023
Original Requirement Text:
Reconcile requisitions.
Reason Cited for Not Implementing During Project:
We don’t (finance in general) reconcile requisitions. Reconciliation begins at the purchase order, which is received and vouchered. The requisition, once sourced to the purchase order, then goes through receiving and/or vouchering. There is a close process for those requisitions not sourced to a purchase order. This requirement is recommended for de-scope as the reconciliation process is managed at a later stage in the purchasing process within the Finance pillar.
OFFICIALLY DE-SCOPED 3/15/2023
Original Requirement Text:
Reverse requisition reconciliation.
Reason Cited for Not Implementing During Project:
Since we don’t reconcile, there is no need to reverse. If the requisition is closed, then there is a reopen process. See PO30 response for additional information.
OFFICIALLY DE-SCOPED 3/15/2023
Original Requirement Text:
Process purchase order acknowledgments.
Reason Cited for Not Implementing During Project:
The requirement validation to date eludes to an assumption that this is acknowledgment by the supplier (Vendor), which is not a function of ctcLink and is handled manually using the Vendor's method for such and acknowledgment. This requirement is recommended for de-scope.
Original Requirement Text:
Create purchase orders or contracts from solicitations automatically based on user-configurable business rules and manually based on the manual transfer of data from a solicitation document to the appropriate purchasing form without additional required data entry.
Reason Cited for Not Implementing During Project:
This requirement originated from Gartner Consulting and was not clarified by colleges as to the meaning of 'from solicitations' at the time of requirement validation. Based on recent research, it could be interpreted as an invitation to bid, and to provide the capabilities to source a PO or contract from the bid responses to a solicitation; however confirmation of the actual meaning of the requirement is needed to better understand the college intent for this requirement. Currently this system provides no automated creation of a PO or Contract from a 'solicitation'.
Original Requirement Text:
Define and maintain user-configurable business rules to support contract management, identification and completion of required contract data (e.g., award advice), and transmission of required contract data to systems based on applicable System, State, State Board rules and regulations.
Reason Cited for Not Implementing During Project:
The Purchasing module, combined with the Project and Contract modules provide the capabilities to support contract management and contract data, but this requirement will need additional clarification from college resources before it can be determined whether this requirement remains unfulfilled.
Original Requirement Text:
Define and maintain receiving tolerances based on user-defined business rules.
Reason Cited for Not Implementing During Project:
This functionality is available in ctcLink, and it is believed that this requirement is fulfilled, however confirmation is recommended from the colleges before marking this requirement as satisfied.
PeopleBooks Reference for College Understanding:
Purchasing takes into consideration the purchase order schedule quantity, the current receipt quantity, and any quantity previously received for the purchase order schedule. When the quantity previously received, plus the current receipt quantity is greater than the purchase order quantity, the difference is compared to the value in the Qty Rcvd Tolerance % (quantity received tolerance percent) field, specified on the Purchase Order Schedule page.
Original Requirement Text:
Automatically notify the Accounts Payable department once receiving information has been entered in the system.
Reason Cited for Not Implementing During Project:
The system implementation vendor responded to the RFP that this requirement was part of delivered functionality and to a limited extent this does exist; however it is limited to serialized assets upon receipt and is handled within the interface receipts process as a push. That functionality does not in fact meet the full intent of this requirement. There is no delivered process that indeed does notify an Accounts Payable department upon entry of receiving information in ctcLink. There is a manual process that enables a user in the AP department to check on the status of receipt. Further discussion is needed with the colleges to determine if a customization is to be requested (via an Enhancement Request process) or whether the requirement should be de-scoped.
Original Requirement Text:
Flag vendors with known quality issues based on user-defined criteria.
Reason Cited for Not Implementing During Project:
Currently not a function of ctcLink. Within ctcLink we have centralized Vendor Profile information, but this does not include many of the elements colleges outlined in Vendor Management requirements (PO88-PO89, PO93, PO97-PO99). If the college system seeks to customize the Vendor Profile in ctcLink a process of requirement gathering, college prioritization is needed in addition to an assessment of the total cost of ownership for such a modification or extension.
Original Requirement Text:
Support Vendor evaluation based on user-defined criteria (e.g., quantitative Vendor metrics; qualitative vendor performance).
Reason Cited for Not Implementing During Project:
See response to PO88.
Original Requirement Text:
Track vendors by logical user-defined groupings (e.g., office supplies, furniture) with defined communication contact.
Reason Cited for Not Implementing During Project:
See response to PO88.
Original Requirement Text:
Support online Vendor and buyer exchanges
Reason Cited for Not Implementing During Project:
See response to PO88.
Original Requirement Text:
Enable vendors to manage their data online, including standard Vendor data, catalog information, discounts, terms, and other data including ability to enter e-payment information, bank routing number and account number.
Reason Cited for Not Implementing During Project:
See response to PO88.
Original Requirement Text:
Enable vendors to track their transactions, payment status, and payment information (e.g., payment date, amount, check number) online based on user-defined criteria.
Reason Cited for Not Implementing During Project:
See response to PO88.
OFFICIALLY DE-SCOPED 4/5/2023
Original Requirement Text:
Track an unlimited number of endowed or non-endowed funds.
Reason Cited for Not Implementing During Project:
System Implementation Vendor responded that this requirement could be met within the General Ledger Module.
College foundations manage investment funds or endowments where the interests earned are used to fund scholarship offers (for example). At the time of configuring colleges for implementation, there were no colleges requesting that these funds be addressed during the Treasury and Cash Management configuration.
At the time of configuring colleges for implementation, there were no colleges requesting that this be addressed during configuration. Project Leadership Team prior to FirstLink de-scoped the Trust Fund requirements, but did not go before a formal governance process. These requirements need to be taken to the Operational Governance for an official de-scope.
OFFICIALLY DE-SCOPED 4/5/2023
Original Requirement Text:
Maintain detail of expendable and non expendable values of trust.
Reason Cited for Not Implementing During Project:
System Implementation Vendor responded that this requirement could be met within the General Ledger Module.
At the time of configuring colleges for implementation, there were no colleges requesting that this be addressed during configuration. Project Leadership Team prior to FirstLink de-scoped the Trust Fund requirements, but did not go before a formal governance process. These requirements need to be taken to the Operational Governance for an official de-scope.
OFFICIALLY DE-SCOPED 4/5/2023
Original Requirement Text:
Ability to make mass updates [..to managed trust funds].
Reason Cited for Not Implementing During Project:
System Implementation Vendor responded that this requirement could be met within the General Ledger Module.
At the time of configuring colleges for implementation, there were no colleges requesting that this be addressed during configuration. Project Leadership Team prior to FirstLink de-scoped the Trust Fund requirements, but did not go before a formal governance process. These requirements need to be taken to the Operational Governance for an official de-scope.
OFFICIALLY DE-SCOPED 4/5/2023
Original Requirement Text:
Maintain/track fund allocations to trust funds.
Reason Cited for Not Implementing During Project:
System Implementation Vendor responded that this requirement could be met within the Cash Management and General Ledger Modules.
At the time of configuring colleges for implementation, there were no colleges requesting that this be addressed during configuration. Project Leadership Team prior to FirstLink de-scoped the Trust Fund requirements, but did not go before a formal governance process. These requirements need to be taken to the Operational Governance for an official de-scope.
OFFICIALLY DE-SCOPED 4/5/2023
Original Requirement Text:
Record type of trust fund (e.g. specific vs. endowed).
Reason Cited for Not Implementing During Project:
At the time of configuring colleges for implementation, there were no colleges requesting that this be addressed during configuration. Project Leadership Team prior to FirstLink de-scoped the Trust Fund requirements, but did not go before a formal governance process. These requirements need to be taken to the Operational Governance for an official de-scope.
OFFICIALLY DE-SCOPED 4/5/2023
Original Requirement Text:
Ability to add comments for internal & departmental use.
Reason Cited for Not Implementing During Project:
At the time of configuring colleges for implementation, there were no colleges requesting that this be addressed during configuration. Project Leadership Team prior to FirstLink de-scoped the Trust Fund requirements, but did not go before a formal governance process. These requirements need to be taken to the Operational Governance for an official de-scope.
OFFICIALLY DE-SCOPED 4/5/2023
Original Requirement Text:
Maintain/track expanded financial source history (e.g. government matches, internal match, donor etc).
Reason Cited for Not Implementing During Project:
System Implementation Vendor responded that this requirement could be met within the General Ledger Module, however the vendor at the time of response assumed we would use a distribution code to designate the source history.
At the time of configuring colleges for implementation, there were no colleges requesting that this be addressed during configuration. Project Leadership Team prior to FirstLink de-scoped the Trust Fund requirements, but did not go before a formal governance process. These requirements need to be taken to the Operational Governance for an official de-scope.
OFFICIALLY DE-SCOPED 4/19/2023
Original Requirement Text:
Manage underwater Accounts.
Reason Cited for Not Implementing During Project:
System Implementation Vendor responded that this requirement could be met within the General Ledger Module, however the vendor did not provide a means by which to identify a mechanism within the Chart of Accounts module to specify an account as 'underwater'. "Underwater" is the term for a financial contract or asset that is worth less than its notional value, which is not traditionally something that would be tracked within a GL. More work is needed with college input to understand the intention of this requirement and determine if a solution is still outstanding.
OFFICIALLY DE-SCOPED 4/19/2023
Original Requirement Text:
Tracking of fund movements within accounts and account reclassification.
Reason Cited for Not Implementing During Project:
At the time of configuring colleges for implementation, there were no colleges requesting that this be addressed during configuration. Project Leadership Team prior to FirstLink de-scoped the Trust Fund requirements, but did not go before a formal governance process. These requirements need to be taken to the Operational Governance for an official de-scope.
OFFICIALLY DE-SCOPED 4/19/2023
Original Requirement Text:
Complete compliance (e.g. Book & Market) information for controlling and tracking fund account expenditures.
Reason Cited for Not Implementing During Project:
At the time of configuring colleges for implementation, there were no colleges requesting that this be addressed during configuration. Project Leadership Team prior to FirstLink de-scoped the Trust Fund requirements, but did not go before a formal governance process. These requirements need to be taken to the Operational Governance for an official de-scope.
OFFICIALLY DE-SCOPED 4/19/2023
Original Requirement Text:
Seamless integration of data into and out of all other systems.
Reason Cited for Not Implementing During Project:
Integration between other systems have not been established, no systems were identified. At the time of configuring colleges for implementation, there were no colleges requesting that this be addressed during configuration. Project Leadership Team prior to FirstLink de-scoped the Trust Fund requirements, but did not go before a formal governance process. These requirements need to be taken to the Operational Governance for an official de-scope.
Original Requirement Text:
Add ticklers (task lists) (e.g., reminder to do something in future).
Reason Cited for Not Implementing During Project:
This functionality does not exist in ctcLink. Project Leadership Team prior to FirstLink de-scoped the Trust Fund requirements, but did not go before a formal governance process. These requirements need to be taken to the Operational Governance for an official de-scope.
OFFICIALLY DE-SCOPED 4/19/2023
Original Requirement Text:
Provide document management functionality (e.g., store gift agreements, etc per account).
Reason Cited for Not Implementing During Project:
Per the system implementation vendor PeopleSoft is not a document management system. PeopleSoft can support document attachments in specific areas, with a customization if not made available within a specific business process. This requirement should have either been reduced in scope to attachments for a specific business process or fully de-scoped at RFP response time. The requirement needs college input and needs to be brought before operational governance to address the scope. The only module purchased, but not deployed that states it provides document management functionality is Supplier Contract Management, but this is unrelated to Trust Fund management.
OFFICIALLY DE-SCOPED 4/19/2023
Original Requirement Text:
Ability to manage the unitization of one or more investment pools with varying distribution rules for shares, income, spending, and gains.
Reason Cited for Not Implementing During Project:
This functionality does not exist in ctcLink. Project Leadership Team prior to FirstLink de-scoped the Trust Fund requirements, but did not go before a formal governance process. These requirements need to be taken to the Operational Governance for an official de-scope.
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.
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 6 ("A6") 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.
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!
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.
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.
List of FSCM Requirements Needing Clarification
The following RTM Scope Transfer requirements are seeking more input from colleges before it can be determined if action is needed:
Accounts Payable
Accounts Receivables
- AR34 - Accounts Receivables (Managing Receipts) [Requirement Clarifications Needed]
- AR40 - Accounts Receivables (Dunning & Collections) [Requirement Clarifications Needed]
- AR56 - Accounts Receivables (Self-Service) [Requirement Clarifications Needed]
Cash Management
- CM6 - Cash Management (Cash Disbursement) [Requirement Clarifications Needed]
- CM22 - Cash Management (Interest Management) [Requirement Clarifications Needed]
- CM23 - Cash Management (Interest Management) [Requirement Clarifications Needed]
- CM24 - Cash Management (Interest Management) [Requirement Clarifications Needed]
- CM30 - Cash Management (Inquiry & Reporting) [Requirement Clarifications Needed]
- CM33 - Cash Management (Inquiry & Reporting) [Requirement Clarifications Needed]
Contracts
- CO59 - Contracts (Manage Contract) [Requirement Clarifications Needed]
- CO60 - Contracts (Manage Contract) [Requirement Clarifications Needed]
General Ledger
Grants
- GR75 - Grants (Manage Grant) [Requirement Clarifications Needed]
- GR78 - GR83 - Grants (Manage Grant) [Requirement Clarifications Needed]
Commitment Control
- BD142 - Commitment Control (KK) (Appropriations) [Requirement Clarifications Needed]
- BD186 - Budget [KK/GL] (Budget Administration) [Requirement Clarifications Needed]
Budgets (PBCS)
- BD3 - PBCS (General) [Requirement Clarifications Needed]
- BD21 - PBCS (General) [Requirement Clarifications Needed]
- BD44 - PBCS (Budget Development - General) [Requirement Clarifications Needed]
- BD45 - PBCS (Budget Development - General) [Requirement Clarifications Needed]
- BD56 - PBCS (Budget Development - Base Budget/ Rollover/ Versions) [Requirement Clarifications Needed]
- BD63 - PBCS (Budget Development - Base Budget/ Rollover/ Versions) [Requirement Clarifications Needed]
- BD77 - PBCS (Budget Development - Financial Plans) [Requirement Clarifications Needed]
- BD95-BD104 - PBCS (Personnel Budget) [Requirement Clarifications Needed]
- BD106 - PBCS (Personnel Budget) [Requirement Clarifications Needed]
- BD107 - PBCS (Personnel Budget) [Requirement Clarifications Needed]
- BD108 - PBCS (Personnel Budget) [Requirement Clarifications Needed]
- BD109 - PBCS (Personnel Budget) [Requirement Clarifications Needed]
- BD110 - PBCS (Personnel Budget) [Requirement Clarifications Needed]
- BD114 - PBCS (Personnel Budget) [Requirement Clarifications Needed]
- BD115 - PBCS (Personnel Budget) [Requirement Clarifications Needed]
- BD117 - PBCS (Personnel Budget) [Requirement Clarifications Needed]
- BD118 - PBCS (Personnel Budget) [Requirement Clarifications Needed]
- BD123, BD128, BD129 - PBCS (Budget - Appropriations) [Requirement Clarifications Needed]
- BD145 - Budgets (Allocations) [Requirement Clarifications Needed]
- BD146 - Budgets (Allocations) [Requirement Clarifications Needed]
- BD147 - Budgets (Allocations) [Requirement Clarifications Needed]
- BD148 - Budgets (Allocations) [Requirement Clarifications Needed]
- BD149 - Budget (Allocations) [Requirement Clarifications Needed]
- BD150 - PBCS (Allocations) [Requirement Clarifications Needed]
- BD151 - PBCS (Budget Forecasting) [Requirement Clarifications Needed]
- BD152-BD154- PBCS (Budget Forecasting) [Requirement Clarifications Needed]
- BD155 - PBCS (Budget Forecasting) [Requirement Clarifications Needed]
- BD156 - PBCS (Budget Forecasting) [Requirement Clarifications Needed]
- BD157-BD169 - PBCS (Budget Forecasting) [Requirement Clarifications Needed]
- BD170-BD174 - PBCS (Budget Forecasting) [Requirement Clarifications Needed]
- BD175 - PBCS (Budget Forecasting) [Requirement Clarifications Needed]
- BD176 - PBCS (Budget Forecasting) [Requirement Clarifications Needed]
- BD177- BD180 - PBCS (Budget Forecasting) [Requirement Clarifications Needed]
- BD181 - PBCS (Budget Forecasting) [Requirement Clarifications Needed]
- BD182- PBCS (Budget Forecasting) [Requirement Clarifications Needed]
- BD183-BD185- PBCS (Budget Forecasting) [Requirement Clarifications Needed]
- BD189 - PBCS (Budget Document) [Requirement Clarifications Needed]
- BD190 - PBCS (Budget Document) [Requirement Clarifications Needed]
- BD193-BD197 - PBCS (Budget Document) [Requirement Clarifications Needed]
- BD198 - BD222 - PBCS (Inquiry & Reporting) [Requirement Clarifications Needed]
- BD230 - PBCS (Inquiry & Reporting) [Requirement Clarifications Needed]
- BD231-232 PBCS (Inquiry & Reporting) [Requirement Clarifications Needed]
- BD223 - PBCS (Inquiry & Reporting) [Requirement Clarifications Needed]
Project Costing
- PC44 - Project Costing (Record and Track Project Transactions) [Requirement Clarifications Needed]
- PC46 - Project Costing (Record and Track Project Transactions) [Requirement Clarifications Needed]
- PC50 - Project Costing (Manage Project) [Requirement Clarifications Needed]
- PC130-PC135- Project Costing (Manage Project) [Requirement Clarifications Needed]
- PC139 - Project Costing (Inquiry & Reporting) [Requirement Clarifications Needed]
- PC140 - Project Costing (Inquiry & Reporting) [Requirement Clarifications Needed]
- CP20 - Project Costing (General) [Requirement Clarifications Needed]
- CP31 - Project Costing (General) [Requirement Clarifications Needed]
Purchasing
- PO3 - Purchasing (General) [Requirement Clarifications Needed]
- PO13 - Purchasing (General) [Requirement Clarifications Needed]
- PO59 - Purchasing (Solicitations) - [Requirement Clarifications Needed]
- PO66 - Purchasing (Voucher & Order Contracts) - [Requirement Clarifications Needed]
- PO80 - Purchasing (Receiving) - [Requirement Clarifications Needed]
- PO88 - Purchasing (Vendor Management) - [Requirement Clarifications Needed]
- PO89 - Purchasing (Vendor Management) [Requirement Clarifications Needed]
- PO93 - Purchasing (Vendor Management) [Requirement Clarifications Needed]
- PO97 - Purchasing (Vendor Management) [Requirement Clarifications Needed]
- PO98 - Purchasing (Vendor Management) [Requirement Clarifications Needed]
- PO99 - Purchasing (Inquiry & Reporting) [Requirement Clarifications Needed]
0 Comments
Add your comment