To understand the Progression subsystem it is necessary to understand the following key terms. Other Progression terms are explained in the subsystem glossary.

Evaluating progress is done through the creation and application of progression rules, using those means of measuring progress determined as best suited to an institution's needs. Identifying the rules and measures used is one aspect of the current progression practices of an institution that need to be clearly identified to enable the defining of the parameters within which this subsystem will function when implemented. Two other major aspects that require clear identification are the timing of progression measurement within the institution and the consequences for a student of failing to make progress. This process of identifying current progression practices provides institutions with an opportunity to review current practice and implement changes to take advantage of the flexibility provided by Callista's Progression subsystem.

The following scenarios attempt to raise the major issues that should be considered by the range of staff involved in this process. The ways in which the Progression subsystem can support differing structures can then be more clearly understood.

This institution has a single progression review cycle, applying to all students, regardless of course type, faculty or course version. This review cycle is an annual one. The evaluation process begins late in the academic year as the student results (for units studied in that academic year) are being submitted by academic staff. It continues until results are finalised. A student is only evaluated when all of his/her results have been finalised. Amended results (e.g. as the result of special consideration being given) mean the student's progression is re-evaluated and penalties amended. This occurs until the end of January to enable students to re-enrol for the next academic period.

Student progress is evaluated using a set of clearly defined rules. These rules fall into two major categories - those that require a student to maintain a minimum Grade Point Average and those that evaluate unit failures. The rules within each category vary in that they are applied to different faculties (organisational units). The minimum GPA required and the unit failure rules applied by each faculty are published in faculty handbooks.

The penalties associated with the failing of any progression rule are clearly defined (and published) and consistently applied. This university allows a student to appeal against penalties (described in Callista as student progression outcomes) but does not provide any period in which a student can show cause, before the application of a progression outcome. This appeal process follows the imposition of penalties by a progression review committee or its executive officer. Minor breaches of progression rules (that result in a warning to the student) are automatically approved. The faculty progression committee reviews more serious breaches and this committee approves or waives the related outcomes. An appeal might result in the lifting of the outcome or the dismissal of the appeal and the outcome's continued application.

Because this is a centralised structure the Progression subsystem could be implemented in a similar 'centralised' way. The variation in this structure occurs at the rule application level (i.e. the point at which a progression rule is related to either a course version or a faculty). There is no variation in either the timing of the application or in the outcome to be applied when a rule is failed. These are standard across the whole system.

Therefore the cycle of progression and progression outcomes can be established at higher levels in the progression subsystem and inherited by the rule application level. A single system configuration can be defined (none is required at organisational unit or course version levels). The progression rules can be created (based on consultation with staff across the institution) within three main groups. The progression calendar can be assigned to each of the categories. Each rule can have required progression outcomes (penalties) assigned to it. When the rule applications are established (by linking each required rule to a course version or organisational unit) the timing of the application and the progression outcomes resulting from failure can be inherited from the category and / or rule.

To implement this in Callista:

In this institution the academic staff, teaching each course, carries out the process of evaluating student progression. The timing of this evaluation, the means used to measure progress and the penalties applied when a student fails to make progress may differ between courses. The institution has a broad policy statement regarding progression, but allows the implementation of those general principles to be decided by staff at course level. This process is transparent and consistent (the practices followed at each course level are published for students) but highly decentralised.

For some courses, the student's GPA and unit failure measures are evaluated and a period to show cause is available. In other courses, the student's WAM is the sole measure of progress and those students are able to show cause and appeal (within 14 days) if they are deemed to be making unsatisfactory progress. In some courses offered in 2 semester teaching periods, a student is evaluated at the end of every teaching period. Other courses evaluate their students annually, even where units are offered in semester periods. Some evaluate progress using only finalised student results; some use a mix of recommended and finalised results. Amended results (e.g. as the result of special consideration being given) mean the student's progression is re-evaluated. Where penalties should be amended, this is done to enable students to re-enrol for the next academic period.

This highly de-centralised structure for evaluating progression must rely much less on the inheritance of progression calendars and outcomes, than Callista University can. This structure must allow for wide variation in the means used to measure progression, the timing of evaluation and the consequences of not making progress. In this university, each course could have a different progression 'system', so the Progression subsystem must be configured to allow this wide variety of approaches.

This means configuration settings need to be defined at the system and course version levels. Configuration settings at the organisational unit level may also be applicable, where the set of courses offered by a single organisational unit have the same configuration requirements.

Many of the required progression rules may be created within the five identified categories, creating a 'pool' of generally available rules able to be linked to different courses. However there may be some that can be created at rule application level as they are only required for a single course. The rule application level (where a rule is linked to a course version) is the logical point at which the progression calendars and required progression outcomes (penalties) would be assigned in this institution. Calendars and outcomes are generally specific to a course, so inheritance from another level (a rule category for instance) is not the most logical structure in this case. New course versions offered could have the progression calendars and outcomes created and/or assigned as part of the process of creating a new course structure.

To implement this in Callista:

Subsequent use of the subsystem then operates within those established structures.

Subsequent topics describe these tasks in sequence. Commonly this cycle of tasks will be repeated throughout the period of progression evaluation, as not all student course attempts will be ready to be evaluated in the first processing cycle. Additionally, some student course attempts may require re-evaluation because an applicable unit attempt result has been updated or existing advanced standing details have been modified. Either of these changes (after an initial rule check has been done for a student course attempt in the progression period) initiates the system creation of a progression ToDo record for that student. These ToDo records in turn trigger the re-evaluation.

Note in the following discussion, the use of the general term 'student' refers to a student course attempt. An individual student may have more than one course attempt. The processes of the progression subsystem apply to a single student course attempt.

Generally this process would not require parameter settings to limit processing to a particular progression period. The relevant progression period/s are determined based on the structure established when the progression subsystem was configured and calendars set up. Those student course attempts that require evaluation within this period (and are ready to be tested, based on the configuration applicable) are identified and each applicable rule is tested.

The exception report can list either those who failed rules or all tested students (a parameter selection). The default setting lists only those who fail a progression rule. Where required the report from a previous running of the job can be reproduced with this setting reversed.

This report describes, for each student course attempt and rule tested, the outcome of the rule check and the action taken as a result. It also provides a summary of the number of students tested and the numbers who fail progression rules. It can be used in preparation for progression review panel meetings. For example from this report staff can identify those students whose lack of progress is so severe that the panel may require additional information on which to base a decision about recommended progression outcomes (such as producing an academic history).

Example:
Against STUDENT ID 99ABC (who passed all tested rules) the message 'All tested rules were passed' is reported
Against STUDENT ID 99DEF (who failed a progression rule) the message 'Rule(s) were failed. The following recommended outcomes were added.' is reported.
Against STUDENT ID 99GHI (who failed a progression rule) the message ''Rule(s) were failed. The following automatically approved outcomes will be applied.' is reported.

Where a Show Cause period is allowed (through the configuration applicable to a student) the Show Cause expiry date is derived and the student will have a progression status of SHOWCAUSE. Where there is no available show cause period, the progression status reflects the approved outcome (e.g. SUSPENDED). (Where an appeal period is available, the Appeal expiry date is derived but the progression status reflects the approved outcome or the availability of a show cause period.)

The second group is those who've failed more serious progression rules with associated outcomes that are not set to apply automatically. Student progression outcomes of this type are created with a PENDING decision status. These require further action before they can be applied. A student in this group would have a progression status of UNDCONSID. Student 99DEF is from this group.

In this form student course attempts with pending progression outcomes can be retrieved based on criteria entered by the user. The criteria options include organisational unit, progression period, course type, course code, location and attendance mode.

To assist the decision-making process, a recommended decision (Approve or Waive) is selected for each outcome. Details of the rule application and the resulting outcome under consideration can be viewed using overlay screens. The recommended decision can be accepted or altered as required.

When each record has been reviewed and the agreed decision status set, all records can be updated through the use of the Process command button. Those that have outcomes approved may have their progression status updated. This can be to SHOWCAUSE where configuration applicable to the student allows a show cause period and it has not expired. Where show cause is not available it updates to a status that reflects this outcome, unless a more severe approved outcome already exists for this student course attempt. Those where the outcome was waived will have their progression status restored to its previous setting (where no other outcomes are pending or active the status becomes GOODSTAND).

The decision is made (and recorded in this form) to approve the recommended suspension for Student ID 99DEF (as part of approving or waiving outcomes for a larger group of students). This student is allowed a period in which to show cause, so her progression status becomes SHOWCAUSE, until the expiry of that period (calculated as being 14 days after this outcome was approved).

Where the submission is dismissed, this approved outcome can now be applied (either immediately using the Apply command button on this form or as part of a batch applied through the next run of the job PRGJ6800). The student's progression status will update from SHOWCAUSE to the relevant status for the outcome.

Student ID 99DEF made a submission within the allowed show cause period, but the review panel dismissed it. The decision to dismiss the submission was recorded on the system (but the outcome was not manually applied). Student ID 99DEF's progression status automatically updated to SUSPENSION. The outcome will be applied when PRGJ6800 is next run.

This job should be scheduled as a regular nightly job. It will apply all APPROVED outcomes that do not yet have an applied date set. The type of outcome being applied determines the action taken (for example whether a person encumbrance is created and whether the student course attempt is discontinued). This is described in the documentation for the job. Where possible (and relevant) an Expiry Date for the outcome (and any associated encumbrance) is derived.

This job checks for the existence of a show cause and/or appeal period that may delay the application of this outcome. This occurs where the configuration settings do not allow an outcome to be applied before a show cause and/or appeal. If a relevant period is currently available to the student, the job does not apply the outcome. Instead that student record remains as an APPROVED progression outcome to be applied subsequently, after the show cause or appeal period is completed. These periods are considered completed when either the student's submission has been dismissed and that decision has been recorded or when the expiry date of the period has passed without any submission being made.

The exception report produced can be used to identify those outcomes that could not be applied. The cause of these errors is described in an explanatory message. The most common cause of errors is where the process attempts to apply an outcome with associated encumbrance effects that clash with an existing outcome for the same student. The process resolves some clashes by expiring the existing encumbrance then applying the new. Those that cannot be resolved are not applied and are reported as errors. These outcomes remain as APPROVED and the clash must be resolved manually. In reviewing the errors and determining subsequent action, the possible actions that may be taken are to expire the existing outcome (and then apply the new) or to waive the new outcome and allow the existing outcome to remain in force. Both can be done through form PRGF6610 (navigate to this form from PRGF6600 after retrieving the required student course attempt).

This job also lifts an encumbrance and/ or discontinuation from a student where a previously applied progression outcome has been cancelled.

Where the appeal is dismissed, this applied outcome remains in force. The student's progression status remains set to the relevant status for the outcome.

Where the appeal is upheld, the decision status for the outcome must be set to CANCELLED. The student's progression status reverts to the status that applied before this outcome was approved (GOODSTAND unless another approved outcome exists). The outcome can be lifted immediately by using the Apply command button on the form, or it will be lifted in the subsequent running of the job PRGJ6800.

There may be circumstances where the decision is made to revoke an already approved progression outcome. This can be done for a single student, using form PRGF6610 (accessed through PRGF6600). A progression outcome that has been approved but not yet applied can have the Decision Status reset to PENDING or WAIVED. An outcome that is reset to pending will be re-presented whenever the bulk approval form (PRGF6700) is used to retrieve records awaiting a decision. Waiving the outcome means it will not be re-presented for consideration.

An outcome that has been both approved and applied must have the Decision Status set to CANCELLED. The subsequent running of PRGJ6800 processes this cancelled decision status and lifts associated encumbrances.

Some outcomes cannot have an expiry date derived (as they have no duration values) and must be expired using form PRGF6610. Entering an expiry date against the progression outcome (rather than the method described above where the decision status is altered) would usually be the better method. The decision status then accurately reflects the decisions that were made in relation to this student progression outcome - it was not cancelled, it has expired.

This method can also be used to expire an existing outcome to allow the application of another incompatible outcome.

Non-rule related outcomes are created in form PRGF6610, accessed from PRGF6600 using the Manual Outcome navigation button. The situations that prompt the application of a progression outcome unrelated to progression rule failure will vary from institution to institution. Academic encumbrances can only be applied through the progression subsystem. Where an encumbrance of this type is required (but unrelated to failing a progression rule) this method can be used to apply one.

Once created, these outcomes can be updated and applied either in these forms or through the bulk processes described above.

This form allows rule checking to be run in standard mode - testing whether a student has completed requirements. It can also be run in predictive mode based on both current enrolled and already completed units. The result of the rule check displays on the form.