If you’ve gone through the trouble of regularly creating a meeting agenda and gone a step further in crafting the agenda so it has an easily understood purpose and objectives, you’ve probably realized a central truth.
Not all meetings are created equal.
No, I don’t mean that some meetings are an abysmal waste of time and may, in fact, endanger your long-term health. Unfortunately, that may be true. I mean that you’ve probably realized that one meeting format doesn’t fit every need.
Especially as you are bombarded by people eager to innovate the dickens out of your workplace and “maximize value streams” or whatnot, you might be pressed to change how you’re doing business. That’s not bad, but as some improvement coaches can be hammers in search of nails, it’s important to remember:
One meeting size doesn’t fit all.
If you’re sincere about trying to make meetings effective –not just blocks of time people get together because “that’s what’s done”– and if you want to be honest about your meeting purpose, you’ll know that one meeting format does not work for every purpose… or even group of meeting attendees.
I can’t say I’ve got a magic formula for this, but especially with those of you who are tasked with being in charge of a project or a program, I think it’s useful to think of three different types of meetings. Those are:
- Status Meetings (Ongoing)
- Issue-Based Meetings (Sometimes Ad-Hoc)
- Lifecycle Meetings (Planned Status and Issue-Based Meetings with limited duration)
These three broad categories give you a framework for how to plan meetings — and to better understand what meetings you need to accomplish what objective. Let’s delve into each type:
1) Status Meetings
PMPs and other project managers are probably very familiar with one form of this type: the Weekly Project Status meeting. Most, if not all, of the project team meets to review the schedule, how we’re on track towards approaching milestones, and reviews project risks, issues, and action items.
“Daily Huddles” and “Daily Scrums” are also versions of status meetings. For many teams, these daily meetings have replaced the longer half-hour to hour weekly project meetings they previously held to monitor progress.
The frequency of the meeting usually indicates whether the discussion is more about tactical matters or strategic matters.
For example, if you’re finding your team is having problems with niggling impediments like software licenses or access, you may want to fold in some form of daily huddle to catch those issues quicker. Likewise, if you feel your team is getting a lot of “actions” done, but you don’t seem to be getting closer to your overall goals, you might need more status meetings where strategic goals can be discussed and further defined (note: depending on what level you’re at, this may depend on strategic conversations happening above your pay grade, but hey, at least you’ve identified the need!).
And be open to the fact that you might want and need both a daily and weekly status meeting. For example, the daily huddles could be purely about individual team members’ progress and impediments, while the weekly meeting could be status reporting with both the team and external stakeholders.
In all cases, be mindful of the audience and the purpose of the status meetings to ensure you’re not repeating the same message to the same audience. In fact, you want as much of your status and reporting to be accessible to most stakeholders (if possible) outside of meetings so that status meetings can be more about status questions and concerns, not simply information delivery.
2) Issue-based/Ad-hoc Meetings
These are one-time meetings or a series of meetings held to accomplish a specific objective.
You may recall that, during regular status meetings, an issue might come up and someone, usually the facilitator, says, “Let’s talk about that offline.”
More often than not, that offline talk is going to be an ad-hoc meeting.
(Yes, that offline talk may be 2 people for 15 minutes, but even if it’s quite informal, it’s still a meeting to be held.)
Not all issue-based meetings need to be unplanned or reactive, however. If an executive has formulated a new initiative, your standard operating procedure may be to schedule a kickoff meeting or brainstorming session with the appropriate stakeholders.
You also may find that, due to uncovering some risk or issue during your regular status meetings, you need to have a series of meetings to address said risk or issue.
Two examples come to mind from software projects. In one case, we found out user acceptance testing wasn’t going as smoothly as we wanted and some major defects were found: defects bigger than we expected that jeopardized the release. We established a series of meetings with both business representatives and the developers to go through what workarounds could be created and what parts of the scope could be pulled back because it was determined we needed to launch “something.”
In another case, we were deep into development when we discovered a huge disconnect between the business and the IT teams on the requirements. We set up a daily meeting for a week to work through a host of previously unasked questions. The combination of all the stakeholders attending and a daily cadence meant a lot of the bull we dealt with previously fell away.
In both these cases, these issue-based meetings were in response to issues that came up with the project or program and needed to be addressed outside of the normal status meetings.
This is why it’s all the more important to understand the format and agenda for your status meetings. Sometimes, you can fit in the risk or issue at the end of the meeting after the main business is concluded (and attendees who are unaffected can leave). Regardless, it’s critical for any ad-hoc meeting to have an objective in mind, even if it’s simply to figure out which stakeholders are needed to discuss whatever risk or issue needs to be discussed.
3) Lifecycle Meetings
On one hand, these are simply variants of the first two categories: any lifecycle meeting is going to be either a status meeting or an issue-based meeting. However, I find it useful to think of them as a third category because of our natural tendency to want to “solve things once.”
Put another way, many of us want so much to establish a routine, we forget we could have a subroutine.
That’s where the Lifecycle meetings happen. For those of us that have done publishing, product launches, or software releases, there are certain meetings you have through the lifecycle of the said launch or release. There are checkpoints and reviews and tollgates that ideally occupy their own space and time separate from a status meeting. In addition, they’re not –or shouldn’t be– ad hoc. You know you’re going to have a meeting on that issue or topic and so you plan for it.
Here are some examples:
- Before greenlighting the product launch, you need to have a meeting with marketing and legal to address any concerns they may have
- Whenever you stand up a new technology system, you always need to walk through security and privacy impact assessments with your Information Security group
- You hold a series of requirements gathering meetings with stakeholders before beginning a design phase
- Before you conduct a software deployment, you go over the release plan for that weekend.
- You conduct a series of user acceptance test sessions
- Right before a product launch, you hold a series of training sessions for your customer support staff, so they can answer questions about the new product
- Right after a product launch, you have a daily status meeting to check on how it’s doing and address any “early life support” issues
- You have a series of lessons learned meetings with stakeholders after any project to help prepare the overall Lessons Learned document
- And so on.
Remember, there’s often a temptation to stuff in some of these topics and work into existing meeting structures. And depending on the maturity of your meeting culture, this might work out fine.
But look at all those examples: you know you’ll need some of these meetings. Many of them are almost certainly going to involve people not in your regular status meetings. And there’s no reason to put off scheduling a meeting if it or a dependent outcome is in your project schedule.
And this is one of the other reasons I like to break out the “Lifecycle” meetings from both the status and issue-based meetings. Because people push back at planning for possible meetings the same way they often push back on risk planning (“there’s just too many variables!”), but they have a lot harder time arguing against things like planning to get input on requirements and such.
And once you have a lot of these lifecycle meetings identified and planned for, you might find a lot of the ad hoc meetings are simply unplanned versions of them… and in some cases, you’ll be able to plan for those meetings next time.
Because the life you save from abysmal, soul-sucking meetings may be your own.