I’ve only been involved in running one code camp, but I think we learned a lot, and it went well enough to be able to recommend some guidelines. This first post will list my guidelines for the preparation steps. It assumes you’re already involved in running a user group. I’ll follow up with posts about running things on the day of the event, and then follow-up steps to be done after the event.

Get Help
The number one rule — do not try to do this yourself! There is no way to successfully run a significant event without the help of others. In addition to our core team (Leo, Louis and I), Louis recruited the help of a couple of really nice, helpful, and diligent people from the UCONN School of Business office — Vicki and Sylvia.

Find a Mentor
If you’re running a code camp for the first time, getting input from experienced facilitators is invaluable. We were fortunate to have the support of Peter Laudati and Bill Zack, who ran the code camps for the NYC .NET Developer Group. Don Demsak, experienced with his NJ events also provided some valuable insight. I think it also helped that I was present early at the NYC code camps to help a bit with their preparation, and to observe some of the steps they had to take before the events began.

Pick a Date
Check for other events in your area. Check with user group leaders, local regional directors, local Microsoft Developer Evangelists, other members of the development community, and sites such as Community Megaphone to make sure that your event won’t overlap with other area events.

Make a List
Make a list of everything you can possibly think of that would be needed — every action step, from beginning to end. You can use these posts as a checklist. These also contain items we forgot about or didn’t realize we needed until it was too late.

Pick a Venue
If you’re already running a user group, you may already have a venue that’s ideal for a code camp. If not, the costs could increase a lot, and you’ll need more contributors to make this work. We are extremely fortunate that we can use the facilities at UCONN. Virtually every room is equipped with projectors and white boards, so the speakers can basically just plug in and power up. Otherwise, you’ll have to rent or borrow projectors (at least a couple more than you may use for your user group meetings), and would possibly need to find a different location with a few rooms to use, preferably large enough to fit 25 to 30 attendees in each.

Create a Website
I recommend obtaining a URL for the sole purpose of the code camp. Try to get one with a similar name to your user group site, and definitely cross-link. This is where you should post the original announcement, the “call for speakers” announcement, and the eventual the list of speakers / sessions, the session schedule, presentation material, and all other info pertaining to the event.

Call for Speakers
About six weeks before the event, send out a call for speakers announcement to all the people on your mailing list, known speakers in your area, other user group leaders in your area, local regional directors, and local Microsoft Developer Evangelists. Blog about it, post the announcements on message forums frequented by your targeted community (if it’s allowed by the forum), and ask others to blog about it. In the announcement, suggest topics that define the nature of the event and that reflect current industry interests. Capture the following info: name, company, email, phone, track level (basic, intermediate, advanced), session name, session description, and bio. A phone number is important. I made phone calls to everyone a couple of days before the event to confirm and make sure there weren’t any unanswered last minute questions. Email is great, but sometimes a phone call right before the big day helps close any loops.

Code Camp Questionnaire
This may not always be needed, but we were surprised with the number of responses to our call for speakers. We had 19 people offer up about 35 different topics in total, and wanted to take the pulse of the community to see which of the offered topics they’d be most interested in, so we could pare it down. We created a spreadsheet listing both the speakers and available topics, and asked people to rank their top ten, giving 10 points to the topic they’re most interested in, down to 1 point for their least. We sent out this spreadsheet with our emailing of the internal announcement, described below. In hindsight, we should have also sent out the detailed session abstracts along with it.

Microsoft Group Events Account
If you don’t have one already that you use for user group registration, create an account at the Microsoft Group Events site. You can also give other members of your team their own accounts so that they could also update the event info. Add this event to your list, and set the enrollment limit up to 50% higher than the amount you can handle (and the amount you state). We allowed for 150 enrollments, and 122 signed up, 9 then canceled, and about 80 showed up. From what I understand, this is typical. The site also generates automatic reminders, and looks professional.

Internal Announcement
At about the same time, you may want to post an “internal announcement” — that is, only to members of your user group. You want to give your local community the first shot to enroll before opening it up to the general public, since they’re the main group you’re doing this for. Remember — this is for the community, by the community. Post a special announcement on your user group’s website which will already have a cross-link to the new code camp website, and announce it at user group meetings.

Call for Contributors
Code camps are free to the general public, but they are not free to run. Your costs will include food (including the speaker dinner) and possibly the facility. We were lucky enough that UCONN was willing to let us use the facilities in exchange for publicity about their programs, and a questionnaire on our eval forms. The remaining costs is where sponsors are your best friend, although due to the nature of code camps, they aren’t really sponsors — they’re more like contributors. Local companies can be extremely helpful in this regard, and you’ll want to post a thank you on the home page. Also, software vendors are great for either contributing funds or swag for this, in exchange for posting info about their products on the home page. Telerik and Infragistics gave us several software licenses to raffle off. Techies love the books and software, but aren’t crazy about recruiters at such events, so I’d save them as a last resort. Microsoft also has a generous budget for supporting community events like these, and they basically covered most of our food costs and plenty of swag.

Swag for Raffles
Always try to secure swag to raffle off at the end of the event. We love books and software, and it’s a lot of fun giving this stuff out. In addition to the software Telerik, Infragistics, and Microsoft contributed, Microsoft also contributed around a dozen books and a mouse. In exchange, we posted Telerik and Infragistics info on our code camp website, and gave out promotional demo disks from Infragistics and Microsoft.

Choose the Sessions
This was made a bit easier by the Code Camp Questionnaire. We had room for 21 sessions (we’ll probably cut this down to 15 for the next code camp), and had 19 speakers apply. Because we were able to accept all the speakers, we only needed to pick two to do two sessions each. We added up the point rankings, and although that played into the chosen two extra sessions, we weren’t scientific about it. We took into account all of the sessions in order to provide a good balance. But we also took into account the rankings in order to do the next step — the session tracks and schedule.

Session Tracks / Schedule
Don’t worry about making specific session topic tracks. We tried doing it anyway, even though Don Demsak warned me about it. Trying to coordinate this was the most painful part of the whole process. We wanted to make sure we had the right mix in each track, and kept adjusting the track descriptions to keep things even. Trying to do that on top of trying not to have well-known speakers present at the same time as new speakers (to make sure that one session wasn’t grabbing all the attendees, leaving little for the lesser-knowns), and at the same time not wanting to place the well-known speakers opposite each other, frustrating the attendees. Bottom line — I learned not to worry about it. We had to swap sessions around during the last week anyway due to timing / commitment issues, and one burnt-out laptop caused someone to back out, which threw much of the planning out the window. It turned out that we had nothing to worry about. All of the sessions were well attended, the balance was pretty even, and I don’t think any speaker felt shortchanged. I guess we initially tried “over architecting” this . Don’t forget to schedule in breaks between sessions (10 minutes worked well), as well as an introductory general session with breakfast, a closing session for raffles, and lunch.

Session Scheduling Considerations
Try to schedule sessions so that a speaker who needs more preparation has their session right after lunch, or even first thing in the morning. This will give them around an hour head start. Also, after you create an initial Code Camp Session Schedule Grid and Code Camp Speakers / Sessions document, email them to all the speakers. You will get requests to shift things around, likely up until the last few days. You’ll also get updated bios and session abstracts. Always try to keep the speakers in the loop with updated versions up until the day of the event.

Session Length
This leads to the question of time allotted per session. This was one of our biggest mistakes. We gave an hour to each session, which turned out to be barely adequate. Part of the reason is that we wanted to avoid turning down speakers who volunteered, and wanted to put in as many sessions as was feasible. For the next meeting, I think we’ll set each session to at least 1:15, and preferably 1:30 each. I’d rather not mix them, because in that scenario, if we needed to swap two, we’d likely have to swap out six. I’m leaning towards three tracks of five sessions each, at 1:30 each session. I’d like to get more feedback on this.

Call for Presentation Material
Try to get the speakers to email you their presentation material the week before the event, so that you can avoid any mad rush after the event from people asking to download the material. Successfully receiving these is lot harder to do than you may think, though, because many speakers like to tweak their presentation up until the last minute. They may even need a couple of days after the event to make any corrections, etc. But the more you can get up front, the better.

Public Announcements
About two weeks after the internal announcement, now that your core community has had ample time to register, start making the code camp public. Contact other user groups, tell other bloggers, contact Dot Net Rocks!, speak to local publications, etc., and ask people at work to contact their friends about it. We tried to have an article published in a local paper about our host, CITI at UCONN, students and local companies impacted by their programs, with a mention of the user groups and code camp prior to the event, but missed the deadline to get it in on time. But once the article does come out in December, it should give a great boost to all parties.

Post Schedule and Session Details
Around the time you send out public announcements, the sessions, speakers and schedule should be pretty close to where it’ll end up, so it’s time to post this info on the website. We created separate pages for each. Make sure to keep these updated, and specify the last update time for each, so attendees know what to expect.

Large Session Schedule Grid
Print a large version of the session schedule that you can display on a wall near the registration desk. For each session, we printed the title on a separate sheet of paper in a large font. We also printed row and column headings on their own pages. Bring clear tape and/or painter’s tape for posting these without damaging the walls or leaving residue.

Room / Track Schedules
Print a single sheet for each room to show which sessions will be held at each time period for that room. You can post this outside the door of each room.

Directional Signs
You should investigate the layout of the venue beforehand, in order to know what signs you’ll need to print directing people to each of the session rooms, the food, and the restrooms. We didn’t know exactly which rooms we were going to use until that morning, because several events were being held at the campus that day. Thankfully, Louis was able to print directional signs at the last minute from his office.

Feedback Evaluation Forms
Design a feedback form to allow the attendees to rate each session over several categories. There should also be a space for comments about the sessions, and the event in general. We also included a questionnaire on the back of the form to capture data to help the facility sponsor. After all, they provide us with the facility to use for the code camp and the user groups. I think this is a good idea in general for any facility you may use. It can be placed on the back of the form so it’s not obtrusive, and almost everyone who handed in the form to us actually answered the mostly yes/no questions. You can download a copy of our eval document for an example of such a form, and to use as a starting point for your own. Print out copies to include in the information packets

Session Schedule Grid Handouts
Print out copies of the session schedule grid to include in the information packets. I grabbed an image of the web page, and just pasted it into a Word document.

Name Badges
Print out name badges for each registered attendee and speaker, at the last feasible moment. Bring along blank ones for write-ins for late registering attendees. I recommend that you require that an attendee can produce a name badge if their name is called in the raffle.

Information Packets
When preparing packets of information, include the session schedule grid, feedback evaluation form, and a pen, at minimum. I also recommend putting in a small pad or a few pieces of blank paper for notes, although we didn’t do that. Also include some promotional material for the venue of the event, as a return favor for hosting it. If any speakers want to hand out fliers for some of their services, you may want to consider placing them into the packets also, although at a free event such as a code camp, you want to try to avoid blatant marketing. We made fliers available from one of our speakers who happened to be providing some free training, so that was an ideal situation.

Security Concerns
If you’re planning to use a secure facility, make sure that the local security or police department is aware that the facility will be used on a weekend. Arrange to have the facility opened in time to prepare for the event, and if the doors lock from the outside after a period of time, make sure someone could monitor the doors so nobody gets locked out, or leave a cell phone number so they can call someone to get back in. If there’s a period of time after which the doors are locked, be sure to state this in the information details when people sign up, since people often arrive late.

Arrange for Food
Always try to supply both breakfast and lunch for all the attendees. Serving breakfast is an incentive for people to come for the early sessions. A significant number of people showed up early, so the early speakers had a good audience, and the day was off to a flying start. The catering group over at UCONN provided us with food for about $1000 for 100 people. Also, make speaker dinner reservations for your team (at approximately an hour after the event). You can probably assume that about 50% of the speakers would be able to join you afterwards. Definitely take the speakers out for dinner after the event — not only for thanking them for volunteering (remember, without the speakers, there is no code camp), but this is also a phenomenal networking opportunity for everyone involved, and a LOT of fun. These are experts in the field; some well known, and others fairly new to the public speaking arena, and they can share war stories. Not only that, but they have a lot of insight into how to improve future events. You’ll probably need a few hundred dollars to cover this. Again, thanks to the contributors for helping to cover all of this.

Directions to Venue
Make sure all the speakers have directions to the venue, both by car, and by public transit. Don’t forget any special info about parking, which we nearly did until the night before.

Your Contact Info
Always give out the cell phone numbers of at least a couple of organizers to the speakers. I forgot to do this until the night before, but it came in very handy. A few speakers got a bit lost trying to find the venue, and another would have been locked out of the building because he came late in the day, and security had already locked the doors from the outside.

Final Confirmation Phone Call / Email
A couple of days before the event, call each speaker to make sure that they’re ready, that they know exactly what time they’ll be presenting, and to remind them to get there early enough to do final preparations. Make sure they have directions, and ask if they’ll be joining you for the speaker dinner afterwards (as your guests). Also ask if they have any final questions. Follow up this phone call with an email to each, especially to the people you had to leave a voice mail.

In my next post, I’ll discuss how to handle the day of the event. It can get pretty frenzied, but at least there’s less actual work to do than in the preparation phase. That’s where all this preparation work pays dividends.