The Grand Bore*

The room erupted in laughter when my colleague accidentally had a double typo in a sprint meeting and wrote “twat” instead of “test”…

“I blame the ergonomic keyboard”, was her response.

At least the team were paying attention to what she was writing and not mindlessly looking at Instagram on their phones. Worryingly though, none of them were writing anything down.

Out of all the Project Management tools, note taking is the simplest and yet by many it’s the last thing they think of doing.

Hey!? Why bother taking notes, surely you can remember everything in the meeting, it wasn’t that long?

Read on to find out why you’re wrong…

The number of times at university I sat in a lecture making scant notes, only to find when I approached them, later on, to revise, I’d forgotten the information. From odontoblasts to R v Ghosh, most of the notes seemed meaningless, and I had to waste time playing catchup.

Recall memory is the ability to retrieve stored information either by being cued by a particular associated item or without an associated cue. The first is called cued recall and the second is called free recall.

The “Forgetting Curve” can be a real killer to productivity, and there is a direct relationship between how well we recall information and the amount of time after the event.**

If you’re stuck, they’ll also be help from team members recall about what was said.

The Simplest Way to Take Better Notes

One of the key skills of a project manager is to “be prepared”. Invariably this means doing the things which people often take for granted, like booking rooms, making sure screen sharing software works before the calls take place, and the client knowing you’ve moved office (the last one makes for a great start to a meeting if you’ve failed to do it).

It can be challenging when chairing/running a meeting to engage with the internal and external stakeholders meaningfully, lead the conversation and take useful notes at the same time.

When I trained to be a lawyer the number one rule for court advocacy was “never ask a question you don’t know the answer to”.

Use this mantra in project meetings. By setting an agenda, you’re already steering the conversation down the path you need to go to get the project completed.

This approach also means you:

  1. Don’t need to remember the agenda;
  2. Have a set of headings to add too;
  3. Don’t have to work late;
  4. Get the written notes over to the broader team in superhuman time;
  5. Look great in front of any third party suppliers who are tardy;
  6. Can use cued recall rather than the inferior free recall memory.

I’ve taken this one step further and have often walked into meetings with a second, private copy of the agenda with most of the answers filled out based on gut feeling on what I’m going to get.

It’s unlikely you’ll be getting answers you’re not expecting if you’re running the project correctly and having regular meetings. Any parts of the conversation which are left-field, manage these by exception and get them agreed and recorded.

While the approach can seem a little over the top, it does allow you to engage people and listen to the discussion, steering where necessary. I found it to be particularly useful with complex third-party integrations into Premier League football sites, where passions are running high, not everyone is technical, and the deadlines are not moving.

Worst case scenario you have only some feedback noted down and not everything. This is still significantly better than having nothing; recall memory is significantly enhanced by cues, such as notes and diagrams which trigger you to either remember more or rationalise out what was discussed.

If you’re stuck, they’ll also be help from team members recall about what was said.

The Temptation of Delegation

It can be tempting to let other members of the team take all the notes — this does work to some extent, but as a project manager you should be guiding the conversation and not being the conversation.

In a perfect meeting, the developer or designer is fully engaged in the process and will probably not be making comprehensive notes.

If you are expecting the team to take notes, make it clear beforehand. I’ve often asked designers to make notes during a meeting; feedback can be quite tricky to follow and sometimes, the team member can add visual notes and cues to ideas they’re having which they might not be articulating verbally — you’d never be able to capture these.

The Information Advantage

As Google has proved, data is vital to successful business. Being in control of making notes puts you, as a project manager in a solid position. You can ensure that “to do” items are noted (often missed out) and what was actually agreed noted down — which can often get lost in the noise of a discussion.

When non-professional project managers are writing notes (often clients will assign someone as a PM as a secondary role within the organisation), they can subjectively pick and choose which pieces of information go into the end document.

Items including their primary job role, or something they’re simply interested in can get a lot of detail, whereas a boring technical point can be left out, even though this might be key to the entire project being delivered correctly (good examples I’ve encountered include DNS handling and server setup).

This can make “next steps” and agreeing what was discussed after the meeting difficult leading to confusion on delivery.

Not all Note-Taking Systems Are Equal

Simply making notes is the start of the journey. You can have many marginal gains by using the note taking system appropriate to the situation.

For example, avoid non-collaborative documents and generic spreadsheets. The latter is excellent for data but are often misused for bug fixing notes, or meeting points. They are hard to navigate and will tie you up in knots later on.

I’ve always loved making paper notes, and while these are better than nothing, I have seen the busy fool physically writing notes on paper then transferring them to the chosen system. There are much better uses of a PM’s time than doing the same thing effectively twice with no gain.

So far, my preferred solution has been Confluence. There are a few formatting bugs which they need to iron out, but the great thing about Confluence is the ability to have it shared with the client automatically (if permissions are set up correctly), have @ mentions in the to-do list (which are then saved in the users profile and notifies team members when they are done) and finally, (the most important) it seamlessly integrates with JIRA, so it’s easy to drop direct references to singular tickets (or you can write a simple macro to pull filtered tickets into the meeting notes).
 
Google docs are okay, but they lack the linking to specific issues which Confluence has. This is also the case with “Basecamp”, a popular system which has been superseded as a tool of any useful project management significance by the Atlassian suite.

Conclusion

Writing notes can feel like a bore, but for successful communication within a project and to retain control they are essential.

In summary ensure meeting notes are:

  1. Built around the agenda,
  2. Are appropriately comprehensive,
  3. Have actions associated with them,
  4. Are in a system capable of disseminating the information without awkward PDFs and emails.

In my experience Consistency and Persistency win most people over. Having solid, regular meeting notes go a long way to achieve this goal and achieving project success.

* Theme inspired by the Amazon original, “The Grand Tour”.

** It’s also worth noting there are many other things which affect the recall of information. This includes the amount of information you’re recalling (there’s a lot of info in an hour meeting) along with bizarre environmental factors like what food you’re eating.