I’m coming to the conclusion I need to gather a number of people together for several days to map out a development path for a key application here at work. Now I’ve got a number of ideas as to what I think I need to do but the Dope is full of experienced PMs, management consultants, PhDs, and various meeting victims. Exactly the type of people that have likely had to organize or survive 3 day conferences. So I turn to the Dope for its wisdom.
What key things should I do, not do, not forget if I’m to make an effective multi-day meeting?
And yes I need these people in one place. The car herding goes better if I can reach out and grab them by the scruff of the neck.
Write an agenda. Be very detailed about what goals should be accomplished on each day, and preferably each part of the day. I recommend dividing the days up into sessions lasting no longer than 90 minutes, with half hour breaks in between. Have a clear goal for what should be decided at the end of each 90-minute session. You are responsible for ensuring that the discussion remains on track.
Bring food. Your company should be willing to pay for this. Days-long meetings are exhausting, even when well-run, and your people deserve some lunch and snacks. It will also make it easier to herd them back into the conference room if everybody isn’t out to lunch.
Start each session on time. Absolutely no tolerance for dawdlers. Enforce this with the iron fist of almighty Zeus.
Ensure that you are not moderating every session. Some objectives can be delegated and those people can lead those sessions, with you there to guide. Otherwise you will burn out quickly. The change of focus will also be refreshing for the group. Especially if you’re boring.
This. Start developing as timeline right now
Something like…
Day 1
Requirements
9-12 business requirements (15 minute break at 10:30)
Lunch 12-1
1-5:30 translate business requirements into technical requirements
9:00 - 11:00
Day 2
Identify affected systems and high level architecture…
Well I feel better, I had most of these rattling around in my head. Except for delegating the moderating which I like a lot.
I had thought about having the group break up into committee/subgroups to come up with solutions to gaps/frustrations with the current tool set. That sounds like a Day 2 type of thing and would get me off the stage despite, friedo, my dazzling personality.
Totally agree. For a long retreat/offsite, I start by listing a 1-3 objectives for the overall meeting - To Create a Development Path for App XX, say. Then, I great a Table with the following columns:
Topic: the overall Objective should be broken out into 5-7 Topics that, when all completed, will deliver on the Objective.
Outcome: For each Topic, what do you want to end up with. These should be NOUNS - e.g., a Decision on XX, a Set of Inputs on YY, Agreement on ZZ, etc. No more than 2-3 Outcomes per Topic.
Process: what is the process your group should go through to achieve the Outcomes? A Moderated discussion? A specific app-design approach? Break out into groups?
Materials: What materials does that specific Topic need - a PowerPoint? Flip Charts and Pens? A Projector? An app to drive the the planning?
Who: who owns this topic and any other key roles?
Timing: how long for the topic?
If you have that, it’s your Agenda, just insert rows between topics to account for breaks, meals, etc…
Of course, with the whole ‘break up into subgroups’ thing, there’s the issue of who picks the subgroups. Do you assign them randomly? By order of name or ID number? By skill? Do people sort themselves? Do you hand out cards of alternating colours and say, “All the reds in group one! All the greens in group two!”?
The should be logically assigned based on the objective you want to achieve and the skills sets / knowledge / expertise of the individuals in the groups.
How many people? What fraction of their usual work time is devoted to this application?
Make sure the breaks are long enough. Breaks are a crucial component of the agenda beyond their biological purpose (snack, bathroom, fresh air). They are when unstructured one-on-one conversations happen. In a regular session, discussion has an implicit time constraint which in turn is an implicit level-of-detail constraint. There may be 5 high-level decisions that need to be settled, but each of those may spawn a few nuanced issues. Alice may realize that her widget will need to be tested with Bob’s interface, but since there are dozens of items at this level, she may not bring it up (since if everyone did, there’d be no time for the high-level stuff). In the break, Alice can sidle up to Bob and say, “Hey, when we were talking about X, do you think there will be any problem with your interface?”) It’s also a chance to digest the conclusions. A discussion may conclude with a soft landing and obvious conclusions, but then after chatting at the refreshments for 20 minutes about the implications, someone realizes that there’s a real issue hiding. Break time also gives people a chance to share with specific people any vague ideas or concerns they might have but that they didn’t feel comfortable enough raising in open session due to time constraints, embarrassment, off-topic-ness, etc.
25 minute breaks are a good middle ground between giving people some time to talk yet not too much time that they try to wander off.
Schedule in some “float” time. Discussions may need to run over, and having built-in buffer is good, especially for the sort of issues it sounds like you’ll be tackling. (That is, these aren’t a string of status updates. These are open-ended questions about how your team should be approaching the problem.) Breaks can serve as a time buffer, but at the expense of the value of the breaks themselves. For a 90 minute session that will definitely include discussion, try to schedule in 75 minutes of material and let it expand organically based on where the trickier points end up. If you occasionally don’t need the float time, you’ve just bought yourself some valuable one-on-one time (“Jim, Bob: how about you guys chat right now about issue Y that came up since we have a few minutes.”)
Keep people on-topic. One person who gets the floor and rambles on about some side nitpick or issue that has nothing to do with the immediate discussion goal can chew up tons of valuable limited time. If their comments are irrelevant, say so (nicely, of course). If there is explicit time later on the agenda to discuss those points, say so.
In some of the multi-day meetings I have been involved in they would put some time on the agenda for a “work break”, usually a hour block or an 1/2 hour extra around lunch, not necessarily every day.
The point being, everyone present has other job responsibilities, so we took a break from our meeting agenda and could spend some tending to our other work. This way one does not have to spend your lunch or evenings keeping up with all of the other things you have to do.
Knowing everyone will have some time for this, you can then expect everybody to focus a little more during the scheduled events. Helps prevents a constant flow of people stepping out for calls, or hunched over their phones/laptops responding to emails instead of being active participants in the meeting.
I like that idea, it might keep the open laptop/email skimming to a minimum.
Basically I’d break groups up along the subsets of the tool - Alice,Bob and Charles all touch the Record creation piece - they’d go off and come back with a solution.
Consider the level of detail appropriate for each segment of the discussion - an easy way to fail is to dive too soon into the minute detail of how some problem could be solved, before you have a general overview of the whole thing as a collection of high level concepts. You may have to keep dragging people back up to the top level thinking.
