Planning
How long it takes to get a timetable live
Infrastructure is days. Data is weeks. And the stage that dominates the calendar is almost never the one an evaluation committee spends its time asking about.
The short answer, and then the useful one
Infrastructure and an imported timetable: a few days. We set up hosting, import an institution's existing timetable and put its web pages in place in that time, routinely. It is the part we are better at than anyone else in our market, and it is also the least interesting part of the answer.
A first full cycle: a few weeks, and how few depends almost entirely on your data and your integrations rather than on anything the software does. An institution that arrives with clean module and room data and a working student-information-system export is at the fast end. One that discovers mid-project that nobody owns the room list is not.
Year two: dramatically shorter, because the structure carries forward and only the changes need attention.
Where the calendar actually goes
Days 1–2 — infrastructure
Hosting, accounts, the institution's web pages. Cloud or on-premises is a policy decision rather than a technical one, and it does not change this number much.
Days 2–5 — structure and resources
Programmes, years, routes, modules, groups; rooms with real capacities; staff with departments. Fast if it comes out of the student information system, slow if it comes out of four spreadsheets with different spellings of the same building.
Days 3–7 — training, in parallel
Three to five days for the people who will run it. It overlaps the stage above rather than following it, and it should: people learn the software faster on their own data.
Weeks 2–4 — availability collection
THE STAGE THAT DOMINATES. Two to three weeks of asking teaching staff when they can teach, and it is not shortened by anything technical except removing the asking. Self-service availability is the single largest lever on this whole timeline.
Days, once availability is in — constraints and generation
Classifying rules as hard or soft is an afternoon of argument and a day of entry. Generation itself is minutes. This is the part evaluations concentrate on and it is not where the time goes.
Week 4–5 — verification and publication
Let lecturers check their own schedules before release. An objection before publication costs an email; the same objection after publication costs a room change, a notification and somebody's morning.
Why availability dominates, and what to do about it
Ask a timetabling office to guess where the effort goes and they will describe generation and conflict resolution. Measure it and it is availability collection almost every time: a fortnight of chasing, then manual entry of what came back, then corrections arriving after the spreadsheet was closed.
This is why the arithmetic of a timetabling project is counter-intuitive. If generation already takes under a minute, making the algorithm faster saves nothing anybody will notice. Removing a three-week collection phase saves three weeks. Open a form to teaching staff, let them enter their own free hours, and chase the non-responders with one automated reminder instead of a hundred phone calls. How that works.
It has a second benefit that is worth as much: availability somebody entered themselves is a rule you can treat as absolute without arguing about it later.
What makes it slower
- No owner for the room list. Estates has one list, the timetabling office has another, and they disagree about six rooms. Settle it in week one, not week four.
- Integration discovered late. Every department that pulls something from the timetable is a dependency. Ask them all, in writing, at the start. What is involved.
- Treating every preference as a hard rule. The fastest way to make a timetable unsolvable, and the diagnosis takes longer than the fix. The distinction.
- Approval chains. If publication needs three signatures, the calendar contains three waits that no software shortens.
- Doing it during term. Everything above is two to three times slower when the people involved are also teaching.
What year two looks like
This is the number worth asking every vendor for, because it is the one you will live with. Year one buys you a structure; year two should be a transition rather than a rebuild — last year's programmes, modules, groups, rooms and constraints carried forward, with the changes applied on top and the calendar re-anchored to the new year's dates. What that involves.
An institution that has to re-enter its structure every September has bought a tool rather than a system, and the difference will not appear in the first year's invoice.
If you are replacing an existing system
Add the migration inventory to the front of all of this: every link, feed, screen and integration currently pointing at the old system. It is the half of a migration that is forgotten in the plan and remembered in week one, and it is written up separately in what actually has to move.
Want to see this working?
Book a 45-minute online presentation and we will walk through it against your institution's own scheduling problem.