I’ve prepared the session schedule for a number of conferences, including this year’s Southwest Fox, several DevCons, and at least one GLGDW. When I prepare a conference schedule, I work with a set of rules, some of which are obvious (no speaker can give two simultaneous sessions) and some of which are not (no speaker should have sessions right before and right after lunch).

The goal, of course, is to create a schedule that works for both the speakers and the attendees. Here’s my list, and the rationale for each:

No speaker has two consecutive sessions, including before and after lunch. Speakers generally like to have the slot before a session as a chance to take a final look at their notes, run through examples again, and get themselves psyched (as well as go to the bathroom, comb hair, etc.). In addition, unless the sessions are in the same room, two in a row presents set-up/break-down difficulties. As for lunchtime, typically, speakers with before lunch sessions are among the last to make it to lunch, while speakers with after lunch sessions need to be among the first to leave. Having both just makes it unpleasant for that speaker.

With repeated sessions, the same pair of sessions do not appear in the same two slots. That is, if session A and session B are given in the same slot the first time, they’re in different slots the second time. This rule is a little stricter than it needs to be for attendees, but the goal is to avoid giving people the problem of not being able to attend session A if they attend session B.

A corollary to the last rule is that no two unrepeated sessions go in the same time slot. That is, if some sessions are being given only once, each of them appears in a different time slot. The reasoning for this is obvious. If two were given at the same time, no one could attend both of them.

If possible, no speaker should have more than one 8 AM session. That first morning slot is tough. It means getting up in time to actually be coherent by 8. Most speakers would prefer to never have 8 AM sessions. By spreading them around, no one can complain. A corollary here is that if I’m both writing the schedule and speaking, I get an 8 AM session. If I don’t share the pain myself, how can I expect speakers not to complain? For Southwest Fox 2007, not only did I have an 8 AM session, but Rick (Schummer) had two of them. While that broke this rule, it did cut down on complaints from other speakers. (That wasn’t, of course, why I did it. I just couldn’t get the schedule to work out right any other way, and I knew Rick wouldn’t complain.)

If possible, no speaker should have more than two sessions in any day. Giving a session is actually hard work. Two in a day is plenty.

If session A provides background information for session B, schedule at least the first repeat of session A before the first repeat of session B.

In any time slot, try to have a diverse set of topics. If there are tracks, try to have each topic in a time slot come from a different track. Depending on the number of tracks and the number of topics in each, this may or may not be possible. Even when I can’t put all different tracks in a time slot, I try never to have more than two from the same track at the same time. (Rick told me that he was really impressed when he saw the boards for the rooms. We’d color-coded the topics by track and he noticed that each room was heavily one color. He hadn’t noticed the pattern just looking at the schedule.)

As much as possible, repeats go in the same room as the first time. This fits into the track motif. Back when presentations were done on computers provided by the conference, it also cut down the number of machines speakers had to test before the conference. Even now, it does cut down on the number of possible computer-projector compatibility problems.

Give all the sessions once before repeating any sessions. This is a rule that usually has to be broken a little. It’s rare to have the number and distribution of sessions work out so that you can draw a straight line and say “first time, above the line; second time, below the line.” In addition, if a speaker needs to arrive late or leave early, this rule, as well as the “no more than two sessions a day” rule may have to go.

Try to have the two repeats of a session on different days. This allows people who’ve attended a session to tell others about it and build audience for the second repeat. (And I guess the reverse is true, too—if a session is awful, it lets people find out.) For a conference like Southwest Fox, which is only two-and-a-half days, this rule is hard to follow, but I still use it as a guideline.

So, given all this, how do I make the schedule? Believe it or not, paper and pencil. I prepare a grid for each day, and print out the list of sessions. Normally, I print the list organized a couple of different ways. This year, I had a list by speaker and a list by track.

Then I start penciling topics into slots, following the rules. As conflicts arise, I erase and try again. Sometimes, it’s exceptionally difficult, especially when several speakers have special scheduling needs. For whatever reason, this year’s Southwest fell into place quite easily.

Once I think I have the schedule done, I go back through it, checking it against the major rules. If it passes, I have somebody else take a look at it. For Southwest, that was Rick and Doug. Rick says his way of checking the schedule is to see whether he can (theoretically, anyway) get to all the sessions he wants to see.

My scheduling experience has made me both more and less sympathetic to the schedules made by others. That is, I know the difficulty of getting it right, so I’m forgiving about small glitches. But I also know it can be done, so I get pretty annoyed by conference schedules that seem carelessly thrown together rather than being the product of conscious effort.

Categories: Uncategorized

1 Comment

Doug Hennig · December 11, 2007 at 7:00 pm

Wow! Great detailed description of the process. This is something every conference organizer should read!

Leave a Reply

Avatar placeholder

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.