1 / 16

Academic Workload Planning The Derby Experience

Academic Workload Planning The Derby Experience. Presented by John Hurd TRAC Manager. Session Outline. Why Change to AWP benefits and process. Overview of System and current position. Problems encountered. How the system grew in complexity.

dreama
Download Presentation

Academic Workload Planning The Derby Experience

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Academic Workload PlanningThe Derby Experience Presented by John Hurd TRAC Manager

  2. Session Outline • Why Change to AWP benefits and process. • Overview of System and current position. • Problems encountered. • How the system grew in complexity. • What can make a planning tool become a recording tool? • The Academic Sign Off process. • Data lock down.

  3. Why Change from TAS? • The TAS system was unpopular and difficult to manage. • Collection was in % terms and not readily usable for any other purpose – a box ticking exercise. • We didn’t collect by research sponsor type – a compliance issue, so a change was needed. • We could “piggy back” on the proposed AWP project and use stopping TAS as a positive.

  4. Why Change to AWP? • The Executive wanted to introduce a more standardised approach to work practices – a review of the Academic contract was already underway. • The University was looking to introduce a standardised workload planning approach. • The need to cost staff time to activity on a more accurate basis to better inform financial performance reporting and resource allocation.

  5. Overview of System and current position • System has been live for 4 years to 13/14 • It informs staff coding to activity • It delivers TRAC information • Some areas use it as a planning tool • Others see it as a recording tool • It lives within our PS student software

  6. Overview of System and current position - 2 • System has several tabs that identify activity type • Classroom teaching • Non classroom teaching publicly funded • Non classroom teaching non-publicly funded • PGR supervision • Research • Scholarly activity/additional LTA • Income generation • Leadership/ general duties

  7. Overview of System and current position - 3 • The Managers control data for their staff • They enter data and validate it with each individual as part of the DPR. • Faculty admin set up new academics and link them to a manager • Faculty Deans sign off the final outputs

  8. Where are the benefits • A consistent approach to workload planning across all Faculties. • Standard allowances built in to the system help achieve this. • Built into the University Student system allowed access to standard data e.g. module codes. • To be able to be linked across other systems e.g. timetabling. • To replace the TAS system for TRAC.

  9. Process - who was involved • Sponsored at a senior level – executive member. • Led by an academic manager (assistant dean) to emphasise it as an academic system. • Data identified as owned and used by the faculties. • Involved the unions early and they had a representative on the project team. • Finance involvement to ensure TRAC compliance and nominal coding.

  10. Problems Encountered • System became over complex particularly: • Linking to standing tables – module codes and nominal codes. • Too many boxes to complete, many not required by most academics - over detailed. • Building in controls – limiting views and options by faculty or individuals.

  11. Problems on Roll Out • System did not fit other users – lack of early consultation. • The number of boxes increased as each area added its own specific requirements. • The overall system ownership and control was not clearly defined. • knowledge too centralised. • Lack of ownership by both faculty and subject area managers – lacked local support. • Academics wary of the use of the information.

  12. How a planning tool becomes a recording tool! • Not intuitive in terms of allocating load. • Managers could not easily compare allocations across staff. • Local spreadsheets remained active with the outputs from these used to complete the forms. • System viewed as complex and time consuming. • Management use of the data available was limited.

  13. Academic sign off process - 1 • July/August • Provisional workloads entered by Line Manager after discussion with individual academics at DPR (Development & Performance Review. • Final sign off for the previous year. • October/November • Review actual workloads and changes in planned activity and update system at DPR.

  14. Academic sign off process - 2 • March/April • Manager and academic discuss actual work completed for period 2. • Agree plan for remainder of the year. • Agree provisional plan for the following year. • Managers update individual plans.

  15. Securing the Data – lock down • Data kept in 3 periods • Each period has a status • Provisional • Agreed • Delivered • After each period the data is set to delivered. • Once set to delivered can only be changed if finance open the form for amendment.

  16. Questions will be taken at the session starting at 3pm

More Related