Capacity planning for PDC
The last three PDC's were overcrowded, with the last PDC being the worst. The solution seems pretty simple to me. Stop selling more admission tickets than you have available seats. Microsoft has had enough events at the LA Convention Center to know what it's capacity is. There really shouldn't be any surprises any more.
All of us involved with PDC 2003 remember that the sold out conference meant we had overfilled sessions. And if we didn't remember, all it takes is a quick browse through the written comments in the session evaluations to remind us ;) As Content Owner for PDC 2005, I’ve spent a lot of time looking over the 2003 attendance data. And my conclusion is the exact opposite of Kevin's: there is no way to avoid surprises. The best we can do is expect surprises and have a plan in place to deal with them.
It's tempting to imagine that the capacity planning math for PDC looks like this:
# available seats = # rooms per timeslot * average seats per room
ideal # attendees = # available seats * .x
where x is some number to account for the fact that not every session will be equally popular, and thus you assume a percentage of open seats will be unused in every timeslot.
If it were this easy to model capacity at the event, then we could do some more simple math:
max # 2005 attendees = # 2003 attendees * percentage 2003 overflow
For example, if data showed that the average session in 2003 was y% overcrowded, just reduce the max number of attendees in 2005 by y% vs. 2003, and voila, problem solved.
And if it were this easy, then Kevin’s right, there would be no excuse for surprises.
The data for 2003, however, suggest that this approach is over simplifying things. I’m convinced that our problem wasn't a systemic capacity shortage (too many people, too few seats) – our problem was mismatched room scheduling. Here are a few interesting data points I've found:
- If you look at the top 20 most crowded sessions, you find that 12 of them were scheduled for rooms that held less than 260 people.
- The most overcrowded session was booked into a room for 254 people. During that same timeslot, for comparison, there was one session in a room of 258 that was 30% empty, and another session in a room of 1200 that was 60% empty.
- The single timeslot with the most overcrowding occurred had an average session attendance of little more than half of total capacity
- The single timeslot with the least overcrowding occurred had an average session attendance of more than two thirds of total capacity. The timeslot with more people had less overcrowding.
I’ve been thinking about this data for a few weeks, now, (I posted some thoughts last week, in fact) and the only real conclusion I can draw is that it's just hard to predict what sessions will be most popular. We could have cut our attendance in half in 2003, but we probably still would have had overcrowding. It doesn’t make a difference whether 800 people or 400 people are interested in a session, if the room only holds 250.
We're working on ways to improve our capacity planning for 2005. Some of things I’ve been pondering (with the help of the rest of the planning team):
- Don’t schedule any rooms that hold less than 300 people. It’s too easy to get surprised and have 350 folks show up. Instead, keep those smaller rooms for repeat sessions, or even video overflow if needed.
- Do a better job predicting attendee plans. Help attendees plan their schedule more accurately by suggesting a few different core curriculum – "if you're developing web commerce sites, we suggest sessions x, y and z, if you’re developing Win32 client apps, we suggest a, b and c". The more accurate the session preference survey is, the better we can anticipate capacity and schedule accordingly.
- Be ready to be wrong. If a session is overcrowded, be ready to immediately set up an overflow room or schedule a repeat.
- As Scoble hinted, consider allowing fewer attendees
So, Kevin, we hear ya, and we're working on it. We're not going to be perfect in 2005, but when we're off base, we'll be quick to make a correction.