What I learned hosting virtual events for the first time…
When I had started writing this blog I had intended to write an entry a week. Several months later and only two blogs published that clearly didn’t worked out how I had intended — writing dropped in priority as we sprinted to toward the launch of the pilot. We’re now in the thick of things: the first cohort has completed their learning sessions, and the second cohort is now planned for the fall. I’m really enjoying the experience and want to continue to share my reflections as we go. I’m now aiming for a bi-weekly publishing and hope you keep coming back from time to time to catch up on what’s happening.
So now that we’ve hosted a series of four virtual learning sessions for Cohort 1, what did I learn helping run a series of virtual events for the first time?
Pick a platform you (and hopefully your participants) are familiar with
When trying to pick a platform to host the event, we cycled through a few different options. We started by identifying features and functions that we needed, and then tried to find a platform that supported all, or most, of these. At the outset, we were thinking about using Zoom; within days of making that decision, however, my organization banned the platform due to the security concerns that were highly publicized this spring. This left us with two options: MS Teams and WebEx Training. On the face of it WebEx was the better option because it boasts a slick breakout room function and was designed to host events similar to the BI pilot. However, no one on the team was particularly familiar with it, so choosing it would have meant investing time and energy in getting to know the ins and outs of the platform. On the other hand, MS Teams (or, I should say, at least the version we use) wasn’t really designed to host formal learning sessions and doesn’t have break out rooms. But we were all very familiar with the platform — as it was the department’s sanctioned collaboration and meeting platform, we’d already invested time and energy figuring out how to use effectively. Further, we were also advised that Teams is better for accessibility and compliance with Official Language requirements. In the end, we opted for MS Teams — our familiarity helped us set up a work-around solution for breakout rooms (more on that below) and meant that we didn’t spend valuable time and mental overhead learning how to use yet another platform.
Teach your participants how to use your chosen platform and provide support during sessions
We held 30 minute tech ‘dry runs’ with each of the teams participating in the virtual sessions. During this 30 minutes, we ran through some of the basic features of teams (mute/unmute, chat function, how to turn incoming video off/on, etc.) as well as how to move from the plenary meeting to the breakout meetings and back again. We also provided participants with a 1 page place mat with a lot of this information for reference. We also did a bunch of dry runs internally and with the subject matter experts we hired to make sure we were confident with all of the technology. We didn’t want to waste a bunch of time at the beginning of each session as participants struggled to connect or have tech hurdles get in the way of the content delivery.
In case there were any technical issues, we also had one person on our team dedicated to helping participants with tech issues during each of the sessions (note: this person wasn’t from IT — rather, it was one of our team mates who was comfortable with MS Teams and ready to try and troubleshoot any problems). We shared their contact information (e-mail and phone #) before and during the sessions. They were equipped with the place mat as well as a series of per-written answers to common technology challenges.
The pay-off for all of this preparation was quick resolution to the few one-off tech challenges and no time or focus lost to helping people get logged in and participating. We’re not sure how scalable this would be for bigger events (we had four teams and a dozen or so observers) since it’s relatively time and person intensive, but in the context of a pilot, and one of the first virtual events our team had executed, we felt it was worth the investment to minimize the likelihood of technical issues.
You can jerry-rig plenary and break out rooms in MS Teams
After spending some time playing around with MS Teams, we were able to jerry-rig break rooms by setting up concurrent meetings for the ‘plenary room’ and ‘breakout rooms’. In Teams you are able to join several meetings at a time and move between them by putting meetings on hold (you can also actively participate in more than one meeting if you sign in from different devices). This allowed participants to log into both the plenary and their breakout rooms and seamlessly move back and forth by putting one or the other on hold.
Breakout discussions less than 20 minutes were not meaningful
When designing the schedule, we assumed that because moving from plenary to breakout session was as quick as clicking a link it wouldn’t take much time for participants to move to their break out room, have a quick chat and move back again. Even though moving between sessions can happen relatively quickly, it still took a few minutes for people to find the right link and virtually land in the new meeting, and another few minutes for everyone in the breakout session to figure out who else is in the room and transition into a meaningful conversation. By that time even the most disciplined groups have burned through at least 5–10 minutes, so we found it took at least 20 minutes for breakout groups to answer a question or complete and exercise we gave them.
If you want to include quick discussions to increase interactivity and engagement I’d recommend an app like Slido that can show poll results and word walls, or cultivating an active discussion in the chat function (people in my department have become so proficient at using online meeting platforms that it’s not unusual for a whole parallel discussion to be happening in the chat bar while the meeting or seminar is occurring).
Plan to adapt as you go
This is probably the most valuable piece of advice that I can offer (and not exclusive to planning virtual events). We had initially intended to do a virtual session every other day to allow participating teams some time to do the homework assigned between each session. We decided to leave two days between each of the first two sessions (e.g. over two weeks the sessions were Monday, Thursday, Tuesday, and Thursday) to allow us give us a bit of extra time if the following sessions’ agendas needed substantial changes were needed or we needed to find fixes for major tech issues. We also scheduled a debrief between the Pilot organizing team and the external subject matter experts who were facilitating after each of the sessions. At these sessions we ran through any feedback we received from participants and shared how we thought things went in relation to tech, content and user experience. The time between sessions gave us the time to adapt and the debrief meetings gave us the chance to all agree on what adaptions were necessary. Doing so meant that we were able to improve the delivery of each subsequent session, improving the quality of experience for participants.
***
I’ll be back soon with a post that talks about what the Behavioural Insights Applied Learning Pilot actually is (rather than just my experiences helping plan and execute it). I hope you’ll come back and check it out, in the meantime @ me on Twitter with any lessons you’ve learned running your own virtual events.
