Skip to end of metadata
Go to start of metadata

As of August 9, 2013

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

At-A-Glance

Overall At Risk: (plus) trending vertical

Major Milestones

  • Milestone 1 (tick) , Thin Slice of KS integration and KS technology stack
    • Completed April 16, 2012
      • Use of KRAD, KIM and KSA services
      • Kuali Rice 2.x framework
      • End-to-end in technology stack
  • Milestone 2 (tick) , Transaction view of student receivables
    • Completed April 16, 2012
      • Strategic functional milestone
      • Unfiltered transaction view and account summary
      • Originally projected for 4Q 2012
  • Milestone 3 (tick) , Account Aging and Delinquency
    • Completed October 15, 2012
      • Strategic functional milestone
      • Originally projected for 4Q 2012
  • Milestone 4 (tick) , Integration with KFS
    • Originally projected for 3Q 2012, Completed January 23, 2013
      • KFS integration testing with UMD completed
      • Integration demonstrated to KS technical team and UMD Bursar representatives 1/23/13
  • Milestone 5 (minus) , Fee Management (Assessment)
    • Originally projected by June 1, 2013, Revised projected date is September 13, 2013
  • Milestone 6 (minus) , 3rd Party Billing and Processing
    • Originally projected by June 1, 2013, Revised project date is July 31, 2013

Demonstrations

  • Upcoming demonstration: September 6, 2013 University of Toronto
  • Recent demonstration: May 2 KS Services Team
  • Recent demonstration: April 4-5 USC Bursar and IT representatives
  • Recent demonstration: March 4 KS PAG
  • Recent demonstration: February 18-19 UMD Bursar; March (anticipated) USC Bursar
  • Recent demonstration: January 23, 2013 KS technical team and UMD Bursar representatives

Key Current Topics, Issues and Risks

  • (minus)Update on development of the Kuali Student Accounts (KSA) project:

     

    During March, April and May of this year, Sigma met with representatives from both of the KSA stakeholder institutions1 and the KS Services and UX teams to present a point-in-time status check, determine gap analysis and gather feedback on existing work.  These were very positive and productive meetings and summary notes are available for each on the KSA wiki.  Overall, the feedback for KSA was very positive and Sigma has agreed to adopt all suggestions and gaps identified by KS.  There were several new items identified by the stakeholders that were originally not documented as requirements which have been adopted.  There were a small number of new items that were identified as more appropriate for phase 3 or 4 of the project and one significant item not originally documented as a joint stakeholder requirement that the University of Maryland and Sigma agreed would be a required implementation task.

     

    In May, KSA UI staff met with Jerry Neal from the Rice KRAD team to discuss performance tuning of KRAD components that were key to the KSA user interface.  Again, this was a helpful meeting and there were issues identified that require resolutions which are slated for Rice releases in August2 and February 20143 that will be necessary to complete the KSA UI with production-acceptable performance and permit adequate quality assurance.  Note that as the Rice/KRAD releases are currently documented, release 2.4 may not be needed by KSA development.  If release 2.3 goes out as scheduled we are not projecting that 2.4 will be required.

     

    Since May Sigma has moved on to final development phases of the project.  There were two remaining milestones: 1) Third Party Billing and Processing, and 2) Fee Management (Assessment).  Both milestones had a projected completion date in June.  Phases 1 and 2 of the project development were slated to wrap up around the early July with QA continuing thru the first of August.

     

    Sigma has identified and documented over the last several months that the project was becoming behind schedule on the last two milestones as well as UI development.  The Fee Management module in particular was a known epic development task due to its dependency on a rule based architecture which would support assigning unique and complex student fees based on user-editable conditions and the need for a significant amount of coordination with the Enrollment team (KE) to jointly design the integration points.  The critical nuances of this requirement have certainly challenged the project since the prototype was demonstrated at Kuali Days 2012.

     

    At this time Sigma projects by the end of July to have completed the milestone, 3rd Party Bill and Processing, and be 90% complete through the remaining milestone, Fee Management by the end of August.  Final development and QA would continue through the end of September.  This additional development time will be Sigma donated hours.  As the Rice releases are provided for development in August and November Sigma will plan to adopt them and refactor UI components dependent on the feature set or performance tuning improvement. 

     

     

     

    _________

    1 The University of California and the University of Maryland are stakeholder institutions for KSA

    2 Rice 2.3 Final is scheduled for 7/31/2013

    3 Rice 2.4 Final is scheduled for 2/2014

Phase 1 Development Progress Metrics

 

 

Original Time Estimate

76 weeks

 

 

Time Elapsed

92 weeks

 

 

Expected Percent Complete

100 %

 

 

Actual Percent Complete

97%

Phase 2 Development Progress Metrics

 

 

Original Time Estimate

36 weeks

 

 

Time Elapsed

42 weeks

 

 

Expected Percent Complete

100 %

 

 

Actual Percent Complete

79%

Overall Project Metrics

  

Original Time Estimate

91 weeks

  

Time Elapsed

92 weeks

  

Expected Percent Complete

100 %

  

Actual Percent Complete

84%

Release Schedule

  • Phase 1 Founders Release: Development completion scheduled for April 16, 2013
  • Phase 2 Founders Release: Development completion scheduled for September 13, 2013
  • Project Completion: September 31, 2013 (does not include estimate for re-factoring of Rice/KRAD release 2.3 in August 2013 and possibly 2.4 in February 2014)

Overview Completion Dates (plus)

Overall On Schedule Trending Flat

Completed Notable Tasks

  • July 2013 (as of 8/8/2013)
    • Design specifications with KE which will support Fee Management (Milestone 5) integration have wrapped up.  Design has been turned over to developers.
    • Third Party and Payment Plans (Milestone 6) services are complete.  UI development in progress.
    • KSA team plans to implement Rice 2.3.0 week of 8/12 assuming availability on 8/9. 
      • It will be important to implement this release quickly to adopt performance improvements in time for demonstration to University of Toronto on 9/6.
      • Some refactoring of code is necessary to adopt 2.3.0.
  • June 2013 (as of 7/9/2013)
    • Continued specific focus on KSA-FM this month.  Design is 95% complete.  Sprint development will take place from now until FM completion estimated in mid-September.
      • Design discussions are wrapping up with the KE team.
    • UI development is still a major remaining effort.
  • May 2013 (as of 6/5/2013)
    • Specific focus on KSA-FM (Fee Management) this month.  The design is complete and development of a domain specific language for the rules management component will be underway next.
    • Included in the KSA-FM design was additional progress and continued discussion with the KS services team regarding interface data.
    • KSA upgraded to from Rice 2.2.0 to 2.2.4 and then to 2.3.0-M2 in support or ongoing KRAD performance concerns.
    • KSA UI development met with Jerry Neal for a performance tuning review of KSA.  Notes from this session can be found here.
  • April 2013 (as of 5/7/2013)
    • Provided a demonstration to the KS Service team
      • One objective of this meeting was to assist the interaction b/w services and KSA when discussing integration points
        • Fee Management is a key integration point that will make use of the RateService.  This discussion is nearing completion
    • Incorporated most of the suggestions received from the stakeholder review sessions held in March and April
      • Documenting results for stakeholder by week end 5/5/13
        • Wireframes were developed for a simplified activity log, Transaction Type setup, display, and modification, simple cashiering, and numerous updates to existing designs to improve user experience
    • Completed a UX review with KS UX team at the April Community Workshop
      • Results are documented here: 
      • KSA team documenting responses to UX feedback by week end 5/5/13
      • Participation in User Experience Initiative Meeting (UIX),and the UX/UIM working group sessions
    • Completion of the General Ledger UI
  • March 2013 (as of 4/4/2013)
    • Actively engaged with KS team to synchronize the Fee Management touch points
    • All wireframes for phase 1 are completed
    • Significant progress with outstanding UI development in active sprint
    • Payment Application module now in testing
  • February 2013 (as of 3/7/2013)
    • Completed a UX review and began onsite user testing with stakeholders
      • UMD completed early this month, USC scheduled for first week of April
    • Continued major focus on UI development
      • Making use of nice KRAD features such as subcollections within collections and lightboxes
    • Great progress with the Payment Application rules engine using a DSL (Domain Specific Language) for end users
      • Currently under internal testing with USC production rules
      • Builds upon the proof of concept developed for KD's and is the foundation for the more complex Fee Assessment requirements (phase 2)
    • Several conversations with the KS team regarding holds and ATP (time).  Design for this in KSA is complete and in development
    • Project update and live KSA presentation to the PAG 3/4/13
  • January 2013 (as of 2/4/13)
    • Payment Bill and Third Party design completed pending review
    • UI for General Ledger (supporting KFS integration) designed and implemented, minor bug review taking place
    • Transaction Type UI significant progress, however sprint ongoing
      • KSA makes extensive use of KS 'Type' service
    • Completed integration of KS ATP (academic time period) service into KSA
    • Several reporting methods implemented including Aged Balance & 1098T
  • December 2012 (as of 1/11/13)
    • KSA was upgraded to Kuali Rice 2.2.0 release and KSA Maven dependencies were changed
    • Integrated Kuali Student’s ATP (time) service in KSA
      • Heavily used in Fee Management module
    • Refactored Rules Service and its Drools implementation
      • Creating a new database schema for storing rules and modifying the Drools persistence layer
    • TransactionExportService and TransactionExportController classes used for General Ledger and KFS integration were completed
    • Internal QA of general ledger completed (KFS XML file generation)
      • Efforts ongoing to complete stakeholder testing
    • Process design for Third party billing 90% complete
    • Process design for payment billing 90% complete
    • Multiple working sessions with KS services team members (Tom and Norm) to confirm migration of KS services in KSA (ATP, holds, possibly organization)
    • UI working in-person meeting held with KS team (William Washington) to review KRAD capabilities and gap analysis for KSA requirements
    • 8300 Reporting (cash payments over $10k) process 90% complete, includes export
  • November 2012 (as of 12/10)
    • Development for integration with KFS and generation of transactions is complete
      • KSA has reached out to stakeholders to initiate test plan with desire to complete by 12/31.
    • The following development is now complete for KFS integration needs and for testing:
      • Refund Service
      • Account import
      • Account export
      • Transaction import for UI controller
      • Transaction utility for filtering and allocations
      • General ledger service for preparing and summarizing transactions
    • 3rd party (milestone 6) design now 65% complete
    • UI development of Transaction types underway
      • Anticipate significant additional development for remaining UI in phase 1 over the next month.
  • October 2012 (as of 10/3)
    • Completed a KRAD analysis and effort to support 2 levels of navigation between views and pages
    • Incorporated search controls and a KSA logo into the application header (KRAD)
    • Modified KRAD templates to position the UIF elements (including breadcrumbs) according to the wireframes
  • September 2012 (as of 9/11)
    • KFS output designed, under validation and development began (3Q 2012 deliverable)
      • Sprints established to meet milestone
    • Proof of concept for Fee Management (2Q, 2013 deliverable) designed
      • Includes Classes, data model and import schema
    • Payment Application conceptual design complete
    • KSA trunk upgraded to Rice 2.2.0-M3 release
  • 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 (plus)


Overall: Trending Vertical

Overview: Phase 1 includes Receivables Management and Core Accounting

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

Upcoming Milestones

  • All Phase 1 milestones have been completed.

Risks (in order of priority)

  • none

Phase 2 (plus)


Overall On Schedule Trending Flat

Overview: Phase 2 includes Payment and Billing and Collection Management, 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)

Upcoming Milestones

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

Risks (in order of priority)

  • none