Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

SQLAndy

I'm Andy Warren, currently a SQL Server trainer with End to End Training. Over the past few years I've been a developer, DBA, and IT Director. I was one of the original founders of SQLServerCentral.com and helped grow that community from zero to about 300k members before deciding to move on to other ventures.

The Daily Status Meeting

For the past six months or so I’ve hosted a daily status meeting for a large project. It started out scheduled for 15 minutes and as the team grew, I found that we often ran out of time – not due to idle chit chat, but because we spent 3 or 4 or 5 minutes to work though an issue that was a road block, and so the meeting was extended to 30 minutes. Probably many of you are already thinking that this is a meeting that has gone off the road. We’ll come back to that.

The daily status meeting is a technique I borrowed from Scrum, aka the daily stand up. No amount of email can replace the collaboration and knowledge share that happens when you put people in a room (or at least on the phone). Scrum calls for roadblocks to be identified and then taken off line, but that isn’t easy when you need time with a group to resolve it, and the next free time on the schedule for the group is a week away. We use that time as the one time each day when everyone is available.

I spend at least 30 minutes preparing for these meetings, and often closer to an hour. I review open items, things that were completed, questions I have or that others have, all compiled into a set of reminders for me to make sure those items get attention during the meeting. That’s good time for me, it forces me to think every day about where we are,what we need to do next.

On any given day half of the attendees will dial in. I’ll note their names and typically call on them early,there are quite a few that are only available for the first 15 minutes and I need to get to them first. I pick names not quite randomly and ask for status. I say not quite randomly because there are some people I have to talk to each day and I won’t put them last, but other than that I try to mix it up a little, mostly to make sure everyone is listening the entire time.

It’s always interesting to hear the things that come out in these meetings. Reminders, follow ups, clarifying questions, referrals on who to talk to about a particular issue, concerns about risks and change windows and rollback plans, budgets, and more. Could all that be done in email, or separate meetings? Some of it could, but a lot of it I think wouldn’t – they wouldn’t have known to ask.

As we go I’m taking notes and checking against my list of things to check on, for most meetings they all get covered and we’re done when we’ve gone around the table once, some days I have a few items to inquire about, and then we’re done.

Average attendance for the meeting is 12 people, lots of days when it will go up to as many as 25, and by my informal estimate we’re averaging about 20 minutes per meeting, trending down now that some of the most intense tasks are nearing completion. My goal is to be done when we’re done. No longer than 30 minutes, keep the meeting moving, and if I can give them time back, I do. Right after the meeting I type up my notes and send them out, every single day.

So back to my opening paragraph and the dangers of a 30 minute status meeting. Meetings can be expensive, but that isn’t a good reason to not have them. Meetings take time, but that isn’t a good reason to not have them. I’m not saying everyone should have a daily meeting, or that it should take more than 15 minutes if they do, but I see a lot of teams that suffer from “meeting fright” and don’t meet because it might waste time or money. Meetings can certainly be a waste – but they don’t have to be.

Here are some tricks for a good status meeting:

  • As I mentioned above, prep for the meeting – it will drive everyone else to come prepared when you push them on things they should have surfaced
  • Publish notes right after the meeting, and use it to call out problem areas for anyone that couldn’t attend. Knowing that things will be in the notes influences behavior! (I also include a list of who attended and key project metrics)
  • Keep it moving, but don’t be afraid to drill down for a minute or two on a hot issue
  • Don’t put all the weight on yourself to ask all the questions, let the team interact and drive the discussion some

Finally, remember that as the work changes the meetings may need to change. As this project nears completion there will be fewer people needed on the call, and once it ends there won’t be a need for the meeting at all.

Comments

Leave a comment on the original post [www.sqlandy.com, opens in a new window]

Loading comments...