Thumb Rules for Effective Meetings

• Software Development

Meetings are unavoidable at any work place. At most occasions, meetings can be frustrating. We all face meeting-nightmares in our professional life.

I worked on a project, where none of the team-members were ever interested in any kind of group discussion or formal communication. At early stages of the project, no one wanted to be a part of decision making process. During middle-stages of the project, no one wanted to share any status updates or discuss any critical issues. And finally when the project failed, no one was interested to discuss about the cause of failures.

On another interesting project, the team members seemed interested only in meetings. During the requirement gathering phase, we had frequent (and long) session, which were merely a time waste. These sessions reminded me of the "Impromptu Speech Competition" during college days. There was no agenda in place during these discussion, and every one sounded as ambiguous as one could be.

Since a software development process involves more than one engineer (some times more than one team)
working together to achieve the final goal, lack of communication can adversely affect the quality and cost of the final product. Excessive and ambiguous communication on the other hand, can be detrimental to the morales of sincere and determined engineers.

There are dozens of software development processes which define their own guide-lines for optimal communication. However, these guidelines are not always practical for each project. One can call a number of meetings to decide upon which guidelines to follow, and finally end up without any effective conclusion.

I generally follow some Thumb-rules, to evaluate the effectiveness of a meeting. Though different meetings can be governed by different guide-lines, but these thumb-rules need to be satisfied, if meeting has any true purpose.

(1) Identify the TYPE
Meeting can be of different types. The two most common types (most office meetings will fall under one
of these categories) are "Brain Storming" and "Decision Making" meetings. You may also encounter "Communication Meetings" but we will not discuss them here, as these are one-way meetings. Most participants have no role to play in these meetings, and they even enjoy the liberty to skip such meetings. A brain storming meeting need not have any tangible outcome. These meetings are mainly intended at information sharing (and information enriching) and thought provocation. Though such meetings are nice to have (as they boost creativity), but must be voided as much as possible. Probably number of such meetings should not exceed more than one per project. "Decision Making" meetings are more focussed and can be very useful (if conducted in a right way).

(2) Have an Agenda and Stick to it
Make sure that there is a well defined "Agenda" in place for the meeting. The agenda must be published well in advance, so that participants can be prepare themselves for the meeting. Make sure that proceedings of the meeting are inline with the agenda. It is wise to raise an alarm when you feel that proceedings are deviating too much from the agenda.

(3) Know your role
Each participant in the meeting has a role to play. This role can vary based on what your position in the organization. For example, a Designer, a Developer and a Tester can make valuable contributions to the meeting by offering information on what they know well. However it could be disasterous if a Developer decides to flaunt his (little) knowledge about QA process. (It does not mean that a developer can not contribute to the QA guidelines, but this is not his prime role and he needs to be very well prepared if he wishes to revive the company's QA strategies). Meeting could also be use-less if one is not prepared to handle one's role in the meeting. For example if the designers in a "Design Decision meeting" are not prepared well (have not even read the specifications), it is unlikely that meeting will lead to anywhere. Make sure that You (which should translate to "each one of you" in the meeting) understand your role and play it well during the meeting.

(4) Tolerate No Ambiguity
Phrases like "it may be true...", "as far as I understand...", "I guess..." evaluate to NULL in a technical discussion. "I will cross-check and get back to you" is a better option, as it avoids confusions and saves time. Try not to be ambiguous in the meeting, and accept no ambiguity from others.

(5) Conclude each item
Any item which is discussed must have a final conclusion which is formally agreed upon by all the participants. In case no such agreement is arrived at, make sure that item is marked as "Open". Some times each one expresses one's opinion on the item, and item is assumed to be closed without a formal agreement. In such cases, each one has liberty to assume that one's opinion has been considered right. This can lead to unpleasant situations later.

(6) Respect Every one's Time
Along with "Meeting Agenda", a rough time table also should be worked upon before the meeting. It must
be ensured that participants adhere to the time table. A few minutes drift on either side is ok, but I have seen meeting planned for one hour, lasting more than three hours. This just reflects that "participants have no respect for any one's time (including their own time)". Such a mis-managed meeting, amongst mis-managed people, will hardly ever lead to any useful conclusions.

(7) Minutes of meeting
At end of the meeting, some one should take up (or can be assigned) the responsibility of summarizing
minutes of the meeting and e-mailing it to all the participants

Sign in