Conrunner Logo

The Final Programme

Michael Abbott

This is not how to do a programme, it's just how Follycon did its programme. If you want to do it another way, go ahead and good luck. In particular, many of these remarks will not apply for conventions of different sizes: especially in terms of how many people to involve, and how much delegating gets done. They also assume an ordinary committee, some of whom form a programming subcommittee.


There's no way to tell you where to get good ideas from, but you will need some. Try to develop a habit of thinking about programming in spare moments, and you'll come up with more of them. Get a group of people together to brainstorm (try to have some device to start ideas flowing), and don't be afraid to look back at what other conventions have done, either to repeat the standard items directly (it's embarrassing to miss out any of the traditional ones by accident) or to try to come up with new programme items, using the old ones for inspiration. You can also do worse than speaking to people you know can do programme items entertainingly, ask them if they'd like to do anything for you, and let them decide the details. This can apply to all kinds of talks, quizzes, games and workshops.


When you've got quite a long list, you need to start thinking about balance. Estimate how many hours of programming you have available in each stream, and how you want to divide it up. After the automatic items such as opening and closing ceremonies, business meeting, Guest of Honour items, awards ceremony, disco and anything else you've decided to do, the rough categories are games, quizzes (which tend to be more serious than games), panels, workshops and talks, all of which can be humorous, serious literary, scientific, fannish (i.e. social), special interest or others: don't let categories cut out items you think will work, just because they don't fit them conveniently.

When you've decided to do an item, give control of it to one of your committee: they have the final say on what happens in it, they write letters about it, and it's up to them to make sure Ops knows what

equipment is needed for it. They should pass any information about its current status on to a central member of the programming subcommittee, who produces notes of the overall programme state regularly: these will eventually become the schedule for Ops and the Green Room.

This work includes beginning to choose people to take part. Very often the participants will be the biggest draw for an item, and you should also try to make sure people will enjoy taking part in and be interesting on the items you ask them to do. This will need co-operation within the committee, both to make sure nobody gets overused (especially Guests), and to get a good spread of people. You can use Feedback forms to get lists of interested people; this is particularly good for quiz or game participants.


Start this early. Follycon spoke to a lot of people before or at Conspiracy, and we were kept busy almost solidly from then on; if you bear in mind that it may take writing to three people in succession to fill a place, the time available seems to shrink greatly. Talking to people face-to-face or on the phone where possible is very useful (and helps get a quick answer) but you should never rely on it as your only communication. Always send a letter to confirm in writing.

Even so, letters may often have to be sent dry. This should include the following: details of the programme item(s) you're asking them about, explanation of why they've been asked, an invitation for them to comment on the item to you (whether or not they will be taking part), who else is likely to be taking part, a return address, and thanks for their time. You should also apologise for writing if they haven't joined the convention yet (as you are then cold-calling them), and you should also ask what times they will be available on programme items, as otherwise you'll find half your participants haven't arrived for the Friday programming.


When you have a fair spread of items with most of their participants determined, start laying out a programme grid and filling it in. To try out different versions, use a filecard for each programme item colour coded with relevant information. You will need to allow for when participants are available, when the rooms can be used (and how early and how late it is worth using them), and for the logistics of moving equipment around. There will also be some items that cannot be easily moved and others that you want to give prime positions to: these should be placed first, though not irrevocably. When placing the others, use the divisions of type given earlier: two hard-science or humorous items should not be placed opposite each other, nor usually in succession. There's a whole range of interests represented at an SF convention (especially an Eastercon), and most people are interested in more than one of these, so will find the occasional clash; but they shouldn't be because of two items covering the same interest. There is also a limitation because of the participants; having someone do two items in a row is dodgy, and any more is entirely unacceptable. There is also a need to watch the overall layout: for example, if you are putting on three quizzes, they should be on three different days, and preferably at different times of day. Some items are also more suitable for some times of the day than others - e.g. silly games tend to go down well just after midnight, but placing a serious panel then would be absurd.

These restrictions may not seem too bad, but it takes a lot of work to get a good programme layout out of them, largely because the programme participants and layouts will be changing at the same time as you are doing it. It's still worth trying to get a layout done early for revision, rather than not doing one till the last minute, as it'll show you if there are any more items needed (or contrariwise if some you were thinking of doing will have to be abandoned), and give you a base to work from. The layout should be checked by as many people as possible, including at least one test run-through, and revised right up until it has to be printed for the Programme Notes - and probably after it as well. Despite the neat headings I've drawn up, the layout, the ideas and balancing and organisation of individual items all go on together, and it's a mistake to treat one as rigid because you're now working on the next.


At about the same time as this, someone should be writing the "teasers": the potted descriptions to go in the Programme Notes. These are very important (even if no-one does actually read the damn thing) and they're useful now, for the reminder letters. These get sent to people who've agreed to your first letter, and tell them that they have been confirmed to do the item. They also include a copy of the relevant teaser (and people running items, rather than just participating, should be offered the chance to rewrite it), and tell them the exact time and place that the item(s) will be. You should remind them again that they can get in touch with you (it can't hurt), and probably give them a warning that there might still be some changes to the time; it may be unlikely, but it'll probably happen at least once, since in some cases you won't be certain that everyone can make your first-choice slot.


Around this time you should also be getting your Green Room team together. Their job is to sit in a pleasant room that should ideally be near the bar and all programme rooms (some hope), and fifteen minutes before an item begins, go looking for any participants who haven't showed up. Take the panellists' drinks orders (make sure they have plenty of bar vouchers), show them to their rooms and deliver the round, and then wind up the item properly. Longer items may also need other drinks orders every hour or so, and for something like a Writers' Workshop, even though the participants may not get drinks bought for them (though the moderator will), it's nice if someone will fetch drinks for them. The Green Room team should work shifts similar to Ops Shift, say three hours at a time, with a half-hour's overlap, and contain one Manager and two or three Green Room Gophers, at least one of whom should be good at identifying faces.


When the programme has entirely settled down (joke), or failing that about two weeks before the convention, prepare the slips to go in participants' membership packs. These should give item name, room, time, role if applicable (e.g. masquerade judge). They should also ask them to go to the Green Room twenty minutes before the item, and ask them to go to the Green Room if they have any problems at any time. People chairing an item should get an extra slip telling them who else is on the panel (in case they want to talk about it beforehand), and giving them the required end time. In most cases this will be 5 minutes before the hour; Follycon went for a strict 5 past to 5 to slot, and this seemed to work well. Your Green Room team shouldn't be too busy otherwise when panels are due to end, and they can give discreet 5 minute and 1 minute warnings. When the item overruns a minute, unless it's obviously in mid wind-up, get Security to pull them off bodily. Perhaps.

You should also prepare anything you want to go into the Newsletter around now, and revise your last set of Programme Notes to make a schedule for the Green Room crew with everything they'll need to know. Bring plenty of copies to the convention.


Now that's been done, everyone understands what to do, and nothing can go wrong. Heh heh heh. This concept might be good enough for Westworld, but isn't for an Eastercon. Some things that can happen:

Hopefully, all these problems will find their way either to Ops or to the Green Room. However, many of them will require authority and familiarity with the programme as a whole that the Green Room manager and even the Duty Committee Member (who may not be part of the programming subcommittee) may not be able to manage. The solution Follycon used was the concept of "Programming Manager", and all such problems got bounced on him. This avoids clashes, and the Programming Manager will also be someone from the programming subcommittee. This means that if a space on a panel opens up suddenly, he'll know what sort of person is wanted to fill it (and often a panel will be planned to include contrasting individuals) and who has already turned down the opportunity by post beforehand. He may consult the committee member in charge of that item, but he acts as a central authority for all programming matters, keeping them under control.

I have said "he" rather than "he or she" in this description because at Follycon this was me, throughout. Having gone through this, I'd suggest that it's better done by two people taking shifts of responsibility, and passing over news at change-over, as I got distinctly frazzled. For the record, I had to handle about fifteen serious problems (most of them quite quickly), which I think shows that the concept is worthwhile.

The final rule is to get everything done as early as you can. Look at me, I promised Ian this article by two days ago, and so now I'm having to speed through it with a lot more rush than I'd like. Sorry, Ian!


This page updated on 09 July 1999