Skip to main content

Author: Lauren Zinsmeister

Lauren is a PMO leader with 10 years’ experience at midsize companies. Her specialty is building Project Management practices and teams, including bespoke processes and frameworks for midsize companies.

Eliminate All Meetings? Not So Fast.

Everyone loves to hate meetings. I’ve seen so many opinion pieces on eliminating meetings, all met with cheers from people who are tired of sitting through meetings they don’t find valuable. I think it’s worth a deeper dive into meeting types so we can be deliberate about which meetings to eliminate.

 

There are three primary categories of meetings:

 

Problem solving – these are your brainstorming or whiteboarding sessions. I think most people agree that these can’t be replaced with emails and Slack messages. When the creative juices need to be flowing and it needs to be collaborative, it needs to be a meeting.

 

Decision making – this is a grey area. If the decision involves a complex scenario or significant consequences, I think it needs to be a meeting since it will likely require discussion. In these cases, my personal approach is to send a pre-read to the decision maker and all key stakeholders, which I develop in partnership with the key stakeholders. My template is this:

 

Background – this explains the broader context of the decision. The decision maker is most likely an executive with many other problems and decisions on their mind, so this helps center them on the situation.

 

Decision point – explain the exact decision needed. Is it strategic direction where multiple approaches have merit? Is it a vendor choice for software that will have a major impact on daily operations? The more specific, the better.

 

Options – Write a summary of each option. Work with the stakeholder(s) who prefers this option and include both the benefits and the drawbacks.

 

Recommendation – Tell the decision maker which option you recommend and why. You know the situation in greater detail than they do, so your recommendation based on detailed consideration is valuable. They may not take your recommendation, but you will have made yourself a resource and thought partner for them.

 

Having this pre-read ensures everyone is on the same page about what the decision point is and what the options are. This will minimize surprises in the meeting, which in turn will minimize unproductive swirl. This preparation will enable the key stakeholders to argue their point, engage in productive debate, and allow the decision maker to hear and consider options before deciding.

 

Advertisement
[widget id=”custom_html-68″]

 

Status – this is the infamous “around the room” where everyone says what they’re working on and everyone else multitasks or dozes off. I believe these are the meetings people are thinking about when they write about how to eliminate meetings. The core of their reasoning is that this information can be shared just as effectively by other means, which is often true. I would break this group into two sub-categories:

 

Type 1: Small projects with a few primary workstreams. In these cases, I agree status information can be shared just as effectively by other means. The team can collaborate in a project management tool such as Asana or Smartsheet so anyone at any time can pop in and see where things are. Simple automations can remind team members to make their updates, and dashboards can be automatically shared. The technology exists to make asynchronous status updates possible. In an ideal world, everyone makes their updates on time, everyone checks in on status, and meetings only happen when the project requires discussion. In reality though, project teams often don’t take advantage of these options, so we find ourselves in meetings that shouldn’t need to happen.

 

Type 2: Major projects with many workstreams. In these cases, there are usually clusters of workstreams where people are working together and depend on each other’s work. There are likely also workstreams that seldom interact but will eventually need to interact. In these cases, I’m a believer in live status meetings. Asynchronous updates can work for more regular updates, but I think there’s value in less frequent live status syncs. This gives everyone the opportunity to learn about what’s going on with the more distant workstreams, allows an opportunity for questions and live discussions, and lets people know in advance how something is progressing that might matter to their workstream.

 

With these meeting categories in mind, how can we avoid unnecessary meetings? Regardless of category, there are some best practices for all meetings. If those can’t be followed for a particular meeting, then that meeting can be cancelled.

  1. Make sure the purpose of the meeting is clear.
  2. Write and share the agenda in advance.
  3. Make sure the right people are in attendance.
  4. Send any relevant information in advance.

If you can’t follow these, for example if your meeting doesn’t have a clear purpose or agenda, then it should be cancelled. To make the most of meetings that do happen, end them with a verbal recap of action items, owners, and timelines, and send a written recap of the same.

 

The highest potential category to eliminate is the recurring status meeting for small or simple projects. Eliminating these without negative impact to the project will require a team effort. Everyone needs to do their part to update and check in on the project tracker. The leader can set conditions for success by ensuring the project tracker is established and expectations are clear. However, if the team doesn’t hold up their end of the bargain then the leader will have no choice but to schedule recurring status syncs. I’ve found that credibility and trust can be established by following standard meeting best practices, and especially by cancelling meetings when there is no clear purpose or agenda.

With this trust, it’s a little easier to convince the team to contribute by making their updates asynchronously. Little by little, we can move toward that ideal world where we’re only in meetings that truly need to be meetings.

Project Management for Midsize Companies

In many ways, Project Management is more art than science. Those of us who have spent years in the field have most likely studied the science of it through classes and certifications.

There are certainly best practices that apply most of the time and a Project Manager would do well to have that foundation. But dare I say, the majority of textbook concepts don’t apply much of the time? Let me share a story of a project I tried to manage “by the book” that taught me a big lesson about adapting the “book” to the needs of the company and the team.

During one of my early roles as a Project Manager I worked hard to be organized and apply all the concepts I learned while studying for my Project Management Professional (PMP) certification. I remember one project in particular where I meticulously developed a Work Breakdown Structure (WBS) and calculated the critical path. I had a Microsoft Project sheet a mile long, as this was a major project that would take more than a year to complete. All my details were in order. Project Schedule – check.

Confident in my plan, I brought the project team together. I had worked with key stakeholders to identify all the departments involved in the project and worked with those department leads to know which people should represent their department. I shared my project documents with the team and talked through roles and responsibilities. Stakeholder Management – check.

I knew part of my job was to clear roadblocks for the team, which included the roadblocks of me being a bottleneck. I thought the best way to keep everyone informed was to democratize project documents and have teams make their updates directly rather than funnel all updates through me. I created automations to remind team representatives to make weekly updates.

I had automations to notify people when one of their predecessor items was updated so they would know right away. I had automations to notify both me and team representatives when an update was overdue. Everyone had access to view, so no one ever had to wait on me to share a document or give a status update. We had weekly status meetings to allow for discussion and broader visibility, as well as ad hoc meetings for specific topics as they arose. Transparency and Collaboration – check.

 

Advertisement
[widget id=”custom_html-68″]

 

If you haven’t already guessed, let me tell you how this worked out. Not a single person ever went into the project tracker to make an update. Not a single person ever went into the project tracker to see status. My first pivot was to start collecting updates weekly and input them into the tracker myself. This allowed me to stay closer to the project details and gave me an opportunity to do a weekly assessment of project health with more context.

Those weekly conversations turned out to be so much more valuable than independent updates in the tracker. Every week, I would take this updated tracker and the deeper context I had to give a status update. I would share my screen and show the tracker so everyone could see visually where we were compared to the overall plan.

If you haven’t already guessed, let me tell you why this failed fast. If every team was meeting with me weekly to give me an update, why did they need to sit through a weekly status meeting of me telling them where their items were in the project? They didn’t. I lost the team’s engagement fast. My next pivot was a change that has stuck with me through the years. I did the legwork to meet with teams, understand their status, challenges, dependencies, needs, and projections. I consolidated all the information and culled it to down to what was critical.

Every Monday I sent an email with the week’s game plan, including all work expected to be done with deadlines and names of people responsible for doing the work. Every Friday I sent an email as a Reply All giving an update on what had been completed as expected, what had changed, what was delayed and why. If something meaningful changed and needed discussion or a decision, I would schedule a meeting to discuss it. We now had emails for things that could be emails, and meetings for things that needed to be discussed live.

This raised my credibility with the team when I called a meeting, because they trusted that there was something meeting-worthy to discuss rather than just a status update that could and should be an email instead. My Monday “game plan” emails served as an easy reference for project team members to know exactly what they needed to work on, which increased the rate of project work completion because there was more clarity and it was easily accessible.

Nearly 10 years later, I still rely on this approach. My Monday and Friday templates have evolved as my projects have changed, but this approach has proven successful time and again.

This semi-informal approach to Project Management would likely not succeed at a company with tens of thousands of employees. With larger teams and greater numbers of stakeholders, proper project management tools and formal project communication methods are likely necessary. On the other end of the spectrum, this semi-formal Project Management with meticulous planning and centralized tracking is probably more than is needed at a small company.

When teams are small and work closely together, it’s much easier for everyone to know what everyone is working on without a person dedicated to keeping it all organized. My time at midsize companies has helped me find this Goldilocks approach somewhere in the middle.