Automated timetabling is a complex undertaking that often requires considerable project management and extensive business process changes that affect every aspect of timetable planning and construction. A successful implementation could potentially take years. There is also a steep learning curve for users trying to automate both the time and space aspects of the timetable simultaneously, which can be overwhelming.
However, it is often possible to split the timetabling problem into two stages, with an initial focus on scheduling (selecting the times for teaching events) before rooming (finding suitable free rooms for the pre-scheduled events). There will be some overlap and feedback between the two stages where events that can’t be roomed may need to be rescheduled (or where events that must happen in certain rooms, like specialist labs, can only be scheduled in very specific time slots), but for most academic timetables these will be the exceptions (and planning around scarce or specialist rooms is often already a part of the scheduling process).
Many academic institutions use exactly this model, where scheduling is a distributed task for academics and administrative staff to arrive at a stable timetable by a specified deadline. After the deadline, it is handed over to another business unit (often within Estates & Facilities or its equivalent) which is tasked with finding the rooms for all the events on the timetable. They may identify bottlenecks, and/or other issues, which will need to be fed back to the schedulers for a resolution.
Models like that evolve because there is a significant difference in complexity between the two tasks. As an example, imagine an event (like a seminar) for a module called Biochemistry 2 at a university which is subject to the following scheduling constraints:
- Delivered by a part-time staff member contracted to not work on Wednesdays and Fridays.
- Needs to occur at least 48 hours after the associated practical class (so the results from experiments growing bacterial cultures in Petri dishes can be discussed).
- Some students are in the Microbiology class which will be off-site on Monday mornings for placement at a private laboratory- which is too far away to get back in time for Monday afternoon seminars.
- Cannot be scheduled at the same time as a list of 55 other events the students take as part of their modular courses (each with a similar list of scheduling constraints).
- Allows a break for students (and staff) with more than 4 hours of continuous teaching, or at least a 30-minute break sometime between 12:00 and 14:00.
- A policy dictates the seminar has half the students in the lecture for the module, with the other half having their seminar occur concurrently (delivered by a different staff member with their own availability and teaching load); allowing the two staff members to swap the student groups in the alternate weeks.
The person or team responsible for selecting a suitable time slot for this event (scheduling it) will need to be aware of all these constraints and could end up spending many hours in meetings and back-and-forth negotiations with other staff to finally decide on a suitable slot- such as 10:00-11:00 on a Thursday. This may have to be repeated several times if the event needs to move for any reason. The (often hidden) cumulative time and effort needed to schedule and maintain events across even a medium-sized institution with about 5,000 events can be significant and demonstrates the potential time savings automation can bring.
In contrast to all that, the rooming constraints for the same event are likely to relatively simple, such as:
- Requires a room with a data projector, seating at least 20 people, and in (or be located as near as possible to) the Science building.
These are just examples (albeit all from a real-world experience), but there could be many more at play for potentially tens of thousands of events. In addition to these so-called hard constraints that ensure a feasible timetable, real-world timetabling will also involve different soft constraints or preferences to improve the timetable’s quality, such as clustering teaching to allow free days or minimising the time spent walking between rooms for students and staff on any given day.
The main benefit of a two-stage approach is that all the scheduling complexity can be devolved and distributed to individual departments, or subject areas, where the myriad of local constraints and preferences can all be handled in a ‘black box’ process that simply outputs a timetable at some point in the year. Typical downsides of keeping this complexity out of sight and out of mind are disparities in timetable quality between different departments, wasted time, the risk of entrenching poor practices that remain hidden, and an inability to accurately report on (or effect changes to) timetabling at an institutional level.
Automating the scheduling process is a good way to bring it all to light, but it requires identifying, translating, and capturing all those constraints as rules in the timetable system. And this must be done by individual users who not only need to be trained and empowered to vet and differentiate the valid hard constraints from preferences but have the time and resources at their disposal to interview potentially hundreds of academic staff about their modules’ timetabling needs or use their authority to impose standard patterns from a timetabling policy, or (more likely) to maintain a careful balance between the two. None of this can, or should be, attempted lightly; nor can it be achieved quickly.
On the other hand, the rooming process is relatively simple and self-contained when compared to scheduling. Someone responsible for rooming the event used in the example above does not need to know anything about the time needed to grow bacterial cultures in Petri dishes, the contracted hours of the teaching staff, or the rules about lunch breaks and teaching times, or the need for some students to be off-site on Mondays. All that is irrelevant to them; they just need to find a suitable free room for the event at 10:00-11:00 on Thursdays, or report back to the scheduler(s) if no such room can be found and try again when new times are suggested.
Academic teaching space is a costly resource to build and maintain. The need to squeeze more efficient use out of estates has resulted in a move away from locally owned departmental spaces to models where non-specialist rooms are shared by multiple departments based on need and availability (as opposed to the perceived ownership or right of use). This can take the form of institutional spaces shared by all departments, overlapping zones based on geographic proximity, or a combination of the two. This, in turn, has necessitated more centralised management to ensure fair use and global reporting for space management and planning, and the responsibility for rooming often rests with a single central team or business unit who may, or may not, also be responsible for scheduling.
Either way, such a team can benefit from rooming-only automation with relatively little effort. CELCAT Automation provides tools to quickly convert an existing scheduled timetable into a series of so-called templates and constraints. These can then be refined and sent to the automation engine for rooming only, whilst leaving all the events at their manually scheduled times. CELCAT Automation is also very flexible, allowing users to automate any chosen subset of their events. Additionally, Automation does not remove the element of human control from the timetable. It assigns rooms to events in a fast batch process guided by constraints and weights but, after that, the affected events can continue to be edited just like any other CELCAT event- which includes changing the room(s) manually or with the Room Adviser.
From a process perspective, this can bring significant time savings. At one of our clients, the entire process to room about 1,500 scheduled events into shared rooms takes less than an hour, shaving an estimated two weeks from the team’s timetable work every year. In addition to time savings, automation allows users to gain valuable insights into their timetable through reporting, identifying bottlenecks, and quickly running ‘what-if’ modelling scenarios to measure the effects of removing or adding rooms to the estate.
For institutions looking to move to full automated timetabling, which includes scheduling, implementing rooming-only automation as a first step can serve as a ‘quick win’ to build trust and convince stakeholders of the value of automation. It also helps to gradually increase the users’ technical familiarity and competency with the software and concepts, reducing the need for complex training. Lastly, from a risk management perspective, it can initially be run in parallel with the usual manual rooming processes with relatively little extra effort, allowing for a safe objective comparison of the outcomes before deciding which of the final two timetables to publish and use.