How to Make a Successful ARCHICAD User Group (Part 2: The Meeting)
How to start and grow an ARCHICAD User Group
If you are just joining us, here are links to the other posts in this series. If you haven’t read the previous posts, you might want to start there. What follows assumes you’ve read them. If you haven’t, that’s okay. But certain references, like “and your Ben isn’t there”, might make no sense.
- How to Make a Successful ARCHICAD User Group (Part 0: Introduction)
- How to Make a Successful ARCHICAD User Group (Part 1: Organization)
- How to Make a Successful ARCHICAD User Group (Part 2: The Meeting)
- How to Make a Successful ARCHICAD User Group (Part 3: Spreading the Word)
Now that we’ve discussed the fundamentals of how to get a user group going, let’s talk about the actual meetings. Having run and attended many user groups in multiple states, I have some extremely strong opinions on what should or shouldn’t happen when a bunch of users get together.
How to Make a Successful ARCHICAD User Group (Part 2: The Meeting)
- Frequency. Consistency helps. It lets people anticipate and prepare. I have found that every other month works best. On off months, if you have the energy, find some users to informally meet up for beers or lunch or coffee (what we in Seattle now call “ARCHICADbeers”). This frequency has worked well for me. It means if I miss a month and go to every 3 months for a meeting or two, that’s cool. That will happen in places with seasons. In Minnesota we often went longer without a meeting in the winter and in Seattle I have a feeling getting users to attend during the perfection that is a Pacific Northwest summer may be impossible. If you skip an “ARCHICADbeers”, that’s no problem because another isn’t so far off. From years of running user groups—this is my seventh year—quarterly isn’t often enough to create critical mass; users need to see each other more frequently than that. If someone misses a meeting, they might go half a year or more before engaging with ARCHICAD users who aren’t their coworkers. That’s unacceptable. Conversely, monthly is brutal. I did that at first. It’s too hard for one person to sustain. And honestly more than most people want to endure.
- How to Run a Meeting. Do not lecture. Ban PowerPoint. Don’t be boring. Try to get other users to present, but assume you as the person running the show are always presenting. Pick a project and share. Get the conversation going and then let the agenda go. This mentality is summed up nicely in my announcement for the April 2015 user group meeting in Seattle. Remember that a user group is not training. It is one to two hours of engagement between users. You need a framework for what you’ll talk about if everyone is too timid to talk (and your Ben isn’t there), but the best discussions are ones that come out organically from what interests people.
- How Long a Meeting should Last. One and a half to two hours is about perfect. If people are still interested in talking, continue the discussion informally at a bar nearby or standing around your meeting space. But after about two hours turn off the computer and screen.
- When a Meeting should Start. The best start time will vary by region, but here’s the question you need to ask yourself when picking a time: what start time gives everyone enough time to leave their office and get to the meeting, but not so much time that they just go home. When answering this question, don’t forget to think about traffic, where people are coming from, and what time people generally finish up work. In Minnesota I usually started things at 6:30 pm. In Seattle, I’ve switched to 6:00 pm. For a while we were doing 5:00 pm, but that seemed like a heavy burden on a lot of people. If you work far away, a 5:00 pm user group meeting means you’re potentially wrapping up work around 3:30 or 4:00 pm. Most people are going to want to work until at least 5:00 pm. If attending a user group means cutting the workday short, you’re going to get fewer people (some of us are workaholics, others don’t control their schedules). I’ve done a limited number of lunch time meetings, and they are fun—especially if there is food—but think of lunch meetings as special occasions. Lunch meetings add extra complexity that is better to avoid.
- Getting There. Location matters and so does parking. I suppose if you’re in New York City, parking matters less, but for most of us, we need to drive to meetings. Good parking means better attendance. It’s about convenience. The easier it is to attend, the more people who will. I’ve found that a central location is less desirable than one with lots of easy parking. Since so many people have to drive anyways, a few extra minutes for close, free parking has proved worth it.
- The Food. Food is great, but not critical. When I was running things on my own in Minnesota, I sometimes brought snacks and beer. A few times GRAPHISOFT was in town and fed us, which was always appreciated. But at the majority of the meetings, if people wanted to eat or drink, they knew to bring their own. Now in Seattle, our local rep Jesse feeds us every time. Thank you Jesse! People love it and appreciate it, but I know we’d all still come regardless (though my life is made easier by not having to eat beforehand).
- The Space. Find a firm with a good size conference room and ask them to host. This is actually very easy to do. It’s easier for their staff to attend and all they need to do is open their doors at the beginning and turn off the lights at the end. No need for them to do anything else.
- The Technology. A typical meeting needs just four things: a screen, a projector, a computer, and the right adapter to get the computer connected to the laptop. Ideally the hosting firm/space (or the local GRAPHISOFT rep) will have the projector and screen. If not, make sure someone in your core group has both those items (thank you Thomas). Never assume someone else is bringing the right adapters. If you regularly run or present at meetings of any sort, spend the couple of dollars to buy the three to four most common adapters you need for your machine. Speaking of machines, bring your laptop. If you don’t have a laptop…why don’t you use a laptop? Make sure someone else brings one.
- The Content. Ideally topics are crowd sourced. Often the theme of a meeting comes out of the questions asked, but not answered in the previous meeting. Other times I choose whatever happens to be on my mind when I send out the announcement—this can mean anything from a project phase I’m dealing with to an ARCHICAD feature I’m exploring to a grander BIM concept I was just reading about. I also will build a meeting around recent problems I’ve solved for coworkers or other users I’ve been talking to. As a fail safe, I have also spent an hour on the archicad-talk forum right before a meeting to get inspiration and learn a tip or two. I’ve also run meetings where I pick a random feature (Complex Profiles, Pen Sets, Layers, Attributes in General, the Morph Tool, etc.) and try to build discussions around that. Templates are of course an endless source of discussion. But again as I mention above, what I always want to see is an organic conversation coming from the people in the room. Of course, every year the release of a new version of ARCHICAD is always a great excuse to have a meeting and it makes a perfect topic. Actually it’s good for two meetings: one presenting/talking about the just released version and a few months later everyone sharing their experiences having used it for a bit. In fact, the meeting BEFORE the release is a perfect time to look back at the current version. Before everyone is immersed in the next version’s new features, this pre-release meeting can focus on everyone’s favorite parts of the current version, the features no one got to, and the aspects people are looking forward to exploring more. If you are running a meeting and have no idea what to talk about, you can also always e-mail me.
- The Connections. Remember that the meetings are about community building. Being the connector and leader of the group means making sure all the users who show up share, know each other, and grow bonds. Start every meeting with each attendee introducing themselves. Everyone should be learning more about both ARCHICAD and each other. When I run user groups, I like to see everyone talking—whether before, during, or after the meeting. Watch out for people who are not part of the conversation. Make sure you (or someone) is bringing them into the various discussions.