PROGRAMME AND PROGRAMME OPS

by Colin Harris & Ben Yalow

1. INTRODUCTION

This article is concerned with the Intersection programme and programme ops. As with many areas of the con, programming was generally run according to a British rather than American pattern, and this produced the usual mixture of successes and failures. In the first part of the article I (Colin) have summarised the things that we did, followed by the lessons that we can learn. For contrast, Ben Yalow then provides a description of one American approach, as used for Noreascon 3. Ben and I then try to take a reasonably objective look at the merits of the two approaches before wrapping the whole thing up with some hopefully useful conclusions.

Before beginning, I should note that I have concentrated on conrunning issues related to programme and programme ops. I have deliberately avoided discussions of programme content (item profiles, balance of tracks, use of workshops, etc, etc) which I do not believe belong here, although I could write at least as long an article on these issues ...

2. INTERSECTION

In this section, I have summarised how the programme was run in a fairly descriptive manner (the lessons follow later ...). To provide a structure, I have divided the review into pre-, at-- and post- con activities. I have included some feedback received from attendees in the post- con section.

Pre-Con

Under pre-con activities I would include programme team structure, planning, participant liaison, and use of computer tools and databases. The programme team structure was divided into areas (tracks in US parlance) for planning purposes. This does not mean that we wanted the tracks to be explicitly visible to the membership; indeed we deliberately mixed them across the programme rooms and avoided identifying tracks as such in the ReadMe. The motivation for tracking was to enable small teams of dedicated specialists to work on developing areas of' the programme for which they had particular enthusiasm, experience, or contacts.

Above the areas sat the head of' programme whose purpose was to co-ordinate the whole thing. Unfortunately we got through several of these ... as we did through area heads. This may be a consequence of having started too early; programme was up and running 2-3 years out and I think that for most of the people involved this was a waste of time. The case is not clear-cut however; on the one hand we developed an adequate literary programme almost from scratch in 9 months, on the other the science team worked as a unit for almost 3 years and produced an exceptional result. My personal view is that programme needs to be "represented" from an early stage so as to have input into decisions on function space, room allocation, etc, but that most effort committed more than 18 months out is wasted as the key programming resource - participants - cannot be reliably pinned down at this point.

Once things did get under way, the intention was for each area to perform initial contacts and programme development for its own items, then to have a cut-off point after which control would be centralised and all contacts and changes would go through the programme head who controlled the programme database. This cut-off point would coincide with the first full attempt at scheduling, as it is at this point that detailed co-ordination becomes necessary to avoid scheduling conflicts.

The approach to participant liaison reflected this scheme. Prior to the cut-off point, each area was free to have dialogue with all potential participants in an ad-hoc manner; afterwards, the intention was for two standardised, centralised mailings, firstly for formal invitations to participate and secondly for confirmations. The theoretical gain from this approach was again that during the early phase of programme development, participants could be given a greater degree of individual attention than would otherwise be the case. Some areas, particularly science, too this idea of focus one stage further by delegating responsibility for individual items or groups of items to specific people.

With respect to computer tools, the objective was to use the standard Worldcon programme database for the centralised planning stage, consolidated mailings, and at-con programme ops. (For techies, this is a Dbase V system running HSR for report generation, and configured with standard tables for programme and participant information and a portfolio of useful reports for e.g. room allocations, participant schedules, mailout templates, and pink sheets).

The programme database caused intense headaches, which were regrettably almost entirely due to misuse and errors of judgement: rather than to problems with the database itself. (although 1 personally found the Dbase / R&R combination rather primitive, and would prefer something such as MS Access which can be more easily integrated with other applications). Without: wanting to dwell on the problems in this area, I cannot. avoid some elaboration of the difficulties, as they include some wider lessons.

Firstly, there were extensive delays in getting the programme computer and the database installed. Secondly the people who would have to use the system did not familiarise themselves with it until. they needed to use it in anger, at which point they were immediately faced with imminent critical deadlines. Thirdly, the people responsible for using the system were not competent to use it. Fourthly, the fact: that we only intended to use the system starting from the cut-off point meant that the database was totally empty at this point, so that a very large amount of' data had to be entered in one go rather than having been built up from a couple of years out.

Another area affected by the database problems was the ReadMe production. The database was essentially incompatible with Ian Sorenson's software, so that all 800 items had to be reformatted by hand on entry. This difficult task was greatly exacerbated by the fact. that the database was not consistent or accurate at the point where the ReadMe was to be generated, and it is only thanks to Ian working unreasonable hours and an obliging printer that: we had any programme information at all in the document that was produced. This nearly came close to being one of the biggest screwups of the convention

At-Con

In at-con issues 1 include programme ops, green room, room allocation and scheduling. I have included these last two items here because they have most: significance at-con although they are of course determined pre-con. 1: assume that there will be a separate AFN article on green room so I have only given it brief' coverage here.

Prior to the con, some rather grandiose plans were put forward for programme ops; these would have involved Hall Managers who would have been responsible for supervising groups of programme rooms. Failure to recruit any significant number of staff for programme ops pre-con rapidly ruled this out on the day, however, and the actual role of programme ops' reduced to overall participant liaison, programme schedule changes and pink Sheet production. Green room, which was located next to programme ops, effectively had control of items from 30 minutes out; at this stage there's not much you can do if anything goes wrong.

With respect to staffing, programme ops had its own team, which was supposed to take over the programme as contained in the database and run with it: from there. The development teams were to check in on a regular basis (several times a day) to clear up any questions that the programme ops team could not deal with. In practice, this worked adequately but no more; the use of separate development teams backfired in that it was hard for the programme ops team to know who they should go to for detailed information.

Room allocation and scheduling was an area that worked out, but shouldn't have. Problems with the computer meant that we lacked the tools to make the job easy, and meetings which were supposed to schedule the major items didn't seem to achieve anything, In the end, scheduling was performed by one person producing a complete draft schedule which was then circulated for comment, then updated, circulated again, etc. The schedule itself' was produced and maintained manually using a simple spreadsheet, as the database was not functional at that time (about 3 months out from the con). As the database problems dragged on, the mailings and even the ReadMe input continued to be produced in an ad-hoc manner; the database was only eventually brought: into a usable state at: the start of the convention, although it was then an important resource for resolving at-con problems and producing pink sheets.

With respect to the content of' the schedule, the main points of note were as follows.
Registration's need to use Hall 1 for the first 2 days of the convention meant that we had to put programme into the cavernous Hall 5. We survived this, but it was highly detrimental to most of the items that were in there; audiences of 500-800 were totally lost in the space.
The Hall. 3 acoustic problems were dreadful. lt was well known that there would be some problems here, but no-one could have believed just how bad they would be, and these rooms were essential in terms of providing mid-size spaces (100 - 200) which were otherwise poorly catered for
Main programme was run on a 9 hour / day basis, 10 am - 7 pm, with one hour s1ots. Some items ran for 90 minutes or 2 hours, but these were scheduled so as to start the next item on the next one hour boundary. Keeping all rooms in synch means a slight rush between items, but is administratively simple and easy to understand for members and staff alike. Our GoH schedules were constrained by Gerry Anderson's limited availability during the convention, and this forced us to put Gerry on directly after Chip Delany's speech. Unfortunately, no-one had warned us that Chip's speeches tend to over-run, and we were forced to guillotine him. We have been criticised for this, but it was a no-win situation with one GoH following another. The lesson is always put a slippable item on after a major one, so you don't have to cut a key speaker short.

Post-Con

Post-con activities are limited to participant follow-up and feedback. With respect to follow-up, a con surplus raises the possibility of refunds. It should be noted that US professionals are much more inclined to expect refunds or reduced rate memberships than Europeans. It is important. to maintain clear records of who actually did what: if you want to be able to do refunds after the con; I'm not sure that we did this adequately. At least one programme area made a point of sending a thank-you letter to Participants after the con. This generated a very positive response, mainly to the effect that it was a pleasant change for the con to remember this little nicety. Given the amount of goodwill generated, 1: was surprised that this gesture isn't more common Feedback from participants was variable according to areas. The heterogeneity of the feedback reflected the tracked approach to development; literary and science programmes were very well received, fan was reasonable, media was poor. Feedback from members and con reviewers has indicated that the science programme was exceptional, the rest reasonable with some high points.

3. INTERSECTION LESSONS

Moving on, I have tried to pull together here some basic lessons from Intersection as far as the conrunning aspects of programme and programme ops are concerned.

1. Having separate programme development teams is a mixed blessing. On the plus side, enthusiastic specialists can give in-depth attention to their' items and work more closely than normal with the participants in developing the programme. On the minus side, there is no common ownership of problems, so weak areas are left to sink or swim where an integrated team would provide a safety net to ensure all areas were covered to an adequate degree.

2. If you are going to use a database, get it in place and tested well before you need it, and allow time for loading up all the necessary data to drive it (e.g. participant names and addresses). And you 'must' get: it in capable hands. The Worldcon database in particular has been developed for and typically used by professional computer systems people; it is not suitable for use by amateurs.

3. The hand-over point. where a centralised system takes over from separate areas needs to be carefully and thoroughly handled. This needs a lot of effort.

4. Refining the schedule is a job that should be done by no more than 1-2 people; it involves a long and tedious process of optimisation that is not suited to a committee environment.

5. Programme ops was a near-disaster which was bailed out by two things: (1) the science and literary programmes both worked extremely hard pre-con to get participants fully confirmed and briefed, so there were relatively few problems to resolve in these areas at: the con itself (2) we had experienced US staff helping with programme ops who were able to cover the deficiencies in the material they were given (many thanks to Ben, Mark, and Janice in particular). The database needs to be in good shape at the start of the con. The scope of and procedures for programme ops need to be clearly defined. There should be a giant-size programme grid posted on the programme ops wall. that can be marked up as required. (Intersection did not have this, so it was impossible for programme staff to come in and easily check on an aspect of the programme).

6. Points where computerised data has to be transferred between different packages and systems must be identified early, and procedures to facilitate the transfer developed. For programme, this primarily means an interface to the membership database for picking up participant information and an interface to the ReadMe DTP system for dumping programme information. Dry runs of the latter procedure are essential as the ReadMe is always produced on a tight schedule.


4 AN AMERICAN VIEW

Since the question of how Program works at non-UK Worldcons has come up, let me (Ben) describe the way many (I can't say all, since I wasn't close enough to the program team for some recent Worldcons to know for sure) recent US Worldcons have had things organised. I can then indicate how things work for some smaller cons in the US. As always, smaller cons tend to be more variable.

At Noreascon (where I co-headed Program with Priscilla Olson), or Magicon (another one where I'm very familiar with how things worked in that division), the program essentially took place in the usual two phases ^ pre-con and at-con. During the pre-con phase, the track managers worked to generate ideas for the program, concentrating mainly on "their" tracks. An idea might be a complete items (a title/topic, and a set of participants), or a partial one (fewer than desired participants). At the same time, the various program team members generated a list of people who seemed like they would be good to have on the program, and submitted their names to the central division staff. About a year out, the first batch of invitations went out, with more coming as new possibilities were identified (either because someone on program came up with them, or they volunteered, or someone else 'on' the program suggested they would be good to invite, and we agreed).

This process continued until the spring, at which time we had a lot of participants, and a lot of items. We then had a big program weekend in mid-Spring, where we got as many of the program team as we could to come to Boston for a weekend, and we ( collectively) put together a first draft of the program (we assigned people to the partial items, and filled up most of the program grid, although we left some space to add more items). Since we had lots of people there together (for the first time, since the program team was scattered throughout the US) then everybody was able to help fill in all of the items. So if we needed an editor who knew hard SF, we could ask the collective, and if' someone working on the fan program had an idea, that was fine. People didn't: 'own' tracks; they were merely the people most responsible for coming up with the ideas.

After the weekend-long program frenzy was over, we had a tentative first draft program. It still hadn't been checked for validity (nobody with a conflict with himself, or an item before arrival, or more items than they were willing to do, etc.) So we (mostly Priscilla) spent a few weeks fixing it up, and then, late Friday, we put together a mailing to all participants with the draft schedule.

And we started getting back problems. Lots of changes. So we added people to items, and took them off, and moved items, and created new ones, and killed old ones that: had too few people and weren't worth saving, etc. We checked with the track managers if it seemed appropriate, but, if it was just a panel that could be touched by anyone (and only a small number couldn't), then we didn't have to wait for that. And we sent out mail. to people whose items we changed, letting them know about major changes, although probably not minor ones. Some changes were easy (deleting the 6th person off a panel was usually easy). Some were hard (when Scott Card had to change what day he was coming, and we had several items specifically for him, we ended up having to move a few dozen, due to cascading effects from moving the few with him on them - but it was worth it to make those items work) .

And, late July, we had a solid program. So we did another mass mailing, telling people that this was their last chance, and that things were almost final. And gave them 2 weeks to make any 'important' changes and they'd better contact us ASAP. And we had only several dozen changes to make in the next two weeks And, about 2 weeks before the con, program division (with help) spent a weekend putting together the pocket program. We did it, since we had the last stuff to go in - the other areas got their stuff in to us, and we just incorporated it. It meant that we could wait until the very last minute, and the pocket program would be almost completely accurate. And we found a printer who could do 1 week delivery, at a good price, so we could give him the originals on Monday, and have them the Monday before we opened Registration.

And we also printed up the individual participant schedules, and sticky labels for the backs of badges with individual schedules, and name signs for each person on each item (plus some spares). All of which could be generated straight by reports we ran against the program databases.

At-con, there were 3 main areas. Tech handled the stuff for all of the program items. Green Room gave someplace for the participants to assemble (and hang out if they felt like), where we had food/drink, and where we could check to see if they were all there. We also kept lists of items that needed more volunteers, and people could tell us if they wanted to be added or dropped from items. And Green Room had the signs for the next hour's items, and gave them to the moderators for each panel, and told them how to get there. They would also send somebody out in time to give a "5 minutes" sign to the two dozen or so items that were ending each hour.

And Program Ops handled all the schedule changes. They added people to items, dropped people, put new people on the program, added items, etc. In general, since they knew enough about the program, they didn't need to consult with anyone about it. But usually at least: one of Priscilla, Patty Wells (asst div mgr), or I was around, if they wanted to bump any decisions up. But mostly they didn't have to - they knew enough about the program that they did what needed to be done, and only used us when they needed to say "No" to someone who needed special handling They also updated the program wall (post-its on a grid that represented the entire program), and the program in the master computer that was the authoritative version of the program, and from which, every night, we produced the pink sheets with the next day's Program. And since Program Tech works out of' Program Ops, they can look at the wall, and @really' know what's being planned.

So, on site, Program Ops makes the program Changes, and Green Room gets people there. And the track managers are available, if possible, for consultation on decisions, but aren't necessary, except where they have items that they want to be consulted - a few dozen out of many hundred.

As for smaller cons:
As you have fewer items, the functions tend to be combined. The track managers are likely to also be the program ops people. And the division staff (which becomes the department staff) is likely to be the same people again. And the green room may move in to the same room as program ops if there isn't enough demand to justify another room. For a medium scale program (5-10 or so items at once), almost all of the functions get combined. For a small program like Armadillocon, where 1 was at last weekend, which had 5 tracks + 2 readings + autographings for about 400 people or so, they didn't have a green room or program ops at all, and didn't really need one.


COMMON GROUND ?

This section pulls out some contrasts and comparisons between the US and British approaches. A particular aim is to identify those pitfalls that lay in wait for European Worldcon runners in terms of different conrunning traditions.

Dealing With Participants
Part of participant liaison is getting your participants in the first place. US cons usually start this process with a mass mailing to a large number of potential programme participants (this can extend to approaching 1000 people in extreme cases) Although large, however, this mailing is targetted, e.g. at SFFWA writers for the literary programme. Intersection chose the more normal British approach of putting a volunteer form in the PR. As this was to all members, many US pros ignored it, expecting instead to receive a professionals mailing which never showed up.

It is important to appreciate that US professionals can treat conventions as tax-deductible if they are invited in an official capacity. They therefore want and need to be sent suitable invitation letters and to appear on the programme. This is not such an issue for British (and presumably European) pros.

Staffing

The programme team must include US members, at least in areas such as the literary programme where the US will provide 50% of the programme participants. US staff can brief the team on potential participants in terms of the nature of their work, suitability for items, etc, and can help to chase up possible participants who are difficult to make contact with. (Many thanks here to Mark + Priscilla Olson). Without this, one can be faced with many volunteers who you've never heard of' and who get very bruised egos when you tell them so, or worse still, participants who you find out too late that you shouldn't have allowed within a mile of a microphone.


PROGRAMME DETAILS FOR INTERSECTION

By Jenny Glover

The Fan programme at Intersection, the World Science Fiction convention in Glasgow this August is divided into three parts.

The morning part will be organised by Jackie McRobert, Alison Freebairn and Ian Weller and will run in the specially constructed fan room in Hall IV of the SECC (that's the one with the bars, refreshment areas and fan fair) from about 10am to about 2pm. It will be targeted at people who don't know that they are fans yet, and will have introductory items on different sorts of fandom and interesting set pieces like a treasure hunt, or pick of the day or "Around the Con in 18 hours".

For the afternoon, the programme will continue in this Hall IV room, and is being co-ordinated by Jennv and Steve Glover. There will he a mixture of items, from snapshot photographs of fandom in different countries to longer discussions on-approaches to fanzines or con running. Topics covered will include fan history and timebinding, censorship and communication of all kinds; there will be some special items like a daily soap opera. This will blend from the end of the morning programme to 6pm, though there will be no sharp cut-off if the conversation is interesting.

The evening fan programme will take place in the Central Hotel, in the centre of town and will be arranged by Lilian Edwards and Christina Lake. This will last from about 8pm to very late and will be partly in the bar which overlooks the station, partly in the room adjoining. Programme items might include "Fannish Blind Date" or a review of the year, talks, discussions and lots of fannish interaction.

In addition, there is a fan bar in Hall IV which will have both smoking and non-smoking areas together with a fan lounge just outside the fan programme area. John D Rickett is looking after the fan lounge: he's friendly and approachable and one of his main interests in life (apart from drinking very strong coffee) is talking with people. Steve Green has also volunteered to produce quote cards and they will, hopefully, be all over the place: on the screens, on the tables, in people's hands ....

Greg Pickersgill will in charge of the fanzine reference library. He is one of the people everyone knows: intensely knowledgeable with fanzines, Nova winner, experienced with cons. That library will only be for reference, but there will be a fanzine table in the fan lounge where fanzines will be looking for new homes and there will be displays, charts, leaflets and flyers on the display screens and tables.


SCIENCE PROGRAMME VIEW OF INTERSECTION

By Dave Clements

This is a report from one of the members of the Intersection Science Programme sub-committee. It is a personal view and in no way represents a corporate report from the Science Programming Area. Nevertheless, I would imagine there would be substantial agreement between the four Sci committee members on many of these items.

The report is divided up into a number of sections that look at different parts of the process of making up the Intersection Science Programme. They are: Structure, which considers the management and communications system that operated over the long run-up to the convention; Construction which looks at the process of devising the programme; Execution, which examines how things ran at the convention and deals with the problems specific to Intersection and the SECC.

Structure

The Science programming committee was established shortly after Intersection won the bid, and we kept all members on board until the end of the convention. This must be an achievement in itself, since during the same time we had 4 Programme Division Heads, and every other programming area head changed at least once over this time. We are thus in an ideal position to be able to examine the make-up of the programming division and how various management styles affected the running of the division.

The appointment of the division head is a crucial one, and it is essential that the division head's vision and that of the programming areas matches up. This is more important in the early stages of the organisation. The first Programme Head had a radically different view of programming to that of the Sci area, and I am sure that if he had not resigned at an early stage then there would have been major conflicts. The main problem here was that there was absolutely no discussion between the then head and the people under him. In a corporate management situation this is a workable arrangement, since there is an element of coercion involved and a clear heirarchy of authority. This is not possible in a voluntary organisation like a Worldcon, and the inevitable result of a conflict of wills would be a ruined programme or mass resignations from the committee until someone is found who wants to build a programme more in tune with the boss' vision. An initial period of discussion is thus necessary during which everyone works out what they want to do, and how they want to do it. The programme at Intersection was a success not because the management was done right, but because the management of programming changed so often that those on the ground level carried on doing what they wanted and then the management had a fait accompli to deal with. We were lucky it worked.

The second thing about the Programme Head changes was that for 2 years there seemed to be very little continuity of information from one to the next. Questions sent up the heirarchy via one division head didn't get answered, or weren't known about, by the next, and paperwork was not transferred. This is plain wrong, and shouldn't be too hard to fix.

Indeed, general communication was the main source of friction within the programming division for much of the event. This is partly inevitable, since, by the end of it, those actively working on the programme were scattered over something like a million square miles (the length of the UK, and spreading out into Germany). It would have been impossible to run this structure without email. The speed, ease, and cheapness of this medium enabled us to work not only together but to discuss things with authors and other programme participants all over the world. I sometimes thing I did more Intersection work when away from Europe than when I was here! The problem here is that if it is agreed to use email as a communication medium then everyone must use it. Many of the problems in the last few months leading up to the con came as a result of the DH either having an unreliable connection, or failing to use email properly. It might not be true that (as reported in the con newsletter) email was read only when someone phoned up and complained about something not being done, but that is what it felt like to those of us on the periphery.

It is also necessary for all those working on the Programme to be aware of their own strengths and weaknesses, enthusiasms and turn-offs, and to try to delegate as much as possible of what they don't like or don't want to do to those people who are able and interested in doing it. The creation of the programming database is an ideal test case here. It was clear by about July that programming central didn't have the necessary experience to do the databasing job well, but they continued to persevere with it instead of trying to find some people who were both able and enthusiastic about doing it. All credit to their perseverance and determination to get the job done. It may be that it was not possible to find replacement database experts at that stage. However when we got to the con, the database had become such a major feature in programming central's world view that it was pursued to the detriment of all else. This was the case even when there were experts at using the software (indeed its authors) willing and able to take up the challenge and allow other things, like the tech schedule (which, if email had been read, was a problem flagged from a month before) to receive the attention which they so direly needed. Many of the cock0ups with equipment on the first day of the convention, Thursday, could have been avoided if Tech had known where equipment was needed and when. Indeed it might be useful at a future con to have a tech-use run-through on the first day before programming starts, just to make sure everything is where it needs to be and is working. This might also find such problems as self-destructing slide projectors that are sufficiently good that they cannot be moved until cool.

One thing that Intersection didn't seem to demonstrate was the difference between planning your programme from three years out (science programming) and less than one year out (lit programming). Both areas have received significant plaudits from attendees, perhaps slightly more to sci, but then I'm biased that way. The significant thing is that Sci wasn't three times better because we'd been working on it three times longer. Great things can be done in a little time, and all credit to Colin for doing so. I suspect he was run ragged by this though.

Construction

The first thing we did after winning the bid and realising we'd committed ourselves to running a Worldcon science programme was to ask for help, lots of it, and from all over the world. This was achieved by establishing an email discussion list with previous Worldcon science programme organisers, programmers from other conventions and many generally interested parties. This group functioned as a permanent floating science programming committee meeting and brainstorming team throughout the run up to the convention, and was probably the single most useful thing we came up with. It allowed us to come up with a varied science programme with many different formats that was the product of 80 brains, not just 4, and so was much better at reflecting the broad interests that a Worldcon audience will have. I t also allowed us to reach, thorough recommendations and suggestions, many people who we would not otherwise have contacted. I may seem to be gushing here, but this really was incredibly useful and successful. So much so in fact, that we are keeping the mailing group open to act as a resource for any other convention, Worldcon or otherwise, that wants our help (plug).

We also adopted the idea of "item sponsors", so that there was a specific person for each item who was enthusiastic about it, who knew something about the subject matter and about who might make good panellists, and who took on the responsibility of organising the item. The four main organisers filled this job for the bulk of the items between them, but something approaching 50% of them were "sponsored" by members of the email discussion list. This spread the organisational load, and also added to the varied flavour of the items. It also meant we had automatic backup moderators (at least for those items that weren't moderated by their sponsors already), since the sponsors were able to fill this role if the planned moderator was unavailable. This helped on a number of occasions.

Another experiment we tried was to centralise the science programme database, such as it was, at a publicly accessible WWW site. This also proved very successful for communications within the Sci committee, with participants, and with the outside world. It was less successful in communicating with the rest of the programming committee and with other parts of Intersection. It is not clear to me whether this was a result of the usual communications chaos that seemed to reign around the Read Me and other aspects of programming in the run-up to the convention, but the easy access we all had to the data allowed us to simply email a whole new version of our item descriptions to Ian Sorenson when the original was lost. This was clearly a rushed compromise, and led to such immortal typos as "one end of a wormhole will become Greg Benford", but at least the descriptions were there. It also allowed each member of the Sci programme team to download a fully up-to-date version of the Sci programme and bring it with them to the convention for their own and others' use. An extra copy was also pinned up outside the Sci programme room, which proved to be very useful for all hard-line Sci programme fans.

Being a fully wired programming committee did, though, have its problems, principally in interfacing with other parts of the con that were not connected or had to be dragged kicking and screaming into the mid-90's. discussions with several of the other programming areas and with programme central were the most obvious aspects of this problem. For someone working the con from Germany and trying to keep the phone bill down, this was a serious problem. If email is to be the mainstay of inter-committee communications, and it looks as if that is likely to be true in the future, then appropriate items in the budget must be there from square one to make sure all necessary people are connected. They must also be ready to use email etc as a proper means of communication, and have any necessary technical help on hand for the inevitable problems. Indeed it might be worth opting for a more expensive commercial Internet Service if it is simpler to use and more reliable than an otherwise cheaper competitor.

Execution

when it came to actually running the programme at Intersection several other problems surfaced. In the run-up to the convention, there had been substantial problems with the programming database. It is unclear to me, as I was somewhat distant from these, quite what these problems were caused by, but it seemed likely that at least some of them were caused by inadequate documentation of the software we were using (not unexpected since it was a fannishly written programme), inexperience, and lack of general computer experience by the programming staffers who were working on it (with increasingly frequent fire-fighting by more expert members of the committee), and a general lack of delegation of the data entry and updating tasks.

If this were all we had to contend with, then we would have coped better (more on why later on). However, at the time when substantial effort was being spent on the database, some of which was perhaps misdirected, other problems requiring the attention of the upper programming echelons were going unattended. Principal among these were Tech issues. Several weeks before the convention, John Bray drew the programming executive's attention to the fact that we needed to provide an equipment timetable to Tech so that things would all be ready in time. This was not done. Instead, so much time was being spent on the database that not even a draft version was sent to Tech, so we ended up having to improvise a Tech timetable on the day. Indeed, the tech side on the first day of the convention was nearly a disaster. Sending programme details to Ian for the Read Me was also an area that fell down badly, and it was only possible to salvage the situation for Science because we had a completely parallel database for our own items on our Web site.

I think this demonstrates that Division Heads need to keep their eyes on the broad problems of their division and to delegate jobs effectively to their team. It is no good throwing ineffective all-nighters on the programming database if many other areas needing attention are going by the board at the same time.

At the convention centre several of these problems became clearer and (using Zoocon terminology) we were able to throw expert people-points at them. Without the extra set-up day that was provided by many people arriving on the Tuesday rather than the Wednesday, things would have gone a lot worse in programming. It would not be an exaggeration to say that this saved us from chaos on the first day.

It also became clear that soundprooofing was going to be a serious problem. And the true horror only became apparent on the first full day. All credit to the rapid provision of PA, however a little thought in the design of the rooms in Hall 3, and perhaps some experiments during site visits, might have helped further. For example, the design of the Hall 3 rooms with speakers facing towards each other rather than away from each other did not help things.

As to communication at the con on the day, I have to say that the original plan for bleepers and phones was a total shambles. I was beeped a total of 3 times, only one of which was a genuine message and not a false alarm or wrong number. For this call, it proved impossible to find a phone or radio carrier to get through to the office! By the time I arrived, others had solved the problem, so this didn't work quite as planned. After the first two days, when a pile of spare radios appeared in programming (I'm not sure if they were meant to be there at the start or what) I grabbed one of these and was directly contactable for the rest of the con. This made things much easier. Ensuring an effective communication system during the con should be a priority. Other parts of the con may have had one, but programming didn't until we rehashed it with resources I'm not sure we were meant to have.

(Fiona: actually you were. The timing of the arrival of a pile of radios in programming was not unrelated to my having given Tech a list of departmental radio allocations and having directed Security to go round and relieve people of their radios who were not on that list)

Finally one further thought. We should put together a set of Zoocon cards based on the unique experiences of Intersection. Examples range from handling Channel 4 to the death of a major author, and I'm sure there's much more material out there.