How do groups best collaborate on projects?
January 31, 2014 9:53 AM Subscribe
I work in a small business that reflects a lot of the same problems I've seen in other groups when they try to be productive. You get some people in a room with an intent to create an outcome, a project that is going to take considerable amount of time, thought, resources and creativity. Just getting people to stick to one single discussion thread in this large project becomes practically impossible.
How do groups collaborate successfully to create an outcome that is worth the effort?
My experience of group meetings is usually about the same. Begin the meeting, announce the outcome (build this thing that is better than the old thing). People in the meeting have varying ability to grasp the concepts involved or familiarity with the subject. Getting them all on the same page about any single aspect of the proposed project is time consuming. Big picture thinking usually never gets done as folks quickly begin obsessing over details. People derail any useful conversation by throwing in a tangentially related idea that goes off on another thread or the time gets eaten up with trivial or unrelated discussions.
All in all, group meetings are like the worst form of productivity ever invented. I read a book once that discussed this dilemma and proposed a methodology of a structured meeting process where all contribute their best ideas and the group evaluates them.
Group endeavor takes on the aspects of information management, value and goal seeking, project management (who does what), plus research and experimentation all coordinated among people who may not use the same tools for managing their working lives.
How do groups get from here to there with something approaching efficiency and coordination, avoiding cognitive bias and choosing effectively then acting on it?
My experience of group meetings is usually about the same. Begin the meeting, announce the outcome (build this thing that is better than the old thing). People in the meeting have varying ability to grasp the concepts involved or familiarity with the subject. Getting them all on the same page about any single aspect of the proposed project is time consuming. Big picture thinking usually never gets done as folks quickly begin obsessing over details. People derail any useful conversation by throwing in a tangentially related idea that goes off on another thread or the time gets eaten up with trivial or unrelated discussions.
All in all, group meetings are like the worst form of productivity ever invented. I read a book once that discussed this dilemma and proposed a methodology of a structured meeting process where all contribute their best ideas and the group evaluates them.
Group endeavor takes on the aspects of information management, value and goal seeking, project management (who does what), plus research and experimentation all coordinated among people who may not use the same tools for managing their working lives.
How do groups get from here to there with something approaching efficiency and coordination, avoiding cognitive bias and choosing effectively then acting on it?
This is a huge, huge topic, and literally something that people spend entire careers working at, but one thing I'll point at:
People in the meeting have varying ability to grasp the concepts involved or familiarity with the subject
Why are those people even in the meeting?
posted by Tomorrowful at 10:12 AM on January 31, 2014 [5 favorites]
People in the meeting have varying ability to grasp the concepts involved or familiarity with the subject
Why are those people even in the meeting?
posted by Tomorrowful at 10:12 AM on January 31, 2014 [5 favorites]
It really depends on the project. Some projects do best with one meeting at the beginning to decide on who does what, timeline, etc. and then people go off and work on their part, coming back together as needed once they have their deliverables. Other projects need people in the same room. There is not one Right Way to rule them all.
posted by rabbitrabbit at 10:15 AM on January 31, 2014 [1 favorite]
posted by rabbitrabbit at 10:15 AM on January 31, 2014 [1 favorite]
Seconding Ironmouth. Someone needs to be in charge, even if "in charge" is limited to "Why don't you two take that up later so we can get back to the grand scheme here."
posted by Etrigan at 10:21 AM on January 31, 2014
posted by Etrigan at 10:21 AM on January 31, 2014
Does your group have a leader, and if so, does the leader have authority (both explicit authority, within the business structure, and implicit authority, in the form of respect from the meeting participants)?
This sounds like a meeting structure without a strong leader. I think you need someone -- project manager, whoever -- to step up and lead.
A few other suggestions:
1) It may be that not everyone's input is valuable for every meeting. If you're designing a bicycle, you don't need the graphic designers at the spoke design meeting, and you don't need the engineers at the branding meeting.
2) Every meeting should generate specific action items for specific people. You can't say "Let's work on that" -- Work on what? Who works on it? You also can't say "This week, we will focus on design." Instead, it should be "Lisa, you should have a three-page report on comparable products by Tuesday. Mike, start looking into parts sourcing -- we need that information by next Wednesday." And so forth. And then the project manager needs to FOLLOW UP as early and as often as required to get that information gathered and brought to the next meeting or meetings. (And needs to have the authority to do so.)
posted by pie ninja at 10:24 AM on January 31, 2014 [3 favorites]
This sounds like a meeting structure without a strong leader. I think you need someone -- project manager, whoever -- to step up and lead.
A few other suggestions:
1) It may be that not everyone's input is valuable for every meeting. If you're designing a bicycle, you don't need the graphic designers at the spoke design meeting, and you don't need the engineers at the branding meeting.
2) Every meeting should generate specific action items for specific people. You can't say "Let's work on that" -- Work on what? Who works on it? You also can't say "This week, we will focus on design." Instead, it should be "Lisa, you should have a three-page report on comparable products by Tuesday. Mike, start looking into parts sourcing -- we need that information by next Wednesday." And so forth. And then the project manager needs to FOLLOW UP as early and as often as required to get that information gathered and brought to the next meeting or meetings. (And needs to have the authority to do so.)
posted by pie ninja at 10:24 AM on January 31, 2014 [3 favorites]
As Tomorrowful stated, this is a huge topic. I'll try to summarize how we did things for a giant project I just finished. It seemed to work well with a minimum of frustration.
1) Who is in charge? For us, we had two people leading - one from the IT side, one from the "business" or user side.
2) What is the plan? You have a budget (someone has a budget) and a proposal. What was the due date given?
3) What can be done in parallel? The business and IT leader figured these out together, outside a meeting.
4) When do we need to meet, and why? Here's what our meeting schedule looked like:
Monday 1 hour: review IT open questions, get answers - both teams - questions posted ahead of time so research could be done and those that could be easily closed were closed before the meeting. This was just to discuss the ones where we needed an actual discussion.
Tuesday 2 hours: The business teams met with the different countries to get requirements, provide testing dates, etc. Agenda was sent out ahead of time and adhered to pretty rigorously. One IT person (the business analyst) also attended this meeting, in case there were IT questions and to free up the rest of the team. There was one meeting in the morning EST and in the evening EST to cover all global time zones fairly well.
Wednesday 1 hour: Discuss testing issues and production moves if needed (both teams).
Thursday and Friday were not meeting days. Also, we always had a meeting agenda for every meeting, which was always published 24 hours ahead of time, and were pretty rigorous on following it. If you wanted to discuss something, you got it on the agenda. Otherwise, you had to wait til the next meeting.
For meeting schedules, the famous Makers Schedule/Managers Schedule is a good read.
Basically, people had to be ready to get rude. You were expected to know what was on the table, why it was on the table, why you were there, what you were expected to contribute, and that if you could not get or keep your act together, you were removed from the meeting, and if needed, from the project.
I would say the other thing that helped was having an executive sponsor who could and would step in to tell people to stick to the program. Sometimes, you just have to have that big hammer to get or keep everyone on track - the key is knowing how and when to use that person effectively, without over using that "lent authority".
I'm not sure that I exactly answered your question. Feel free to memail me if you have specific questions about what I wrote.
posted by RogueTech at 10:26 AM on January 31, 2014 [1 favorite]
1) Who is in charge? For us, we had two people leading - one from the IT side, one from the "business" or user side.
2) What is the plan? You have a budget (someone has a budget) and a proposal. What was the due date given?
3) What can be done in parallel? The business and IT leader figured these out together, outside a meeting.
4) When do we need to meet, and why? Here's what our meeting schedule looked like:
Monday 1 hour: review IT open questions, get answers - both teams - questions posted ahead of time so research could be done and those that could be easily closed were closed before the meeting. This was just to discuss the ones where we needed an actual discussion.
Tuesday 2 hours: The business teams met with the different countries to get requirements, provide testing dates, etc. Agenda was sent out ahead of time and adhered to pretty rigorously. One IT person (the business analyst) also attended this meeting, in case there were IT questions and to free up the rest of the team. There was one meeting in the morning EST and in the evening EST to cover all global time zones fairly well.
Wednesday 1 hour: Discuss testing issues and production moves if needed (both teams).
Thursday and Friday were not meeting days. Also, we always had a meeting agenda for every meeting, which was always published 24 hours ahead of time, and were pretty rigorous on following it. If you wanted to discuss something, you got it on the agenda. Otherwise, you had to wait til the next meeting.
For meeting schedules, the famous Makers Schedule/Managers Schedule is a good read.
Basically, people had to be ready to get rude. You were expected to know what was on the table, why it was on the table, why you were there, what you were expected to contribute, and that if you could not get or keep your act together, you were removed from the meeting, and if needed, from the project.
I would say the other thing that helped was having an executive sponsor who could and would step in to tell people to stick to the program. Sometimes, you just have to have that big hammer to get or keep everyone on track - the key is knowing how and when to use that person effectively, without over using that "lent authority".
I'm not sure that I exactly answered your question. Feel free to memail me if you have specific questions about what I wrote.
posted by RogueTech at 10:26 AM on January 31, 2014 [1 favorite]
I hate working in groups and I find meetings hideously unproductive.
To that end, managing meetings and projects is vital when groups must work together.
1. Have the outcome defined before coming into the meeting. Too often people fake giving contributors input into something that's already been decided. Come clean, if we're updating the Frammistannie to comply with ISO 2050, then just say that and move on.
2. Have an idea of who is doing what. Again, none of this fake, "so who wants to handle X part of the Frammistannie project? "Lisa, you wrote the base code for Frammistannie, you're the leader, how many people do you need to help you update and who would be best for this?"
3. Milestones. Have set milestones and dates for everything. "Lisa, we need the updated code by February 28. Joe, you need to have the impacted account list scrubbed and ready for production by March 3."
4. Have frequent sub-meetings with stakeholders, standing up, just to check in to make sure everyone's on task.
5. Before you have a large meeting, send out a request for agenda items. Determine how long each item will be discussed. No items that aren't on the agenda will be discussed.
My point, is that typically meetings serve the appearance of a democracy, when in fact, what you need is a dictatorship. If you want things to be done that is.
posted by Ruthless Bunny at 10:38 AM on January 31, 2014 [1 favorite]
To that end, managing meetings and projects is vital when groups must work together.
1. Have the outcome defined before coming into the meeting. Too often people fake giving contributors input into something that's already been decided. Come clean, if we're updating the Frammistannie to comply with ISO 2050, then just say that and move on.
2. Have an idea of who is doing what. Again, none of this fake, "so who wants to handle X part of the Frammistannie project? "Lisa, you wrote the base code for Frammistannie, you're the leader, how many people do you need to help you update and who would be best for this?"
3. Milestones. Have set milestones and dates for everything. "Lisa, we need the updated code by February 28. Joe, you need to have the impacted account list scrubbed and ready for production by March 3."
4. Have frequent sub-meetings with stakeholders, standing up, just to check in to make sure everyone's on task.
5. Before you have a large meeting, send out a request for agenda items. Determine how long each item will be discussed. No items that aren't on the agenda will be discussed.
My point, is that typically meetings serve the appearance of a democracy, when in fact, what you need is a dictatorship. If you want things to be done that is.
posted by Ruthless Bunny at 10:38 AM on January 31, 2014 [1 favorite]
One thing to keep in mind is that productive meetings very often don't actually get anything done - they exist to either identify problems that will be attacked afterwards, or present the results of work that was already done. Meetings are not times for productivity; they're times for communication.
posted by Tomorrowful at 11:01 AM on January 31, 2014 [5 favorites]
posted by Tomorrowful at 11:01 AM on January 31, 2014 [5 favorites]
My experience of group meetings is usually about the same. Begin the meeting, announce the outcome (build this thing that is better than the old thing).
That sounds like the project goal, not the meeting goal. So if you're beginning the project, do this:
- Hold a kickoff meeting w/everyone. Engineering, marketing, UI, etc. The goal of this meeting is to get high-level agreement about project goals, rough timelines, roles & responsibilities, and how the project will be run. It also functions as a communication device so that people aren't wondering why they haven't heard anything about New Project that they know is coming up.
- Create a deck that has a strawman schedule, etc., in it. Everything you need the team to agree on in the kickoff meeting. It is much easier to have something to refine in the meeting instead of walking in and saying, "so guys, how should we do Big New Project?"
- Before the kickoff meeting, have one on ones with the senior person of each team to get aligned on your deck. Nothing should ever be a surprise in the kickoff meeting. It allows them to give feedback on your initial framing of the project and will give them a sense of ownership. This avoids any major pushback in the kickoff.
- Give people deliverables in the timeline and get commitment that the work will happen.
Feel free to me mail me for more info, I've done this many times.
posted by sfkiddo at 12:48 PM on January 31, 2014
That sounds like the project goal, not the meeting goal. So if you're beginning the project, do this:
- Hold a kickoff meeting w/everyone. Engineering, marketing, UI, etc. The goal of this meeting is to get high-level agreement about project goals, rough timelines, roles & responsibilities, and how the project will be run. It also functions as a communication device so that people aren't wondering why they haven't heard anything about New Project that they know is coming up.
- Create a deck that has a strawman schedule, etc., in it. Everything you need the team to agree on in the kickoff meeting. It is much easier to have something to refine in the meeting instead of walking in and saying, "so guys, how should we do Big New Project?"
- Before the kickoff meeting, have one on ones with the senior person of each team to get aligned on your deck. Nothing should ever be a surprise in the kickoff meeting. It allows them to give feedback on your initial framing of the project and will give them a sense of ownership. This avoids any major pushback in the kickoff.
- Give people deliverables in the timeline and get commitment that the work will happen.
Feel free to me mail me for more info, I've done this many times.
posted by sfkiddo at 12:48 PM on January 31, 2014
« Older More Android Games Like The Silent Age | easing back into things after mysterious running... Newer »
This thread is closed to new comments.
posted by Ironmouth at 10:11 AM on January 31, 2014 [6 favorites]