Student Retention – Early Alert
Project Charge Document
  1. ProjectInformation

Project Name: / Student Early Alert / Plan Summary: / Pilot Phase I
Project Sponsor: / South Dakota Board of Regents / Project Start Date: / 05-09-2012
Project Director: / Executive Director, Dr. Jack Warner / Project End Date: / 08-30-2012
Project Manager: / Student Affairs, Dr. Janice Minder / Vendor: / Starfish
Project Owner(s): / Student Affairs Council and Academic Affairs Council
  1. ProjectTeam

Lead Name / University / Area
Janice Minder / SDBOR / Student Affairs – Functional Lead
David Hansen / SDBOR / Information Technology - Lead
Suzanne Preszler / SDBOR / Information Technology
Curtis Card / BHSU / Academic Affairs
Mike Isaacson / BHSU / Student Affairs
Marilyn Halgerson / DSU / Information Technology
Patti Beck / DSU / Student Affairs
Joann Pomplun / NSU / Information Technology
Kathleen Coughlin / NSU / Student Affairs
Pat Beu / SDSMT / Student Affairs
Mark Urban / SDSMT / Student Affairs
Aaron Aure / SDSU / Academic Affairs
Jody Owen / SDSU / Student Affairs
Carla Reihe / USD / Information Technology
Steve Ward / USD / Academic Affairs
Rich Avery / DSU / Faculty - Math
Steve Rasmussen / NSD / Academic Affairs
Kendra Hill / SDSU / Faculty - Biology
Rory Fenske and Hanna McElroy / SDSMT and SDSU / Student Federation

3.Process Statement

The South Dakota Board of Regents has selected Starfish as their Student Early Alert vendor. This software will enable the identification of students exhibiting at-risk behaviors early in their educational career, so that action can be taken by the appropriate service areas. The objective for the system is to increase student retention, success, graduation and reduce transfer-out or stop-out rates. Managing the information in this system will become an integral part of the daily processes of many different departments at all of our Universities and locations statewide. The system must be architected to work in our University system environment and have a robust security setup that is flexible and supports levels of security ranging from restricted access to broad access. Security setup should also support a distributed model of administration where central administrators or super-users have broad access and they can distribute more restricted access to departmental users based on certain roles or groups.

RFP Assumptions - SDBOR intends to use the system in the following ways:

1.SDBOR will identify warning indicators or behaviors that will begin to be monitored early in a student’s career allowing faculty and staff that observe students exhibiting at-risk behaviors to note it in the early alert system so action can be taken to improve their chance for success in the BOR system.

2.SDBOR will need the ability to identify data points or markers in our information systems, Colleague or D2L, that can be monitored, included for evaluation individually or used in conjunction with other markers to identify at-risk students.

3.SDBOR will need the ability to import markers from other systems that the Universities define to be considered in determining at-risk students.

4.SDBOR will need the ability to correlate multiple pieces of information from items 1, 2, and 3 above, identify the criteria to be used in an automated evaluation of the noted behaviors, and provide for the option to categorize or prioritize individual student cases based on their indicators, markers or behaviors.

5.Based on the at-risk level determined by the information above, the SDBOR will identify specific activities or groups of activities or actions that will be taken to address the at-risk student and improve their chance for success.

6.The early alert system will help facilitate the communications for certain communication types and will allow the University to continue tracking correspondence with the at-risk student until the condition(s) is addressed and they are no longer considered at-risk or they are no longer a student at the University.

7.When the at-risk condition is either addressed or the student is no longer a member of the University system, the system should allow us to end their status so the students is no longer an active member of the early alert system and notifications are no longer sent/updated.

Project Area / Description
Background: / The exploration of early alert software emerged at the institutional level, and it was this individual level review that helped to bring about the request for one-time funds during the 2011 legislative session. The legislature provided one-time funds of $380,000.
Vision Statement: / To increase early adoption of the Early Alert software, increasing communications between staff, faculty and students and thereby, retaining students.
Objective: / Increase of retention by 1% within the Regental system for first year students. The result would be an increase of 48 students by the Fall of 2014. According to Noel-Levitz, a 3-5% improvement may be possible within one year with aggressive retention strategies.
Scope:
Included in scope: / This is a pilot phase including first year students. The implementation and early adoption will focus on the following general education course sections: Math 21, 101, 102, 123; ENGL 101; SPCM 101; PSYC 101; SOC 100; BIOL 101; WEL 100; CHEM 112; POLS 100; CSC 105; HIST 121, 151; SPAN 101; GS 143.
Excluded from scope: / While early adoption and training will be centered on the general education courses identified, the remaining first year students/faculty may utilize the system. However, all other courses/students/facultyare excluded from this pilot.
Impacts:
(Organizational & Technical) / Implementation will impact Academic Affairs, Student Affairs, and SDBOR Technology. (Stakeholders include: faculty, students, staff, administration, Regents, state government and legislature (funding)).
Dependencies: / Implementation of interfaces, daily refreshes of data, and reporting needs.
Assumptions & Constraints: / Implementation will be in one instance of Starfish and where possible, a standard approach to implementation will be utilized. Some configuration may be smart coded in order to provide the flexibility in workflow. In addition, there will be the need for some unique workflow due to referrals.
Training will be essential for faculty, staff and student populations to engage early adoption. If no adoption, the ability to report on metrics will be limited. Therefore, training will occur first for the staff, and just in time training for faculty will occur upon their return for the Fall semester. Students will be provided training during their orientation class.
A progress survey will be submitted to students to allow consistent reporting and better adoption by faculty.
Preliminary Assessment
Pros /
  • Software allows for communication via email.

Cons /
  • Too many emails and surveys will inhibit users from utilizing the system.

Performance
Implications

4.High-level Requirements

  • Starfish will need data interfaced from Colleague, D2L and Pearson MyMathLab.
  • The interfaces will need to pull certain data elements that identify key stakeholders by relationships including university indicator, memberships (such as athletics, trio, etc.).
  • Attributes need to be identified and interfaced into starfish.
  • Reporting will be essential for the university/system.
  • Initial phase will be a roll-out phase and managed at the system level to ensure data is successfully interfaced, reporting data is available, and metrics are defined.
  • Universities that have identified key retention goals where this early alert system may help obtain the objectives, should providethose key data elementsduring this implementation period so the correct data can be interfaced and documented in a report or reporting capability for thatuniversity.
  • Roles will need to be defined for the Administration Role, Success Center/Academic Center (or other name for center), Advisor Roles, University Center Advisor Roles, etc.
  • User flags need to be defined and established in Starfish.
  • System generated flags will need to be defined and established in Starfish.
  • The level hierarchy of the flags will need to be defined and established in Starfish.
  • Email templates will need to be defined in Starfish.

Current Parking Lot Items – for Discussion/Comments and Steps.

Requirement Area / Projected Steps/Comments
AAC / Define the Policy that initiates the generated system flags for grades, attendance if applicable.
IT / Past History – recommendation for 6 years of historical data loaded into Starfish. This needs to be discussed by RIS.
IT/AAC/SAC / If D2L is not used, the midterm and final grades need to come from Colleague. The midterm grade of DEF is not used consistently. Will need to further discuss.
SAC / There is an ability to load free text comments in the system. Training is essential on what should be written. There is a disclaimer in the system that it is FERPA related. We need to be sure that text is not available to all individuals/roles where it should not be.
IT / RIS will need to work on documenting the interface to load students, faculty, staff, etc.
AAC/SAC / This system does not replace Tutor Track/Advising Track (Scheduling Software).
Project Team/IT / Roles, Memberships and Relationships need to be better defined. Research has to be completed by RIS on whether or not Colleague is used consistently for athletics, advisors, trio, vet status, etc.
Project Team/IT / Attributes need to be defined so we can pull the right data from Colleague. We will need a better understanding of the reporting/viewing of data in the system by AAC and SAC. I.e., an attribute would be a student’s GPA. It is demographic data being pulled into Starfish that is viewable by the student and others in the system.
SAC/AAC / There is the ability to have a financial aid referral. We have discussed postponing this one for Phase II either Spring 2013 or Fall 2013. Discussion was to add Admissions and Registration Referrals for Phase II.
All / Reporting. There is a need for more dynamic reporting then what currently exists in Starfish. Dr. Minder has requested a project estimate to understand what it would take to have the system deliver an interface back to SDBOR for reporting or how they might modify their current reporting features for SDBOR.
Project Team/IT / Academic Advising Calendar. We will need to identify an automated process of loading faculty calendars.
Project Team/IT / There needs to be an automated process to remove flags versus a manual removal process.

5.High-Level Deliverables

There are some deliverables that should be established to ensure metrics can be reported at the end of the Pilot Phase.

  • Adoption – Goal that 50% of faculty in the selected pilot phase be engaged in the system outside of the system generated flags. Faculty members logging into the system, submitting flags, etc.
  • This can be measured by a report generation of users in the system.
  • Use of a Progress Survey during the first 6 weeks of the semester to increase early alerts to those students in the first portion of the semester to be flagged. This progress survey will identify the standard flags (Attendance Concern, Missing Assignments, Low Participation, Low Grades/Test Scores). A progress survey is a method for faculty to respond on their students through and email survey. This allows the faculty member a reasonable process to get information into the system.
  • This can be measured by identifying if the progress survey was submitted and percentage of faculty responding.
  • At the end of the semester, conduct a survey with the advising centers to measure the outcomes of their work with the students. Did the early alert in their view facilitate student outcomes?
  • This is to assist understanding if the early alert tool was beneficial in a summative report.

Deliverable Type / Name/Description
Business Process Analysis and Reporting / Model on processes. Creation of BPAs for each process that is defined. There will be 5 types of flags: Generated Flags, Standard Flags, Standard Kudos, University Referrals, and Standard To Do’s.
Status Reports / Reporting to AAC and SAC on status of project.

BPAs and Status Report Attachments will be attached at the end of the document as an amended Project Charge.

6.Timeline

Milestone / Target Date / Date Achieved
Create Project Approach and Charge / 5/16/2012 / 5/23/2012
Identify Manual Standard Flags/Automated Grading Flag (Phase I) / 05/18/2012 / 5/23/2012
Gather Current State / 6/08/2012 / 5/23/2012
Analyze Current State Process / 6/08/2012 / 6/7/2012
Develop Future State Process Model / 6/15/2015 / 6/13/2012
Deliver Findings and Recommendations / 6/28/2012 / 6/27-28/2012
Test Development (Workflow and Technical) / 8/03/2012
Training Development / 8/05/2012
Production / 8/24/2012
Training / 8/24/2012
Evaluation and Assessment of System / 10/31/2012

7.Required Resources and Level of Effort – ESTIMATED ONLY

Most of the required effort will be conducted through webinars and conference calls. The kick-off was the first face-to-face meeting (F2F) and future meetings that are F2F will likely be testing and training oriented.

Groups / University/Units Represented / Description / Est # Hrs
Project Team: / Project Team - Functional / Kick-Off, Training of Product, Working on Defining BPA, Decision Points / 80
Technical Expert(s): / Project Team - IT / Kick-Off, Training of Product, Developing interface, working with consultants to load system, establishing TEST, establishing PROD / 120
Other(s) (please describe non-ITS resources): / AAC and SAC / Decisions on Policy Implications, Reporting Needs, Metrics, etc. / 40
Documentation / Project Management – IT and Functional / BOR staff documenting project status, BPA, etc. / 100
Systems / IT at SDBOR / Networking, LDAP, Systems / 60
Subject Matter/Expert(s): / University Experts / Working with local project team member on BPAs, testing system, documenting decision points, recommending reporting needs, etc. / 60
Stakeholders / University Stakeholders / Training by CBTs, Documents, train-the-trainers, etc. / 8

8.Budget

9.Training

Training will be of great importance to ensure adoption of the technology. Training opportunities will include: Computer Based Training, Train-the-Trainer, Manuals and Quick References. The Steering Committee members will be charged to have the discussion at their university to identify a plan of training, identify a person who will be responsible to manage the training, and timeline associated with the training.

10.ProjectGovernance

Status Report Owner: / Janice Minder
David Hansen/Suzanne Preszler
Status Report Audience: / AAC / SAC
Project Team / Technical Staff
Executive Director / Board of Regents
Steering Committee Member / Division/Units Represented
Mike Isaacson and Lois Flagstad / BHSU Subject Matter Experts
Marilyn Halgerson and Patti Beck / DSU Subject Matter Experts
Kathleen Coughlin and Joann Pomplun / NSU Subject Matter Experts
Pat Beu and Jolie McCoy / SDSMT Subject Matter Experts
Aaron Aure and Jody Owens / SDSU Subject Matter Experts
Steve Ward and Carla Reihe / USD Subject Matter Experts

It is expected that the Functional Steering Committee Member(s) [SC] will go back to the university and communicate and discuss the features of the project to their subject matter experts. This is to facilitate university needs into the project and to ensure full discussions are occurring at the university level. The SC members will then report back to the project team. Training will also be the responsibility of the SC members to their subject matter experts. Tools will be developed for use by the project team and the vendor.

11.Revision of Project Charge Documentation

Version Number / Date / Revision Author / Description
1.0 / 05/14/2012 / JM / Creation of Project Charge Draft
1.1 / 05/23/2012 / JM / Modification based on VP meeting and meeting with Starfish.
1.2 / 06/05/2012 / JM / Addition of Faculty and Academic team members.
1.3 / 06/19/2012 / JM / Updated completion dates.

12.Attachments

Attachment I: BPA on Standard Initiated Flags by Faculty - DRAFT

Attachment II: BPA on Generated Flags for Grades - DRAFT

Attachment III: BPA on Generated Flag for Poor Attendance – DRAFT

Attachment I: BPA on Standard Initiated Flag by Faculty - Draft.

Attachment II: BPA on Generated Flags for Grades – DRAFT

Attachment III: BPA on Generated Flag for Poor Attendance – DRAFT

SDBOR – Early Alert – Retention ProjectPage 1 of 11