8.4 Meetings

 < Day Day Up > 



8.4 Meetings

I debated where to put this topic. The final decision to place it in this chapter was based on the key point to be made about meetings. It is a common practice of mine to review assumptions that shape behavior, and I encourage you to do the same. On this topic, a most interesting dialog arises in that regard if you ask the very simple question: "Why do projects require meetings?" We could refine this issue by further asking, "What is so special about this next meeting that the same things cannot be accomplished by chat (i.e., e-mail), smaller gatherings, one-on-ones, or by whomever you choose to sit with at lunch?" And, of course, we can add another layer of interest by asking the corollary question "Why do people attend project meetings?" There must be some purpose other than the free continental breakfast, or the excuse to break from the drudgery of actually doing work, right?

I can only think of one reason to have all these meetings: to make decisions with the right people around the table. Granted, team building and bonding are socially useful consequences of gathering together. Information exchange and developing empathy for the other person can all be positive results of meetings. Still, without decision making, meetings can be fun, entertaining, and even educational without adding one inch of progress toward project success.

The reasons are easy to infer, if you think back on the hundreds of meetings you have attended - not as leader, but invitee. Someone gathers the troops, possibly including customers or beneficiaries, in a room. He passes around reports or presentations and proceeds to talk at everyone, or he has someone do that for him. Then, the group discusses practically anything that comes to mind, with questions asked and issues raised in far greater quantity than answers seem to come forward. Before long, everyone's attention dissipates and a few begin taking calls on their cell phones.

The meeting is running long. Someone else needs the room, or a significant attendee has to rush off to the next appointment, so the meeting finally dies from lack of interest. At that point, the project manager looks down at his pitiful notes and wonders how to summarize what just transpired into published minutes that demonstrate how those in attendance earned their pay for that hour or two. As a result, minutes come out with as much substance as oatmeal, or are used to slip in decisions or opinions not formally agreed to by the group. Few of these results sound like the ball got moved down the field and, truth be told, it probably did not.

No one can deny they have been to a lot of these stinkers and presided over a few, as well. Exhibit 3 lists the effort I put forth to avoid perpetrating such injustice on my attendees. Although hosting business meetings is not the same as throwing a party at home, I hope you would not deliberately insult or antagonize either set of guests.

Exhibit 3: How to Run Effective Meetings

start example

  • Publish the agenda in advance, distribute copies at meeting, and stay with it.

  • If time permits, cover additional topics once all agenda items are cleared.

  • Follow the same script with each item - introduce, discuss, resolve, close.

  • Try to close the discussion on topics as quickly as possible - keep moving.

  • Ten minutes before the scheduled end, close all discussion.

  • Summarize all conclusions verbally just as they will appear in the minutes.

  • Schedule any required follow-up meetings before adjourning this one.

  • Publish minutes appended to the agenda document by the end of the day.

end example

The best description I ever heard of managing big meetings is that it is like herding cats. Everyone has opinions. Most want to be heard, although some people's minds wander. Their pagers and cell phones go off, or their personal digital assistant (PDA) has a wireless connection that allows them to surf the net. I was in a meeting where an attendee muttered, "Cubs win!" while staring at his laptop.

Therefore, each meeting for which you are responsible should have firm objectives set by you. Hopefully, you will have positive input on this from conscientious team leads who lobby to get a topic put before the whole team. The second key point is that you want to condition the team and others who attend your meetings on a regular or semiregular basis to expect certain things and to adjust their behaviors accordingly. My premeeting mantra as I get ready to rev one up is: "tasks, dates, and owners." Sometimes, I literally recite this to myself as I wait for the elevator or stand at the copy machine putting the meeting package together. This is what I want to come from this meeting, or any other one I lead or attend.

  • Things that need to get done

  • Dates when they need to be completed

  • Names of those willing to get these things done by those dates

  • Any significant issues pertaining to these tasks

I am not particularly interested in the 19 permutations on the 47 options. Just tell me this: what course are we taking, when do we get there, and who is rowing the boat? I must confess that I probably have decided who should do what and by when, in advance of the meeting. I have found that it works far better if the meeting actually produces these results, instead of asking the team to vote my ideas up or down. I want the crowd buy-in, either because the particular item requires team effort, or I want the peer pressure of the other team leads to have a positive motivating effect on whoever gets tagged with a particular task.

Stylistically, different methods are used to pull this off, but if you set this tone and maintain it consistently, people will show up prepared with their issues looking for help, or for that brief moment of glory when they can report success with a previously assigned task. That is the real intent here: to get people to prepare for meetings where good things can and will get done. If you are going to improve your effectiveness as a project manager, it is because you understand that it is a leadership position. In this context, part of that responsibility is to provide the opportunity for problems to be solved. Use your meetings to do this. Also, good meetings help carry people emotionally from week to week. It is not that meetings should be run like a revival, but there is tremendous value in using the meeting as a tool in this manner.

As I said, meetings are about decisions, which, of course, are worthless without documentation, which is how we got here in the first place. Now that we have set the table for the climate or mood you hope to create and maintain for all your meetings, it is time to look at how documentation ties it all together. Exhibit 4 presents a typical agenda.

Exhibit 4: Sample Meeting Agenda

start example

SouthPointe Meeting Agenda/October 15, 9 a.m., Room 981, Building C

  1. Status (voice, telecom, server, network monitoring, engineering).

  2. Requirement for the legacy mainframe network at the new site.

  3. Potential upgrade of desktop operating system.

  4. Handling legacy LAN server protocols at the new site.

end example

This example was taken from a weekly 2-hour meeting for an 18-month project that had as many as 30 people attending in person or via conference call. We always began with status, typically allocating ten minutes to each team lead, although sometimes they took more. Due to the size of the crowd and its makeup, it worked best to focus on one piece at a time, delaying issues with dependencies between or among sub teams until individual reviews were complete. Items 2, 3, and 4 in Exhibit 4 were issues that involved all the subteams except the voice team, which would be excused once it gave its status because their piece of the project was mostly, but not totally, stand-alone.

Minutes for this meeting will be appended to the preceding agenda document under each section, plus a section would be added for any new business that would find its way onto the group's radar screen.



 < Day Day Up > 



Complex IT project management(c) 16 steps to success
Complex IT Project Management: 16 Steps to Success
ISBN: 0849319323
EAN: 2147483647
Year: 2004
Pages: 231
Authors: Peter Schulte

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net