A management and schedule AntiPattern. : ''Scheduling meetings to a late project makes it later.'' (derived from BrooksLaw by GeraldoXexeo) You have a problem with schedule. To solve this problem, you start making meetings. People that should be involved with delivering the project start to be involved in this meetings. Project gets later, oh... Yet another meeting will solve it. See also DesignByCommittee, DeathByPlanning, BrooksLaw and GroundHogDayProject. -- GeraldoXexeo ---- Is this not a case of AnalysisParalysis? I have seen too many projects stuck in endless meetings where people agonize over what to do instead of actually trying to ''implement'' a solution. ---- ''... and we are going to keep having these meetings until we work out where all our time is going!'' ---- I'd like to propose a specific sub-category, that of the daily status meeting. Along the lines of GodwinsLaw "As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one.", I propose Status Infinitum--"As the frequency of status meetings approaches daily, the chance of a successful deployment approaches zero." ''The duration of the meeting has to factor in there somehow, too. For example, consider daily but very very short meetings, like XP StandUpMeeting or ScrumMeetings. They often more than pay for their time by reducing miscommunications and helping detect problems earlier.'' ''In my opinion, it's not frequent meetings that are evil, but long meetings, especially with many participants. -- FalkBruegmann'' ---- I saw this one posted at my first job (I didn't stay long): the more time you spend reporting on what you are doing, the less time you have to actually do anything. Equilibrium is achieved when you spend all of your time reporting why nothing is getting done. I suspect this should be refactored elsewhere, but it seems to fit the thread at the moment. -- ChrisFay OTOH, reporting can be useful. -- BrentNewhall ---- A great application: equip all the conference rooms in your building with ID badge readers, and big NBA scoreboard-type displays. All meeting participants are required to badge in on their way in the door. The software looks up their salary or contract rates, and provides a minute-by-minute updated view of the cost of the meeting. Unfortunately, this would only capture the direct costs, and not reflect the other inefficiencies related to attending the meeting. But it is a start. -- BillBarnett ''Yes! I have heard this proposal before, and always marveled at its simplicity. I would enjoy seeing the expression on a manager's face as he strolled into his own meeting 15 minutes late and realized he had already cost his company upwards of $1000 by his tardiness. -- ChrisFay'' ''I can improve this by simplifying even further. Just ask HR to give you an approx value for the average company salary (they'll probably be able to give this out without violating any privacy rules). Then divide by hrs/month to obtain the average hourly cost per employee. When the manager walks in 15 minutes late, just multiply tardiness by number of people in the room and quietly state "15 minutes times 6 people, that's $54". No special equipment required. -- MichaelChermside'' Why were all you guys wasting time until I got here - you could have started! --PhlIp ---- Not all meetings are bad. There is also a tremendous amount of effort wasted when people do not have meetings to ask for clarification, alternatives, or help. When a project is behind, one of the most productive things to do is to get representatives of the development team and the end users together to decide how best to proceed given where we are at today. ---- I disagree with this term YetAnotherMeetingWillSolveIt. Yes, if you are not prepared for a discussion in a meeting it is useless. So it will be better to move this point and have a new discussion. The main problem I see is that in a lot of status (and other) meetings things are discussed with no preparation, or just details which are of no interest to the rest of participants. For every meeting you need an agenda with the topics described, the amount of time you want to spend and the results you want to have. I saw too many meetings with * No agenda, we only guessed what we want to talk about * Purpose of the meeting, only for information, report, coffee? * Moderator or boss is late up to half an hour * Raising new topics in the discussion (endless) * No results, we just talked about the things * No minutes of the meeting, two weeks later the discussion starts again * More than one discussion, sometimes private * No moderation at all * Extended meetings, the whole afternoon Preparation is the best (Agenda contains): * All topics with short description * Amount of time to spend for each topic * Moderator * Time and place and expected duration! * Expected results for exact topic * Minute taker or recorder * Results of the last meeting(s) or where to find * List of "To-do"s that if available Doing the meeting: * No other discussion than only the topics - if not move this new topic to the next meeting or define member(s) of the meeting to solve this * Avoid to large extensions of expected duration (each topic) * Check the expected results * Make a summary a the end of each topic (the minute taker will thank you) * Assign a "Todo" only to a present person, otherwise this won't be done. Afterwards: * Writing the minutes at the same day, directly after the meeting * Send it to all members of the meeting * CC to all interested * Keep a copy in the intranet (or somewhere else) -- AndreasSchweikardt ---- Another big problem is the place of the meeting. Why the hell do we meet in a meeting room to talk about an application when I can show the GUI/code/DB/etc from my desk? Informal ad-hoc meetings should be the norm not the exception. -------- Meetings are for people who don't know how to use Wiki's. --top ---- See also MeetingHaiku, W''''''hatAreMeetingsFor ---- CategoryManagementAntiPattern CategoryAntiPattern