I had come out of a big presentation, and one particular thing that resonated with me (as I had been thinking about it a lot before hand) was how to recover time – or at least not waste as much. (It was actually in the context of allowing line managers to have enough time to learn new technologies, but really it’s relevant to saving time for everybody.)

One area raised was the time spent in meetings. Meetings are clearly important – they get engagement, multiple people interact, there is discussion, etc. (OK, I should say *most* meetings are important!) But how can they be made more efficient and effective?

For teams providing services to other teams one approach is to require external groups asking for features to provide a written spec before any meeting. A lot of time can be be wasted by having a meeting and discussing something, with nothing written down by the end of the meeting. To me it is crazy to think this is acceptable. People forget things. People move to new positions. There are just so many reasons why verbal communication is not enough to transfer knowledge that has to be retained. Verbal discussion is great to gain better understanding, reach consensus, and make decisions – but not for capturing knowledge for future access.

Writing specs before a meeting ensures something is documented, rather than someone promising to document things after the meeting. It also forces the people making the ask to put sufficient thought into the request before the meeting is called. It can be easy for people to ask for a meeting and talk about half formed ideas. To me the people asking for the feature should be documenting the ask, not the recipient. This is good for the requester to ensure the requirements are correctly captured, buts it’s also a good measure of how important it is to the requester.  (If they don’t write it up, it’s probably not important.)

Another approach that may be suitable in some meetings is good old practices (that are good old practices because they WORK!)

• Require an agenda to be set before agreeing to attend the meeting
• Have someone nominated during the meeting to keep notes – I frequently use a Wiki page because everyone can access it easily
• Have the minutes distributed soon after the meeting – even consider writing them into a Wiki page during the meeting (!). They should be reviewed for accuracy by participants.
• Capture and clearly identify action items, who is going to do them (one primary responsibility), and by when.

Another related challenge is working out what groups of people are working on what. For example, someone asked me on one project who was looking after the rollout strategy. I knew some people were investigating the area, but I could not remember who. Having minutes on the Wiki would have allowed me to do a search and identify people involved. Email is not as good for this – only participants can access the email thread, and it’s easy for email to be lost.

But hey, you may ask – how does the above free up time! All I have talked about involves *more* effort, not less! Writing specs, keeping minutes, etc. This is all additional work! What I have observed so far is that a lot of time gets wasted due to poor communication. Details are not understood or forgotten. There is no way to review again later. I hear of meetings where the same ground is covered again because people forget what was previously agreed to. This is unnecessary waste and where improving practices I think can help with efficiency.

So personally, I recommend teams at least to ask other groups who come along with requests to document their requests in advance. If not, capture minutes of the meeting and save them away say on a Wiki page so everyone can review and follow up on. But I don’t think any group responsible for implementing stuff for other groups should accept receiving requirements only verbally. It’s just too dangerous and can lead to discontent down the track.