Workload Allocation Monitoring (WAM) Prototype

I decided to start writing a workload allocation monitoring system for Higher Education. I found one written as part of a JISC project at Cambridge, but despite my experience with PHP I found it difficult to set-up, a bit crude (sorry) and hard to maintain. It was clearly very flexible, and I wanted something flexible, simple and clean.

So I decided I'd try writing something quickly using the Python django framework. This is my first web-app written in Python and so I dare say I would do some things differently with more experience, but I have now reached the point where I have a workable prototype that I can start to use myself. I've got to say, I found django to be pretty neat.

At its heart is a list of the loads against Academic Staff in a department or school. The idea is to try and increase transparency. There are problems with this approach: some known irregularities of loading can be for confidential reasons; small numbers of staff with key skills can cause issues as well, but it is intended to provide a basis.

Overall loads for staff.

Overall loads for staff.

 

 

 

 

While classically the word semester implies that there are two of them, most Universities operate a three semester system with the third covering the Summer. Unevenness in loading over the Summer is another cause of potential trouble, so the system tries to show loading as spread across semesters. A scaled column accounts for staff who do not have a 100% FTE contribution but their hours are up-scaled for comparison.

Naturally staff will want to see some granularity of these loads and they are broken into individual activities that are allocated to given members of staff.

Breakdown of activities for a staff member.

Breakdown of activities for a staff member.

An individual activity can be specified as occupying a number of hours, or alternatively a percentage of a staff member's time. It can occupy one or more semesters (in which case it is spread evenly across them). Types can be allocated for activities to help track contributions of different types. It might be that an activity is related to a module or study, or not.

Activities are long term parts of work allocated hours or a percentage of time.

Activities are long term parts of work allocated hours or a percentage of time.

Speaking of modules basic information is stored for these, and another issue I think will help, tracking the submission of exams and coursework through various QA processes.

At a glance the most recent information about the exam and coursework status can be seen.

At a glance the most recent information about the exam and coursework status can be seen.

While activities are considered to be events with long engagements, another issue for staff are tasks that are allocated to them, usually of comparatively short duration. It can be hard to staff to remember all of these tasks, and hard for manager to follow up their completion, especially without annoying staff who have completed them already.

Tasks can be allocated against individual members of staff or groups or both.

Tasks can be allocated against individual members of staff or groups or both.

The web-app will allow tasks to be defined against one person, many people, categories of people and so on.

A list of tasks and their deadlines.

A list of tasks and their deadlines.

 

 

 

 

 

It is possible to easily see which tasks are still open and whether their deadline has come and gone.

The staff required to complete a task are shown, and those that have indicated completion. The system politely nags those still outstanding.

The staff required to complete a task are shown, and those that have indicated completion. The system politely nags those still outstanding.

A look at a given task will show who has completed it and who still needs to.

A given staff member can sign off their own task.

A given staff member can sign off their own task.

 

It is often the case that admin and clerical staff check off colleagues who have responded to a given call, so the system allows for staff with given permissions to indicate someone has having completed the task. Alternatively the member of staff can do this for themselves.

So while it is still a bit rough and ready I've reached the point where the system is stable enough for use. Of course the challenge comes when we consider the assumptions to come up with the hours and percentage loading in the first place. So I hope to pick the brains of some colleagues about this and start testing the system.

I've yet to make a formal release, but the code is Affero GPL (you can use the code free of restrictions (and charge) but cannot deprive others of the same freedom on derivative works) so feel free to have a look at it.

My roadmap for an initial release can be found on foss.ulster.ac.uk, where I will eventually host the code as well, but at the moment it can be found at GitHub. My previous post detailed how to get the app to work with a central authentication system your University likely has, or something similar.

Yeah... design and CSS is not my strongest skill, more work to be done on that.

Share and enjoy.

Follow me!

2 thoughts on “Workload Allocation Monitoring (WAM) Prototype

  1. Pingback: Manually completing a botched django migration | Proving the Obviously Untrue
  2. Pingback: Workload Allocation Modelling Update – Scalability | Proving the Obviously Untrue

Leave a Reply to Manually completing a botched django migration | Proving the Obviously Untrue Cancel reply

Your email address will not be published. Required fields are marked *