The Pitfalls of Project Meetings
Jared Whitaker, Founder and Managing Director at Ideologic, looks at the problems surrounding project meetings, and how to solve them.
“I couldn’t get any work done because I was in meetings all day!”. We all know that feeling, and when you look at it objectively and step back, you realise what a ridiculous concept that is. Work meetings are preventing work? It is definitely the case a lot of the time, and it’s not because meetings are wrong, it’s because the wrong meetings, run the wrong way, are wrong. Meetings are the cornerstone of collaboration, yet meeting management is a skill or area that isn’t really focussed on when it comes to project management. You will find endless tools for building a project plan, but very few to help run structured meetings.
If we look at project meetings (including Project Team Meetings, PMO Meetings, Project Finance Meetings, Risk Meetings, Approval Meetings, Governance Meetings, Steering Committees, Planning Meetings etc.), this meeting time usage for a project manager does not stop with the time the actual meeting takes. There is the pre-meeting prep such as agenda setting, chasing meeting acceptances, pre-meeting actions, material creation, and then there are post-meeting actions like minute writing and chasing updates from anyone who did not attend.
For larger programs or Strategic ones, we can often multiply the time taken due to larger teams or even International teams, so finding a meeting slot that works for everyone becomes harder and getting updates does as well.
Let’s look at some of the items surrounding meetings, some of the pitfalls and the problem statements.
Time
For time, let’s focus on two aspects – the actual time slots of meetings, and the time spent in meetings.
Finding a time slot that works for an entire project team, or even worse, the Project Steering Committee made up of execs and senior leaders, can be hard at the best of times. The larger the team, and the more diverse the geographical footprint of the team, and the options narrow dramatically. Add to that meeting no-shows or people that have to attend to an urgent issue, and the problem statement is simple to see. It is incredibly difficult to have every person needed for every meeting available at the same time, and for them to actually all attend your meeting.
Now let’s look at the second aspect – time spent in meetings. Meeting lengths are generally defined by standard blocks of 30 minutes. On average you can expect something like a team meeting to be an hour slot, and a Steering Committee maybe an hour to ninety minutes long. In my experience, the length of time spent in the meeting is more closely linked to how long the meeting was booked for, rather than the amount of time actually required to achieve the meeting objective. Some meetings could be 20 minutes long, and others could be an email! So again, the problem statement here is simple. Why are meetings not run more effectively and focused on achieving an objective to reduce the amount of time required in meetings?
Minutes
Aaargh, minutes! The bane of so many project manager’s existence. From the template, the format, the agreed SLA within which to send them after a meeting, to the actual taking of minutes and making sure they represent the meeting, minutes can be a lot harder than they seem, and also they can be incredibly useful, or just plain ignored. Actions and decisions required captured in the minutes then also need to be captured elsewhere so that they aren’t lost track of. Often this is something manual like an Excel spreadsheet, so the management of the actions against their due dates is the responsibility of the project manager. So, for minutes then, there are a few problem statements. They can be time consuming, repetitive in the fact that they must be then be captured elsewhere as well, and they can be left unread, ignored, or not agreed with by the team.
Actions and Decisions
Project meetings should in theory be used to provide feedback, check the status of actions, or raise decisions that are required. Other items can be involved, but those are the key areas that need to be addressed. As we highlighted above in the Minutes section, actions and decisions are largely captured during meetings in the minutes, then transposed into an action or decision log, and manually tracked by the project manager. They have to be followed up on, have the assignees reminded that they are responsible for them, and tracked against their due dates. Not only is this very time consuming for the project manager, but there can also be actions that slip through the cracks or slip past their due dates. The problem statements therefore can be shown as: Managing actions and decisions can be very time consuming, and actions can be lost or slip past expected due dates causing project slippage.
Audit Trails
For regulatory or strategic programs, audit trails are often required, either internally or possibly even externally. For a project manager and team, they must have a project repository where everything is uploaded. These items include meeting minutes, action logs, decision logs etc. What can be difficult for the team is making sure that everything discussed in email or even Instant Messengers is captured in these to best represent the full trail of the project or program. Finding these can be extremely time consuming, and its very likely that some things will be missed, and just as likely that given the amount of disparate items (minutes, logs, emails etc.), an auditor will have a hard time making sense of it all. Problem Statement: Making sure everything related to the project can be found in one location can be time consuming, and will likely not be fully complete, or easily reviewable.
These are just some of the pitfalls of Project Meetings, and some of the problem statements surrounding them. You’ll notice one of the general themes running throughout these is “time consuming and even then, might not be 100% effective”.
So how do you solve for these problem statements?
Step 1 is to make sure that you have standard, repeatable, templates and processes for meetings.
Step 2 is to focus on bringing structure to your meetings. Look at attendees, agendas, and the desired outcomes of meetings.
Step 3 is to try and automate where you can, or even if you can’t automate, use a tool that will help prevent rework, such as writing minutes and then adding the same minutes to an action log.
Step 4 is to adapt. As your project runs, you will need to constantly make tweaks and optimisations to your process. Over time it will run smoother and faster, and everyone will be on the same page.
If you can find a solution that does all of these things for you, then even better.
