Project Manager If We Have Too Many Meetings We May Be The Problem
“The information technology revolution makes it possible to have more information go to more people more efficiently,” [Simo] Ramo says. “more people can now be informed on topics. Therefore, more people have ideas.” And that leads to longer discussion and … more meetings. It’s Not You, It’s Meetings, Bloomberg Businessweek, June 17,2012.
It’s Not You, It’s Meetings – No, It Is You!
The proliferation of meetings is almost always a symptom of a bigger problem. Too often, the meeting is a solution thrown at problems of poor planning, poor communications, poor cooperation, poor … well, you get the idea. If we’ve had these problems for years, then we’ll have had excessive meetings, for years. No, it does not have to be this way.
The notion by Simo Ramo struck me as being at odds with my own experience. I often got the argument that because I pushed out so much project and organization information, often times it was the working data — before it was “done, done” — that people would be confused or would react to information that they didn’t need and we would get more meetings.
Unneeded Meetings Go Down As Information Sharing Goes Up
It just never seemed to work that way. Yes, I was pushing out information in large part to simply get people the information they needed (and often, I didn’t know who all needed what information so I made it available to everyone). This almost always reduced the number of meetings needed (teams and managers calling meetings) and when we did have a meeting, everyone was much more informed and on top of the issues.
Independent Problem Solving Goes Up As Information Sharing Goes Up
I always loved it when someone or a team I didn’t know much about (e.g., large projects with thousands of engineers across the world) reacted to my information and fixed or adjusted a plan or requirement without anyone having to tell them. I’ve run meetings, where I thought all was going well, only to discover that a team saw a problem based upon our updated status and had fixed it. They had worked through the weekend to make sure everything was on track. They had never said a thing to me as the project manager, just acted on the information, and then let me know, casually and with great pride in the meeting, that they had seen a major problem based upon our update and had fixed it. Wow.
Shared Information Should Be Complete, Comprehensive and Timely
Don’t get me wrong. Just pushing out random information will not make any kind of difference. It has to be the key information that we use to drive the project or organization. It has to be the plans, strategy, issues, metrics, and details of what teams are doing and how they are progressing. It has to be the daily details and updated daily. You know, it has to be all that information that projects that are not doing well will inevitably hold back. It worked best when we were just brutally honest and exposed ourselves to everyone (security sometimes had problems with this approach, but that is another discussion).
Sharing Information Does Not Fix A Project That Was Poorly Planned
Of course, if we have poor plans, poor estimates, poor requirements, etc., then having good communications just exposes all these problems, and that indeed could increase the number of meetings. But again, the solution is to fix the underlying problems (getting good project estimates, for example, is almost a silver bullet for many problems) and then the meetings should settle down to a reasonable amount that contributes to progress.
For more see “It’s The Project Management Schedule, Stupid”
Meeting are a great and essential project management tool, but they are often overused as a solution to underlying organizational or project management problems. If our meetings appear out of control, focus on why we need so many meeting and solve those problems, rather than spending too much time fretting about all the meetings. Fix the underlying problems and the meetings will settle down to an appropriate tempo and then your meeting will become a project management tool that works.
What underlying problems are provoking excessive meetings in your project?
8 thoughts on “Project Manager If We Have Too Many Meetings We May Be The Problem”
Comments are closed.
More comments from around the web:
Kaushlendra Rai • My perception is that most of the time the discussion is between 2-3 people and rest act as the spectators who neither do understand nor contribute to meaningful judgement.
I think that the meeting organizers must specifically invite only those people who are of relevance and do not disturb the whole team.
The daily meeting are the real time killers. In the daily stand-up meetings, people need to be brief in their content rather than giving extensive discourses. Any detailed discussion should be taken outside the general meeting and that too with the responsible parties only.
Bruce Benson • Kaushlendra,
Agreed. The trick is to help tune the team to deliver what is needed and not much more.
During the end of our mega projects (these were mass market consumer products) we would have a daily review of open defects. These meetings would go on forever, for hours, as people wanted to quibble about each and every defect. I implemented a simple approach where all I wanted to know was: Have you recreated the problem (yes/no – if no is there any help you need and I would move on to the next defect), have you found the root cause (same approach as first question), have you coded a solution (ditto), have you tested the solution in a product build (ditto), etc.. We went from covering about a dozen defects (we had hundreds) in an hour to covering about 60 defects an hour (averaged one per minute once everyone got tuned in).
The key was that everyone knew what they needed to report in the meeting and if someone wanted to know more, they had to catch the person after the meeting (or IM/e-mail during the meeting when that person was done with their portion).
We had a lot of people in the meeting not only so they could cover their defects, but also so if someone asked for help, we would have an immediate confirmation of who would be helping (team dependencies and interactions were high in the product so that happend a lot).
The success of this approach was that it made the meetings more productive and shorter (I held the meetings to exactly an hour, and started exactly on time — took a few people some time to realize this!). It was a very task oriented meeting and people would say something short like “we’ll take that one” or “we’ll help them” and rarely did we get any long winded comments, rants or the like. We got in, covered the material (as much a we could) and got back to doing the work.
Thanks for the comment!
More comments from around the web:
Jannet Sparts • The main problem, I guess, that too many meetings can provoke is wasting time on gathering together team members performing some tasks. And as a result, much wasted time and sometimes broken deadlines.
Bruce Benson • Jannet,Agreed. Generally the time available to each individual is a valuable commodity and needs to be allocated to activities that move the project forward. In my practice (managing projects and consulting) the lack of time is the number one reason why projects failed (e.g., delivered late, low quality, over budget, etc.). Once we got the overall time estimate correct (the overall schedule), then this gave individuals the time they needed to get the job done right – including meetings and other overhead that took them away from their primary and specific individual contributions (e.g., programmers, operators, analysts, engineers, etc.).
If the project was well estimated, and then well managed (good communications and coordination, etc.) then I found the number of meetings needed (as compared to previous projects) were noticeably less (at least people would comment that we didn’t need to call as many meetings).
The need for meetings generally went up when things started to go wrong. When we classically underestimated a projects schedule (saying we can do something in six months when it ultimately takes nine months) then within the first month we would see milestones being missed (a task taking ten days instead of seven) and as we slip, we call meetings to “fix” the problems. The meetings in turn take more time away from doing the tasks that are already underestimated and so the effects of the too short schedule can snowball as we try to fix the problems and avoid any other schedule slips (which rarely works in an underestimated project – the best solutions I’ve seen work are those that make a one time fix to the overall schedule – getting it right on the 2nd try).
Thanks for the comment.
More comments from around the web:
Chanda K. Zimmerman • Good points, Bruce! Meetings these days all too often fall under “we have met the enemy and he is us.” I don’t understand why it’s so impossible for so many organizations to recognize that their meetings are not functional, and are actually part of the problem, not the soluion.
Chanda, I had one senior manager push back with “meeting are how we manage!” At his level, meetings were his world, so I think that high tower has a moat that makes it hard for some folks to see that there is even a problem. On the other side, I’ve seen initiatives to reduce meetings — make a list, decide to not call some of them, combine some others, etc. — and I think this missed the notion of finding the root cause for the apparent need for all the meetings. The notion that individual meetings might be dysfunctional is a whole other topic and yes I agree that running ineffective meetings can generate more meetings that can snowball (e.g., due to an inability for leadership to make a decision, etc.) instead of solving problems.
Great feedback, thanks
More comments from around the web:
Mike Murphy, PMP • Couple ideas on possible underlying problems:
1 – inability to delegate authority – such that everybody up and down and across the org chart has to be there, and when not everyone attends (how can they all be there??), more meetings added.
2 – fear of retribution – such that while given authority to make a decision, the person might still need to have follow-on meetings to gain approval for decision before making it.
3 – all status meetings must be happy – such that only good things can be discussed (never say negative things), making meetings self-congratulating (and therefore very boring) sessions, which because the problems aren’t discussed, generates lots of future meetings to discuss what went wrong and how to fix it.
4 – company vision, goals, interests are not shared – such that no matter what might be decided in a meeting, the various organizations will countermand the decision to further their own view of the company vision/goals/interests, generating more meetings to “get back together” to discuss/decide again (and again and again…..).
5 – “too many meetings” is the whipping boy for late delivery – when in doubt, blame any schedule problems on “too many meetings” (see below for more on this one).
On the general complaint of “too many meetings” – rarely is there any data to support this claim. I’d bet 95% or more companies have a time code for “meetings”. Anyone ever check who dumps time in the “meeting” time code? Have you noticed that it is used as all purpose time sheet filler by many – sometimes to the tune of 60+ hours a week? Anyone tried to verify the data – perhaps counting # meetings on room reservation times estimated # attendees vs total time on time sheets charged to “meeting”? Anyone ever consider disabling the “meetings” time code and forcing folks to assign time to the meeting purpose, such as “design”, “plan”, “review or inspect”, etc?
Bruce Benson • Mike, Ack! Too many good topics for discussion. Great list of underlying problems. I measure everything, or so it seems, but I’ve never measured the number of meetings as a project metric. Mostly it has been hearing feedback that “we didn’t have as many meetings on this project as the last and we got more done!” If I had the inclination, I’d probably just track meetings to start (use the time codes/database) and just see what “normal” looks like over the course of a project. I’d look at both successful and not so successful projects and see how they differ (and if they do). I’d first do that first before attempting to “improve” the reporting of meetings or trying to “right size” the number of meetings.
As to just time tracking in general, I’ve spent a lot of time getting people to assign their time to the right project, then to the right activity. Just getting it assigned to the right project provides great insight. Often time trying to get it assigned to the right activity within the project is a “point of diminishing returns ” effort. I think getting time assigned meticulously (which needs its own meetings, definitions, agreements, ugh …) across dozens of activities just leads to a notion that we could then micro-manage using this data — and I’ve never yet seen that be successful (for all sorts of reasons). A few high level activity buckets are what have worked for me in the environments I’ve had to deal with.
Thanks for sharing.
More comments from around the web:
Terry Dexter • Interesting point to this article is that sharing complete and timely information between project teams is critical. However, when the project is poorly planned – expect the worst.
Question: how to qualify ‘complete and timely’ communications?
Bruce Benson • Terry, “complete and timely” is in my opinion — like so much of management — a judgment call based upon experience and upon feedback from the existing communications. For folks who need “objective” data, beside the success or not so success of the project, we could always poll folks on if they feel they are getting complete and timely communications.
Excellent point.
More comments from around the web:
Saurabh Aggarwal • I believe meetings become a problem when the discussion keeps wandering around trying to find ways to solve the effects of the problem rather than understanding the root cause of the problem…..some time is wasted on blaming people causing the problem and some time defending ourselves…
Vijay Pawar • I think that meet is always based on certain topics, if it is not going in other way it should be control by responsiable person. so that time, work & money all save.
Bruce Benson • Saurabh, Agreed. I think the art of focusing on and finding the root cause is often not recognized nor practiced well. It is also often too easy to leap to conclusions (blaming, well meaning but unhelpful “solutions”, etc.) which we can do without first doing the hard work of finding and confirming the root cause.
Mark McQuade • So, twice a day daily meetings is too much? hmmm…
Agus Kojaya • Meeting should be brief and efficient. The purpose of the mtg is to quickly go through current status and announce to do list… Dismiss. Everyone should do his/her due diligent before attending the mtg.
Andy Rozylowicz • yes, twice daily is too much
Charlotte Wittenkamp • With modern technology many meetings have become redundant, we can all follow status on group mails and shared walls and documents. Not all meetings need include all people.
Ditte Kolbaek: “Proactive Reviews – how to make your organization learn from experience” has many good pointers.
Bill Branan • If two a day is good, three a day should be even better..
Carl Kuehling • It appears we have too many meetings daily on each project. How do we get any real work accomplished when we spend too much time preparing for each meeting and attending each meeting.
Andy Rozylowicz • There are several rules I use for meetings: 1)have an owner (not just a convener) who drives the meeting content, 2)force the use of data with a standard format so people are used to looking at repeatable patterns of reporting, 3)charts with data have conclusions; don’t just put up data, 3)all 1 on 1 discussion takes place outside the large meeting, since you don’t need 30 people watching 2 people talk to each other, 4)almost all problem solving and solution creation gets done outside the meetings, because 30 people can’t/shouldn’t really create a solution to a specific issue, 5)don’t show the same data at different meetings.
Bruce Benson • Andy,
Great rules! A few comments and practical considerations: 1) Agreed, a real owner, 2) love using patterns of reporting that reinforce and train people to understand the data – this is hard to get to because the organization changes, often driven by the data-centric reporting, so I’ll have “required slides/data/reports” but leave it open for folks to add their own data or scrub the existing data differently. Over time these new view often become the new required view. 3) Yes! Tell me what you think it means, including possible alternative meanings. 4) I learn a lot listening to people talk to each other, so it can’t go on too long but I like to let the initial exchange be heard by all. 5) This one I don’t get. In fact I encourage the same data/view to be shown widely and often to reinforce the meaning/impact of the data. This is a necessary logical extension of your point #2 in my view.
Thanks for sharing.
Comments from around the web:
James Ascher • Some of the PM training I took at CSC on Skillport concerned the importance of planning all aspects of communication for the duration of a project. This was mirrored in other phases (staffing, resources, and others) of PM as outlined in The Guide.
Peter Novicki • I wholeheartedly support sharing information, especially with the project team. It helps the team understand the overall project better and helps them relate to how they fit in. It can also foment ideas for completing tasks more efficiently and effectively, as well as build team spirit. I even think that status reports should be shared – why not let your team know how they are doing?
Bruce Benson • James, Peter, thanks for the feedback. I often find that most communications is a bit ad hoc and few people seem to think about it as an essential project management tool. I would set up a news group/mailing list/wiki and tell folks that if they do nothing but monitor this source, they will be kept up to date, daily, on the project. We also had status meetings and periodic reports, but something simple such as one place to go where we religiously and brutally honestly keep things up to date, and it is amazing how much gets done and how much less confusion exists when such a source is available. This is relatively easy when projects go well, but when things start getting rocky, too often information is held back (until the problem gets resolved of course!) and that it almost always a big, project management mistake.