Skip to end of metadata
Go to start of metadata

As of August 9, 2012

Legend: Done(tick) /Green is on Track(plus) /Yellow is At Risk(warning) /Red is Off Track(minus)

At-A-Glance

Overall At Risk (warning) trending vertical

Completed Major Milestones

  • Milestone 1, Thin Slice of KS integration and KS technology stack
    • Complete April 16, 2012
      • Use of KRAD, KIM and KSA services
      • Kuali Rice 2.x framework
      • End-to-end in technology stack
  • Milestone 2, Transaction view of student receivables
    • Completed April 16, 2012
      • Strategic functional milestone
      • Unfiltered transaction view and account summary
      • Originally projected for 4Q 2012

Demonstrations

Recent demonstration: April 25 Board Meeting: A Demo of UX and milestone 1 & 2

KD12 Target

  • Demonstrate integration with KFS
  • Demonstrate account aging and delinquency

Key Issues and Risks

  • KRAD Knowledge is Expanding
    • Initial gap analysis of KRAD widgets found that some desired templates for an accounting view were missing
    • KRAD documentation was not available to the KSA team until 7/26
    • Anticipate much greater velocity beginning mid-August
  • KFS technical contact is needed
    • Specifications for integration with a generic FS are complete, however a KFS technical contact is need to finalize the integration for KS.
  • Interaction with Functional Council
    • KSA's interaction with the functional council has been very limited since May

To Top\

Overview Completion Dates (plus)

Overall On Schedule Trending Flat

Completed Notable Tasks

  • August 2012
    • Now able to process & import online and volume transactions / document to KSA ledger and create receipts / results
    • Worked out the major contours of payment application and general ledger transaction production (but not interaction, KFS)
    • Designed a number of standard reporting formats (1098T being one of them- strategic)
    • Designed a number of transfer methods to transfer charges to other accounts, which will be fundamental to sponsor billing, etc. Includes write offs, etc.
    • Implementing refund services development 50% complete
    • Payment billing (phase II requirement) design underway
      • This is a trigger for a general ledger review
  • July 2012
    • Interaction with KS-KFS Team Delayed and Off-Schedule
    • Demonstrable Aging of Accounts
    • Account Delinquency
    • Collection Management
    • Dynamic Transaction Views
    • Integrating Rules Management System with KSA
  • June 2012
    • Audit for KSA Lifecycle Supported
    • Transaction Service and XML Load Supported
    • Aging of Accounts Service 70% Complete
    • Utilize KSB Scheduler Factory & rules to initiate transaction input service to age accounts in volume
    • Initiated Contact with Stakeholders to Stage QA Receivable Management Content to KSA Database
      • (First development interaction with stakeholders)
      • UMD fully engaged
    • Refund Management Design Near Completion
    • Personal Preferences Design Under Review
    • Access Authorization for User Ability to Apply Certain Transactions Completed
  • May 2012
    • Interface with KIM Complete
  • April 2012
    • Major Milestone (1) Completion Announcement
    • Thin Slide of KS Interaction and Kuali Technical Stack
    • Major Milestone (2) Completion Announcement
    • Transaction view of Student Receivables
  • March 2012
    • Published KSA-PB (Payment Billing)/TP (Third Party)/CM (Collections Management) requirements on Wiki
    • Published KSA-RM UX Personae on Wiki
    • Published designed KSA-RM use cases, data representation and ER diagrams
    • Published KSA-RM UX Wireframes
    • Stakeholder review/approval period started
    • KS-Community comment period ended for KSA-FM
    • KSA-FM rules design sign-off (epic dev - phase 2)

Detailed Status

Phase 1 (warning)


Overall Trending Vertical

Overview: Phase 1 includes Receivables Management, Payment and Billing and Collection Management

Objective: This module handles the core requirements of accounts receivable, including handling accounts, charges, payments, deferments, etc.  Almost every other module in the system interacts with Accounts Receivable and core accounting functions.  The module includes, but is not limited to the following functions:

  • account management
  • refund management
  • reporting and reconciliation
  • bill production
  • transaction creation
  • cashiering
  • general ledger interaction
  • payment type tracking
  • charge type tracking
  • payment application
  • auditing
  • policy enforcements
  • payment acceptance
  • memo functionality
  • bad debt and collections
  • regulatory tracking
  • holds

Reason for At Risk status:

  • KRAD Knowledge is Expanding
    • Initial gap analysis of KRAD widgets found that some desired templates for an accounting view were missing
    • KRAD documentation was not available to the KSA team until 7/26
    • Anticipate much greater velocity beginning mid-August
  • KFS technical contact is needed
    • Specifications for integration with a generic FS are complete, however a KFS technical contact is need to finalize the integration for KS.
Demonstrations

Recent demonstration: April 25, 2012 to Board and FC 

Previous Notes and Recordings

Progress Metrics

Original Time Estimate

55 weeks

Time Elapsed

28 weeks

Expected Percent Complete

51%

Actual Percent Complete

44%

In-Progress Functionality

  • under construction

Upcoming Milestones

  • Integration with KFS (3Q, 2012)
  • Account aging and delinquency (4Q, 2012)

Risks (in order of priority)

  • KFS technical contact is needed
    • Specifications for integration with a generic FS are complete, however a KFS technical contact is need to finalize the integration for KS
    • Mitigation: request ASAP assistance from KS management to identify a resource for minor Q & A
  • KRAD experience and training/reference materials required
    • Mitigation:
      • This risk has been reduced with the receipt of reference materials 7/26. 
      • Additional ramp up for more complex widgets/development by KSA staff is still needed. 
      • Note thin slice *was* completed using KRAD.  This included UI for transaction view and account summary. 
      • Additional resource has been assigned. 
      • Developing at roughly 65% of expectation currently, but trending up.

To Top\

Phase 2 (plus)


Overall On Schedule Trending Flat

Overview: Phase 2 includes Fee Management and Third Party

Objective: The fee assessment module will be able to calculate all fees and charges for a student given their demographic data, the course load, and other applicable variables. The necessary student data will need to be accessible to this module either via an integration to the school’s student system or an ESB request to the school’s student system or over the KSB.  This will be a rules driven process that will be able to handle extremely sophisticated billing algorithms. The charges can then be posted to the account, or provided to another service (for example, in KE, a student could theoretically present their list of classes, and find out how much it would cost, and create several what-if scenarios.)

Third Party Accounts is otherwise known as sponsorship accounts. This is a module that provides a standard way to deal with an often ad hoc accounting practice, where third-party sponsors agree to pay for some portion of a student account. Most often, this is an employer offering some form of tuition benefit. Third-party access to bills and information is handled very differently to student access. This module will allow that customization, as well as handle the transfer of funds from a third-party payment to the student’s account. It will also handle the reversal of funds if a sponsor does not pay the bill or a student's participation requirements change. The module will include the following:

  • third party sponsor and student accounts
  • transfer of fee from the student(s) account to the third party sponsor account
  • generations of third-party billing
  • third-party payments
  • third-party account aging
  • third-party sponsor self-service/access (phase 3)

Reason for At Risk status: n/a

Demonstrations

Recent demonstration: April 25, 2012 to Board and FC 

Previous Notes and Recordings

Progress Metrics

Original Time Estimate

29 weeks

Time Elapsed

0 weeks

Expected Percent Complete

0%

Actual Percent Complete

5%

In-Progress Functionality

  • Payment Billing design underway


Upcoming Milestones

  • Fee Assessment (2Q, 2013)
  • Third Party (2Q, 2013)


Risks (in order of priority)

  • none 

To Top\

  • No labels