Minutes to Cover Your Arse

Requirements will change during the course of any project. Ideally your customer will have designated a requirements champion who signs off on the requirements. Often you will have to deal with competing requirements from multiple stakeholders.

Trying to accommodate competing requirements usually results in increased scope, and therefore increased cost, longer time or lower quality (or all three if you are careless). Project managers (customer and contractor), business analysts and engineers all play their part in managing scope.

I have a simple rule - cover your arse. I usually do this by sharing notes of any discussion with the participants of that discussion. These discussions can be formal (meeting, workshop) or informal (a chat in the corridor, over a coffee, over dinner etc.). Either way I send out a note with the contents of that discussion - a minuted record of the discussion.

To paraphrase Humphrey Appleby from the satirical comedy Yes Minister (series 2, episode 2):

The purpose of minutes is not to provide a written account of a meeting, but instead to protect people. They allow a pause where anything regrettable said in the heat of the moment can be safely put to one side and not appear in the official record of events.

Use meeting notes, minutes, followup emails to cover your arse and protect yourself.

My meeting minutes or notes contains five sections - who, where and when, notes, decisions, and actions.

The contents of each section is self explanatory:

• Participants: The participants of the discussion - full names and initials in brackets if needed.
  
  
• Where and when - location, date/time, duration: If a phone conversation, indicate the phone, or conference call number.
  
  For formal meetings with an agenda, I usually include it here.
  
  
• Notes: These are general notes made during the meeting. For example, 'Henry did a great job on that module', 'We are having further discussions on strategic direction of the company' etc.
  
  These are notes that are related to this meeting, but not necessarily an outcome. The aim of recording it here is to establish a context to this discussion and future discussions. These notes do not result in a decision or an action.
  
  
• Decisions: All decisions not resulting in an action should be listed here. For example, 'postpone module A deliverable'. 'The delivery will be made at a lower quality threshold'.
  
  Its always a good idea to indicate who made the decision - whether it is an individual participant (who may be acting as a proxy to another member unable to make it to the meeting), or the collective team.
  
  If a decision results in an an action, then add it to the actions section.
  

• Actions: List out any follow up actions that need to take place, the owner of that action, and when the action will be completed by.
  
  The owner of the action is the person responsible for ensuring the action is completed by the agreed date. Occasionally the owner may ask someone else to execute the action. Either way, the owner has the responsibility to deliver on the action.
  

All in all, its quite a simple process. Breaking it out to each section makes it easy for the reader to understand the context and result of any discussion or meeting.

For informal discussions, I try layout the notes so it can be viewed by a simple text reader - such as a blackberry. The result is a neat, clearly spaced out note that can be read and comprehended quickly.