MoreProductiveStatusMeetings

This thread's genesis was the ScheduledAndUnscheduledTime thread.

Big time-wasters are hour-long status meetings... 15-minute stand-up meetings are just as effective for spreading information, if run properly. Short emails and Wiki's are simple and easy for maintaining information for managers too busy to ask and listen to answers. Problem-solving meetings rarely need to be scheduled for every week with lots of people.

KeithRay 2005.01.23

I agree with Keith on hour-long status meetings. I would much rather get status via e-mail and a fifteen-minute stand-up.

To achieve the best teamwork, what would an "ideal" status meeting be like to take into account all of the temperaments of the MBTI?

CharlesAdams 2005.01.24

Short. The introverts need to know the agenda in advance, so they can prepare their thoughts. The extroverts need to know the agenda in advance, so they can rehearse what they'll say to keep it short. The NTs need to know why. The SJs need to know the next steps. The Ps need to know the decisions aren't being short-cut. The J's need to know a decision will be made promptly. The NFs need to know how the community is affected by the information, and I'm not sure about the SPs. (Does someone else know about the SPs?) To me, this is all in service of preparing people so they know what is expected of them in a status meeting, and how the information will be used.

People who prepare status meeting agendas in advance, or run a standup meeting with an already-known agenda are much more likely to meet the needs of all the types (because they'll have thought about what they want). -- JohannaRothman 2005.01.24

The SP's don't need to know a thing. They'll wing it, pretty much regardless of what you do. If you do something to take care of them in one way or another, they'll do something else. -- JimBullock 2005.01.24 (Making it up as I go along.)

If status meetings need to be "short," why do you speculate that they are longer than necessary?

My answer is that the people who host the meeting, typically the project manager, enjoy it. I notice project managers who love to use the meeting as a bully pulpit to berate people in front of their peers. I suspect that the PM thinks that embarassing people will change their behavior and the fear of being publically embarassed will keep their peers in line. I suspect this behavior tells a lot about what motivates the PM.

[The "I have Status and You Don't" meeting? -- KeithRay] And I Bully You With it. SteveSmith

How do you initiate a change?

I'm an NF. If I feel safe, I would speak my truth in font of the group. I have been known to say, "I invested an hour of my time in this status meeting and my return is zero. I propose the following changes to the meeting...?"

SteveSmith 2005.01.24

My experience is similar to what Steve noted above. We have long status meetings because some of us enjoy them. Sometimes the project manager enjoys it for reasons other than berating people.

Sometimes I have been the project manager and I have held longer-than-necessary status meetings. The reason was that it gave me a chance to relax with people I knew. As the PM I was being pelted by questions and tasks from people above me. The status meeting was one chance to sit down, rest my feet, talk with friends, and not have any more tasks given to me. It was sort of an escape.

I think many project managers have this exeperience - the status meeting is an escape.

DwaynePhillips 25 January 2005

Thank you, Dwayne. I agree that status meeting are often an escape for the PM.

BTW, I have seen more meetings like you describe than I have of the bully pulpit variety.

I think some people are frustrated because the meeting is not an escape for them -- it's a trap. And they want to be free.

SteveSmith 2005.01.25

I'm not sure I'm right about this, but as a line manager, PM, and / or change agent I often use the first of a series of status meetings as a: "Let's figure out how we're going to do things" meeting. Having the two topics in the first meeting ties process design and process execution closely together. With either process execution or process design on its own, you can get the endless, perfect theoretical process that nobody does, or random execution in the worst possible way. Often both at once.

Often in initial meetings where I am nominally "in charge" there is a large element of "how I want to report results" in those meetings. I think it's important to make a distinction between dictating to people how to do their work and requesting what I need as the person responsible for the overall performance, and for helping them be as effective as they can be. As their boss (of whatever flavor) I'm an advisor for how they do the work, their customer for the results, and a supplier of the environment to do the work in. I need the information I need to do my job, just as they don't need me meddling or dictating stuff where they're the experts. That's why they are paid, after all. They tell me I'm pretty reasonable about what I need. My bosses tell me I'm pretty good at keeping them informed of what they need to know.

With ongoing work, sometimes the "status" meeting starts to talk about changes to how we do our work. The initial meeting set that tone, making that topic legitimate. I, personally don't mind this as long as we explicitly recognize the distinction between reporting status and working on the process. For me, the process is always on the table if we want it to be. If it isn't working (for us, right now) change it. Thus one of my objections to overly-presrciptive methodologies be they big-bang, or incremental, document-heavy or "agile." I much dislike the abdication of responsibility for getting the work done that goes with uncritical adoption of any method. If the method were the solution, we wouldn't use people. We'd make a machine and turn the crank.

Since people have generally budgeted time in a status meeting for the short status part, I prefer to take the initial introduction of the interest in change as data. Then we schedule some extra time associated with the next status meeting to talk about process change. Doing it this way gives the introverts time to think about the change. It gives whomever proposed the change time to cool off. Often a change is a reaction to the most recently stubbed toe, costing in aggregate more than it saves. Doing the change discussion in the status meeting also gives us a reality check right then and there. How would we know where we're at and what we're doing with this change in place? Does this proposed change satisfy all the stakeholders as well, or better? (Often a "change" proposal is a repackaged demand to satisfy one stakeholder group at the expense of another.) Would this other way of working really help us get things done, for example the things we're engaged in right now - this very status list?

It seems to work pretty well, so far.

-- JimBullock, 2005.01.25 (Satus? All is well. We are doomed.)

Jim, The meetings you describe sound different than the typical status meeting, at least the kind I know about. The first meeting sounds like a requirements meeting about statusing the project. Your team designs a solution. And tests it with status meetings. If a participants detects a process problem, you schedule a problem solving meeting.

Although all these meetings are under the umbrella of a "status meeting", they are three separate kinds of meeting, at least in my mind.

I know you will let me know if I'm interpreting the post correctly.

SteveSmith 2005.01.26

Fair enough. Three different kinds of conversations around statusing. I think that's a big problem with "status" meetings - being three different kinds of things without recognizing them as so. FWIW, I usually call the first meeting something like: "Let's decide how we'll track what we're doing." The possible, incremental re-design should it occur (and it does) is explicitly recognized as a second topic, scheduled coincident with the "status" cycle for convenience - the folks who must do the work and track the work are there, so why not?

FWIW, for status I'm personally strongly biased toward the following, but it's not what I insist on all the time, even as boss:

A scope, usually an inventory of objects, intentions or similar.
States for the things in the inventory. State changes are interesting. Report that.
What changed since last time? What do we expect to change by next time?

That's it. FWIW one pernicious invasion into "statusing" that I see all the time is projection / estimation. We get some piece of new information - a "status" - and immediately want a new projection: "What does this do to the delivery date, six months hence?" There are two approaches to this that I use:

Make projection it's own activity. Once in a while, we go rework our projections based on tracking data (what we got from the statuses.) That's a thing we decide to do, then track but do not execute in the status meetings. A lot of endless status meetings are about exploration of various scenarios, arguments about projected outcomes, and so on.
If it's that all-fired important and we have to know every time, make providing a revised projection part of the status, each time, every time. The deal here is, however, that events don't get reported until their impact on the projections can be assessed, which introduces some delay. Sorry. Nothing is free.

I particularly despise the exploration / projection debates in "status" meetings used as a way to beat down someone's assessment of the impact of new information. Catch them cold. Then they express a large impact, but weakly because they're not sure. Let the argument begin: "But it can't take that long . . . " One move here is to step to the meta-level. "Oh, we're working out the possibilities. Let me clear some more time on my calendar." As boss-facilitator guy I insist that everyone play fair. As not-boss, it's sometimes a bit harder to make happen. Personally, when put on the spot I'm OK with asserting "I don't know." as many times as it takes, and incidentally declining to own a projection I did not agree with.

Then there's "But last week, we said . . . " morphing an estimate into a commitment by stealth. "Actualy, you said. I said 'I don't know.' Also that was an estimate, not a commitment." Same goes for ideas that one is blue-skying. Great way to narrow solutions and create silence, that, holding people as commitments to things they threw out as wild ideas. You'll do that once, maybe twice, then you'll get the most circumspect, padded information you have every seen, forever more.

If you want to know what I have observed, I'll tell you immediately. If you want me to tell you what that means, I need time to think. If you want to tell me what that means, OK tell me - you can form your conclusions at whatever pace works for you. Sorry. That's the best I have.

I find a lot of the pushing for estimates, projections and similar in "status" meetings very odd, because I am often told that I am very quick on the up-take and similar. Not about this, it seems.

-- JimBullock 2005.01.28 (Sometimes a status meeting is an invitation to muse . . . )

Jim Bullock: I find a lot of the pushing for estimates, projections and similar in "status" meetings very odd, because I am often told that I am very quick on the up-take and similar. Not about this, it seems.

Don't worry. You are still "very quick on the up-take." You are just looking at a different dimension than the other people.

The people who want estimates have a story to update. And they craft that story for people who care about when will something be done rather than what is the state of things to be done.

I agree with you that state information is required to provide a new estimate. The estimate people are just trying to expediate getting to the "bottom line". You wisely demand an intermediate calculation that updates the state information before formulating a new estimate. That's smart. And, if you explain the process to the estimate people, they will agree.

Does that make sense?

Makes sense. Thanks Steve. Remains to be seen whether I can remember to use the "expose the process" step when that's what I'm doing. - jb 2005.02.01

SteveSmith 2005.02.01

Updated: Tuesday, February 1, 2005