Meetings – The who and what

Assuming you’ve put some thought into whether the meeting is actually needed or not, then the next step is to think which poor souls will be having chunks of the lives eaten up on a regular basis.

I’ll state up front this is a long post; communication is key to projects and meetings are key to communications. However, there is a lot of room to get them wrong and waste a lot of time. By focusing the meeting to get the maximum value, the result is meetings that are better attended than waffle sessions.

Below I’ll cover two points in detail, but the summary is:

  1. Carefully consider who needs to be in the meeting
  2. Ensure you get the agenda out in advance:
    1. In an agreed format with the pertinent details clearly listed;
    2. With enough details for the attendees to be adequately informed.

(The follow-up will be the next post).

The benefits of a focused meeting pay dividends and make them a useful tool for the project. Alternatively, if you don’t put in the effort up-front then the meetings become a sink and will drain a wider group.

Identify the Victims Attendees

First start by identifying which people are going to have significant chunks of valuable time sucked into the meeting, or series of meetings. One simple rule should be only invite those people who absolutely have to be involved. Spectators are acceptable as long as they remain on the side and passively observing. Agile formalizes this with the chickens and pigs fable, but I think it provides a clear lesson for all meetings. What the project meetings need are knowledgeable and empowered decision-makers. In some cases the notes and agenda provided before the meeting are key to providing that knowledge).

Generally, as soon as you start on a project you should be identifying and updating the sponsors and stakeholders, and this needs to be quickly formalized for everyone’s benefit. The first step is to identify who needs to be there, and that should ideally be people with the authority and experience to make decisions and commit the project to them.

The PMBoK has the Stakeholders identified in the Project Initiation, quickly followed “Plan Communications Management” in the Planning. Since communication is key to a Project is makes sense to cover this very early in the project. Ideally you want to establish a rhythm – daily team meetings, weekly PM meetings, monthly steering, and rules for calling exceptional Aagh!Help!TheWheelsHaveFallenOff meetings. For larger meetings there may well be formal committees with quorum limits; for smaller projects it may be just a single sponsor or their representative who will join. Either way, you need to tailor the meetings and schedule to fit the reality of the project.

When thinking about the potential attendees, there are some people who simply have to be there. The first port of call should be a list of the stakeholders and project teams (the PMBoK has the Stakeholder Register for this listing amongst other details.)

For example, if we’re about to make some decisions that are going to fundamentally change the project then the key stakeholders – especially the ones who pay the bills – must be there, or appoint someone with the full authority and remit to make the decision for them. If the changes are minor, say modifying the delivery dates of some trivial documentation that has zero impact, then it may be enough for just the PMs on each side to decide and commit to the change. Similarly, the Project Sponsor may have set ideas on how information should be provided – some are happy with simple one-page traffic light reports, others want the detail available.

The make-up of the meetings needs to be agreed early on as it will impact the budget and schedule estimates. If it takes two or three days of effort to create the meeting pack for monthly Steering, then for a 12 month project a) you’ll want to bill 36 days to the client and b) you’ll need to get these over to the Steering Committee at least 2 business days out to allow them to review and digest so the meeting can focus on the decide and commit.

Once you have the participants, both you and they will need to juggle availability to get the meetings on the various calendars. This is another reason to get a rhythm established as for longer projects people are less likely to double-book if they know that the first Wednesday of each month is the big project meeting. Similarly, if your steering meetings are pulling in senior staff or C-suite executives then you’d be surprised just how far out they already have commitments.

Now we have the attendees agreed and the meetings committed to mutual calendars, the next item should be the agenda.

The Agenda

In short, the agenda details the items to be covered in the meeting and should include supporting documentation. The first couple of meetings should be used to garner feedback from the attendees to allow the format to evolve to best fit the project’s needs. After a few meetings the format should stabilize to a regular format which will also allow attendees to quickly digest the information.

The only “standard” items I’d suggest for every agenda are:

  • Clear statement of the date, time and place of the meeting;
  • The name of the meeting (eg. Steering Committee, etc.);
  • The chair (ie. who is responsible for running the meeting). Larger projects or PMO teams may have a meeting organizer, in which case their details should be listed.
  • The status of the agenda (whether draft or final) and the security (Client Confidential, Internal Only, Burn laptop after reading, etc.) For confidential documents I’ve found it helpful to state this as part of the filename as well as stating it in the document.

If your teams are located in multiple time zones then make sure the timezone is clearly stated with the time; I normally use the timezone of the chair. (I’ll use chair in this post, however if you’re using a meeting organizer – say your Project Admin team – then you should clearly agree roles and responsibilities as part of the Communication Scope.) If you’re attending from outside the host timezone then be careful in the Spring and Autumn to check for when daylight savings occur. For example, the US and UK put their clocks back in the Autumn at the same time, but the US puts them forward a few weeks earlier than the UK.

It is well worthwhile having a template for the meeting agenda. Once you’ve modified it for the meeting and project at hand, you can the reuse the previous agenda as the base for the next meeting’s agenda. For projects with remote teams, the agenda should include the dial-in details for attendees, and attendees should check before the meeting they can access the dial-in. Sometimes there may be a specific number to call from a country, sometimes it is a generic number. Either way, it pays to take a couple of minutes to dial-in ahead of showtime to ensure that your phone is allowed to access it.

The order can be left to taste or to feedback from the team. I prefer to start with a review of open actions followed by the relevant activity since the last meeting, then cover the key areas of the project that are ongoing. For larger projects this could be a phase by phase approach; for smaller projects it could be all in one.

Whether large or small, the meeting or section should look to get to the decision-making as soon as is practical. The attendees should be in agreement that they are committed to review any supporting documents ahead of the meeting so that valuable time isn’t wasted.

Ideally this should allow the meeting to quickly move to the core reason for gathering people in the first place; is there any significant news, risk, or issue that needs to be address or confirmed at this point in time. This could be regular project activity such as confirming then agreeing/rejecting Change Requests, or updating or adding new risks. However, it could also be more significant; for example, a regulator is proposing a new requirement which could significantly alter the project landscape, or even render its underlying business case invalid.

For organizations where historically meetings were used to update key stakeholders and keep them appraised on any significant issues or changes, the move to meetings that are focused around ‘decide and commit‘ can be hard. One way to get them to move toward this is to go back to what they need (a clear statement on where the project is) and how best to deliver it (via the medium of modern electronic communications, not verbose waffle).

In this situation, the information they need to fully understand the current and future status of the project should be provided ahead of the meeting in a format agreed between the project teams. All parties then review ahead of the call, and the call acts to confirm they have read, understood, and agree with the status. The meeting can make the decision about whether the information is sufficient, and move on.

If there is a question or concern, these should be raised back to the chair before the meeting. The chair can either provide additional information or clarification, or agree there is a genuine issue for the meeting to make a decision on how to address.

From a general process view, if an attendee cannot make a meeting then they should confirm this to the chair; if they are a required attendee then they should provide a replacement with adequate knowledge and authority to make decisions on their behalf.

Another key point is that the meeting should also confirm that the minutes of the previous meeting was accurate and accepted. The minutes are one of the key take-away items from a meeting so I’ll cover that in a future post. Some clients prefer that the previous meeting’s minutes are included with the agenda, some do not, most are agnostic – however, make a point to at least discuss which approach and agree.

If the minutes are disputed, do not use the meeting to argue it out unless either a decision can be agreed quickly, or the dispute is so fundamental as to be a roadblock. Otherwise, it can be noted there was dissent, and whether any follow action was agreed. Issues with the minutes should ideally be raised ahead of the call as per questions about the status. If the issue is agreed as too significant to agree outside the meeting, then the details of the contention should be provided with the agenda to allow the meeting to review and then move to quickly and decide how to resolve.

Generally, the Agenda should list all those matters which the meeting needs to discuss in detail and which require some action or decision. If this needs to refer back to some other document provided with the agenda you may want to consider noting the document and page so people can find it quickly if then need to cross-reference.

The list of agenda items (which is apparently called the agendum) should see each item consist of a clear and accurate heading that concisely describes the item. For regular meetings these items should be consistent from meeting to meeting so encourage a regular flow to the meetings and allow them to be quickly tracked down in minutes, etc.

Since we’re trying to position meetings to focus on ‘decide and commit’, for each item we should either state in an agenda a recommendation for consideration, or at least have one or two in mind. (As a general rule whenever I bring an issue to a meeting or manager I always like to have some ideas of how it can be fixed, removed, or absorbed). For these recommendations we should also be clear whether the recommendation is one that the Project team has reviewed and recommend the meeting accept and commit to, or is simply one that the team would like the meeting to consider.

Some agenda lists are simply a series of bullet points, especially for smaller or more informal meetings. For large, or formal meetings (such as decisions on whether to continue a project or move to the next phase) it may be more beneficial to have pertinent background information and reference back to other documents as needed (minutes, scope documents, etc.) Of course, this also means more due diligence off the chair before the meeting to make sure all these documents are available to attendees and are correctly referenced. If you are going to recommend a course of actions, make sure you have the information to justify your decision.

I find that regardless of the list of agenda points, the last one should be “Any Other Business” to allow the meeting to capture anything that was missed ahead of time that really cannot wait.

Finally, I always find it useful to confirm the date and time of the next meeting – particularly handy with multi-site/national teams that observe different holidays.

Hopefully this should all lead to a quick and productive meeting with the minimum waste of people’s time. Once out the way, you then need to look at capturing the decisions and such… which I’ll cover next post.

This entry was posted in Uncategorized and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s