Student Retention Early Alert
Student Retention – Early Alert
Project Charge Document
1.
Project Information
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
2.
Project Team
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
SDBOR – Early Alert – Retention Project
Page 1 of 11
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
Background:
Description
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.
SDBOR – Early Alert – Retention Project
Page 2 of 11
Project Area
Description
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.
Objective:
Scope:
Included in scope:
Excluded from 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.
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/faculty
are 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 
Cons 
Software allows for communication via email.
Too many emails and surveys will inhibit users from utilizing the
system.
Performance
Implications
SDBOR – Early Alert – Retention Project
Page 3 of 11
4.
High-level Requirements
o Starfish will need data interfaced from Colleague, D2L and Pearson MyMathLab.
o The interfaces will need to pull certain data elements that identify key stakeholders by relationships
including university indicator, memberships (such as athletics, trio, etc.).
o Attributes need to be identified and interfaced into starfish.
o Reporting will be essential for the university/system.
o 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.
o Universities that have identified key retention goals where this early alert system may help obtain
the objectives, should provide those key data elements during this implementation period so the
correct data can be interfaced and documented in a report or reporting capability for that university.
o 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.
o User flags need to be defined and established in Starfish.
o System generated flags will need to be defined and established in Starfish.
o The level hierarchy of the flags will need to be defined and established in Starfish.
o Email templates will need to be defined in Starfish.
Current Parking Lot Items – for Discussion/Comments and Steps.
Requirement Area
AAC
Projected Steps/Comments
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.
SDBOR – Early Alert – Retention Project
Page 4 of 11
5.
Requirement Area
Projected Steps/Comments
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.
High-Level Deliverables
There are some deliverables that should be established to ensure metrics can be reported at the end of the
Pilot Phase.
o 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.
o 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.
o 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.
SDBOR – Early Alert – Retention Project
Page 5 of 11
Deliverable Type
Name/Description
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
7.
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
Analyze Current State Process
6/08/2012
6/08/2012
5/23/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
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
Project Team - Functional
Description
Kick-Off, Training of Product,
Working on Defining BPA,
Decision Points
Est # Hrs
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
Project Team:
SDBOR – Early Alert – Retention Project
Page 6 of 11
Groups
University/Units Represented
Description
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
Est # Hrs
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.
Project Governance
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
Mike Isaacson and Lois Flagstad
Division/Units Represented
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
SDBOR – Early Alert – Retention Project
Page 7 of 11
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.
12.
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.
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
SDBOR – Early Alert – Retention Project
Page 8 of 11
Attachment I: BPA on Standard Initiated Flag by Faculty - Draft.
SDBOR – Early Alert – Retention Project
Page 9 of 11
Attachment II: BPA on Generated Flags for Grades – DRAFT
SDBOR – Early Alert – Retention Project
Page 10 of 11
Attachment III: BPA on Generated Flag for Poor Attendance – DRAFT
SDBOR – Early Alert – Retention Project
Page 11 of 11