A project course requires frequent project meetings. Most of these meetings can be very informal. However, periodic semi-formal project meetings are useful, too, especially at critical junctures of the project when input from all members is required. Some courses require the supervisor to attend such meetings as an observer, evaluator, and sometimes, as a facilitator. If that is the case in your course, how you conduct the meeting will form an impression in your supervisor's mind as to how professionally you go about doing the project, and this impression can affect your grade. Besides, everyone hates meetings that waste time. Introducing a little bit of structure and order into meetings, as suggested in tips in this section, can make your project meetings more productive.
Having an agenda reduces aimless 'time waster' type meetings, and sets targets to achieve during the meeting. Decide the agenda for the meeting in advance, and communicate it to the team. If this is not possible, at least decide the agenda at the beginning of the meeting.
It is a good idea to assign someone the responsibility of making meetings work. This person, let us call him the moderator, should steer the meeting along the correct path. The process need not be formal, for example, there is no need for the moderator to sit at the head of the table or stand up when talking. The team leader will often serve as the moderator, but not necessarily.
Once the starting time is decided, it is everyone's responsibility to be there on time. If you are not sure of making it on time, let others know before finalising the start time, so that it can be rescheduled. Two prominent 'time wasters' during meetings are 1. waiting for someone to arrive, and 2. filling in someone who joined mid-meeting. Some teams even fine late-comers to discourage tardiness.
We should minimise time wasted in meetings because every minute wasted in a meeting is a loss for all attendees. For example, 10 minutes wasted in a six-person meeting is effectively a 60-minute loss. But on the other hand, the time spent on getting to and getting back from a meeting is much higher in a student project than in an industry project. This is because, unlike in most industry projects, students do not work in cubicles located close to each other. Therefore, it does not make sense to have very short meetings either (imagine spending half an hour getting to a five-minute meeting). If you do not have enough items on the agenda to cover at least one hour, try using online meetings instead (for example, using instant messengers). Alternatively, you can schedule meetings and 'work together' sessions back-to-back so that all the time spent on getting to the meeting location is justified. In our experience, two-hour meetings work better than one-hour meetings.
Appoint a 'scribe' to take notes during the meeting (i.e. to record minutes). These notes should be circulated among the team members, and perhaps CC'ed to the supervisor. This is particularly useful for the supervisor to keep track of decisions taken by your team (remember, he tracks multiple teams), and for members who did not attend the meeting. A digital camera can help greatly in capturing anything on the whiteboard.
Just before you break up the meeting, the scribe can recap (verbally) what was discussed during the meeting. This reiterates the 'takeaway points' of the meeting. This is also useful to gauge how much you accomplished during the meeting.
Fix the finish time when you schedule the meeting. For example, do not schedule 'open-ended' meetings such as '5 pm onwards'. Instead, it should be something like '5-7 pm'. Do not let the meeting drag on beyond the finish time. When you aim to finish on time, there is an incentive to get on with the agenda.
Higher-priority items should appear earlier in the agenda. If you run out of time, you can postpone unfinished lower-priority items to a later meeting.
Schedule your meetings on a regular fixed time slot (e.g. we meet every Friday 12-2 pm). Do this at the beginning of the course and inform team members to keep this time slot free. This reduces the chances of someone skipping a meeting due to an alleged timetable clash.
Brainstorming is a good tool to put the collective brain power of the team to good use. In a brainstorming session, everyone throws in any idea that comes into their mind no matter how outlandish it may sound. Proposed ideas are not debated or evaluated during the session. All ideas presented are recorded for further consideration.
Setting ground rules avoids certain unwelcome behaviour from team members without having to confront the culprit individually. Some example ground rules.
Some suggestions to avoid frictions during meetings (and at other times):
If something does not apply to the majority of those present, do not use the meeting to discuss it. Avoid putting on the table for discussion topics that are not suitable to discuss in a meeting, maybe because they require some preliminary research to be done first or because they require hard thinking and analysis at a slower pace. When the topic to be discussed is known beforehand (which should be the case most of the time), do your homework before the meeting and come prepared to discuss it. For example, create the test plan before the meeting and use the meeting to tweak it rather than trying to create the test plan from scratch in the middle of the meeting.
Problem: A team member who frequently sends the project discussion along an irrelevant tangent. Some distracters joke too much, some take pleasure in arguing about unimportant things, some bring up 'interesting' trivia (e.g. "By the way, you know what else is an interesting design pattern?"), some love to interrupt with chit chat ("Hey, is that a new phone. What happened to the the old one?"), and the list goes on.
Recommendation: This is often (but not always) unintentional. Set a ground rule to pre-empt this kind of behaviour (e.g. 'not too much joking during meetings').
Problem: A team member who uses his native language when talking to his compatriot teammates.
Recommendation: This is unacceptable. Set ground rules to pre-empt this behavior.
Problem: A team member who loves to hear his own voice dominate the discussion.
Recommendation: The moderator should take action to give equal chance to other team members.
Problem: A team member who constantly brings up topics related to his own part of the project even when the team is discussing something else.
Recommendation: It is the job of the moderator to redirect the discussion to the topic at hand. Another tactic is to allocate time in the agenda for each person to bring up issues.
Problem: A team member who uses the meeting as a surrogate social life. He insists on frequent meetings and uses various tactics to lengthen meetings.
Recommendation: A meeting is a costly tool (in terms of time spent). Question the need for the meeting that do not have a worthy agenda. During a meeting, the moderator should follow the agenda and limit the meeting to the duration previously agreed.
Problem: A team member who often skips team meetings.
Recommendation: Count the time spent in meetings towards the contribution calculation for each team member.
Problem: A team member who is physically present in the meeting, but uses the meeting time to do other work, or frequently drifts away from the discussion to answer text messages or phone calls.
Recommendation: Set ground rules to preempt such behaviour (e.g. no texting in meetings)
Any suggestions to improve this book? Any tips you would like to add? Any aspect of your project not covered by the book? Anything in the book that you don't agree with? Noticed any errors/omissions? Please use the link below to provide feedback, or send an email to damith[at]comp.nus.edu.sg
---| This page is from the free online book Practical Tips for Software-Intensive Student Projects V3.0, Jul 2010, Author: Damith C. Rajapakse |---