Academic Timetabling Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the constraint model never get finished?

Most timetabling projects do not fail on the solver. They fail because half the rules never made it into one. The statement of work says model the institution's scheduling constraints, and nobody costs the political work of extracting them from people who have never had to justify them.

Ask a department chair why a course meets on Tuesday morning and you get rules and habits delivered with identical certainty. The senior professor does not teach before eleven. The two section course must not clash with the departmental seminar. The lab technician supports both chemistry sections, so they cannot run at the same time. Some of that is contractual. Some has genuine academic justification. Some has survived only because nobody has ever seen its cost.

A build forces the classification a spreadsheet never has to make: hard constraint, weighted soft constraint, or preference honoured where possible. That classification is uncomfortable, so it stalls, and a stalled classification means the developer models whatever they were handed. The solver then produces schedules departments reject, and everyone concludes the software does not work.

The fix is procedural rather than technical. Run constraint discovery as its own workstream before implementation, with a named owner per department, a deadline, and a registrar or provost who will arbitrate. Every rule gets an attribution: a policy document, a clause in a collective agreement, an accreditation requirement, or a named person's preference. The rules with nothing behind them get challenged in that room, in July, rather than in week minus six of the term.

What goes wrong with room and course data migration?

The room inventory is always worse than facilities believes. Capacities are recorded from the original fit out and never corrected after a refurbishment took out two rows. Rooms divided into two teaching spaces still exist as one record. Features are held as free text, so a room with a document camera, a room with a doc cam and a room with a visualiser are three capabilities to a solver and one capability to a human. Accessibility attributes are frequently missing, and that is the one category where an error becomes a complaint rather than an inconvenience.

Course data has its own decay. Section codes carry meaning only the department office knows. Cross listed sections appear twice and get scheduled twice. Contact time on the catalogue does not match what actually happens in the room, particularly for laboratory and clinical sessions.

Feed that into a solver and the first run produces a timetable that is technically feasible and physically impossible. Trust never fully recovers, and the registrar goes back to the spreadsheet.

The fix is an audit before the first run rather than after it. Walk a sample of rooms and count seats. Reduce the feature vocabulary to a controlled list the solver can reason about, with a mapping from the free text you already hold. Validate contact time against a term of real usage. Budget this as its own phase with its own days and its own facilities time, because doing it inside implementation means it competes with features and loses.

Why do student information system integrations break after launch?

The timetable and the student information system hold the same facts and start disagreeing within a week of go live. Someone publishes a room change in the scheduling tool and the student record keeps the old room. A section is cancelled in the student system and the timetable still holds a slot for it. Enrolment caps get raised in one place and the assigned room no longer fits.

This happens because the integration is usually built as an export at a point in time rather than an agreement about ownership. Nobody wrote down which system owns section identity, which owns room assignment, which owns meeting pattern, and what should happen when both change between syncs.

There is a second failure that arrives later. The student system gets upgraded, a field changes shape, the nightly job stops running, and nobody notices for eleven days because the published schedule still looks correct until someone walks to a room.

The fix is a written ownership map before any code, one row per field, naming the system of record and the direction of flow. Then build the sync as reconciliation rather than overwrite: compare both sides, apply what the ownership map permits, and raise everything else as an exception a human clears. Add monitoring that alerts when a job does not run at all, not only when a job runs and fails. Silence is the failure mode that costs you a term.

What happens when faculty agreement rules are not covered?

Collective agreements and workload policies contain scheduling rules that are not negotiable, and they are the rules most often left out of scope because they are specific and dull. Minimum gap between an evening class and a morning class for the same instructor. Maximum consecutive teaching hours. Limits on distinct preparations in a term. Rules on how many days a week someone can be required on campus. Notice periods for changing a published assignment.

Leave these out and the system produces schedules that are mathematically excellent and industrially unacceptable. The consequence is not a bug report, it is a grievance, and grievances get settled by reverting to manual scheduling, which is exactly the outcome the project was funded to prevent.

Accreditation adds a second layer in professional programmes. Clinical placement hours, supervised contact requirements and sequencing rules in nursing, education and allied health are constraints with an external auditor attached, and they are the hardest constraints on any campus.

The fix is to name a rules owner outside the project team, usually in human resources (HR) or academic affairs, who signs that the encoded rules match the agreement text. Store each rule with a citation to the clause it came from and an effective date, so a renegotiated agreement becomes a dated configuration change rather than a code change nobody can trace. Then test against last year's real schedule and show which existing assignments the model would have rejected, because that conversation is far cheaper before go live than after.

Should you build custom or configure what you already own?

Configure, if your problem is size rather than shape. A college under roughly four hundred sections a term with stable offerings and spare room capacity does not have a constraint problem, it has an administration problem, and CollegeNET Series25 or Coursedog will handle it. Series25 in particular is strong on space and event requests, which is a genuinely different product category from academic timetable construction, and institutions sometimes discover mid project that requests were their actual pain.

Configure also if you already own an optimisation engine such as Infosilem and never finished the constraint modelling. That is a common and expensive halfway house. Paying to complete the model you already bought is almost always cheaper than starting again, because somebody has to write your rules down regardless of who hosts them. The same applies to Ad Astra if your live question is utilisation and demand analysis rather than construction.

Build when the shape does not fit. Health sciences cohorts, consortium space where another institution's rules apply, several campuses with travel time between them, or a constraint set the vendor's configuration surface cannot express are all points where the packaged model runs out. So is the situation where one room change forces a full manual rebuild, because that tells you the institution's scheduling logic is not executable by anything.

The honest test: describe your constraints to a vendor and ask them to show you where each one lives in their model. If more than a handful have no home, you will be building that part whatever the contract says.

How do hidden costs get into the quote?

The line underpriced most often is constraint discovery, because it looks like meetings rather than engineering. In practice it is weeks of interviews, arbitration and documentation, and it decides whether the solver is useful at all. A quote showing two weeks of requirements for a multi department institution has not costed this.

Room data audit is the second. It is physical work, it needs facilities time you do not control, and it usually gets discovered after the first solver run rather than before it.

The third is infeasibility handling. Your first real run will fail, because a real institution's rules conflict somewhere. A system that reports no solution and stops is worthless. Explaining which constraints are in conflict and what would have to relax is real engineering, and it rarely appears in a fixed price scope.

The fourth is minimal disturbance re-running. Full re-optimisation is straightforward. Re-optimising while pinning the current schedule and finding the smallest set of moves is a different problem, and it is the mode you will actually use in week minus six.

The fifth is examination scheduling, quoted as a small addition and carrying its own rules about consecutive exams and shared conflicts.

Ask for those five as named line items with their own days. If a proposal folds them into implementation, the money is not missing, it just gets found later as a change request when you have less negotiating room.

What separates a build that works from one that fails here?

The builds that work do three things the failures skip.

They scope release one to a single term, the general purpose room pool, and the departments that generate most of the conflicts. Resolving the large majority of collisions in one term earns the right to do the rest. Attempting the whole institution at once means constraint discovery never converges and the project dies in analysis.

They run in parallel before they replace. Build the schedule both ways for one term, compare, and make every difference explainable. Each one is either a rule the model has wrong or a habit the institution cannot defend, and you want both found while the spreadsheet still exists.

They treat the constraint model as institutional property rather than project output. It is written down, attributed, versioned, and owned by a named person after go live. Timetabling systems decay because nobody maintains the rules once the developer leaves, so the model drifts away from policy and the manual overrides return.

Two smaller habits matter more than they should. Keep the manual override, because the registrar will always need it, but record the reason, because those reasons are how the rule set improves. And make every published schedule traceable to the run that produced it with the rule versions attached, so a dispute about why a section moved is a query rather than an argument in a committee.

Get those right and the system outlives the person who commissioned it.