Tag Archives: Communication

Larry McEnerney: The Craft of Writing Effectively

Communication, Video,

Mr McEnerney presents a really good “strategic” approach to writing in a professional context. On the one hand nothing really new, but the way it is presented and details being put into context, make this a wonderful framework for me.

In particular it became even clearer to me why knowing a lot about a subject often makes it more difficult to write about it or discuss things with non-subject-matter-experts. This is also described nicely in the course description for professionals.

And finally I want to direct your attention to this nice blog post about a personal encounter with Larry McEnerney.

The Danger of BCC

Management, ,

The title is a bit dramatic, admittedly, but there are some pitfalls associated with using the BCC feature of email programs. More specifically the combination of BCC and the “Reply to All” functionality can put you in a pretty bad position. And the reason is quite simple:

You put people on the BCC list because you want them to know about the email, but the regular recipients should not be aware of that fact. So far so good. The problem is that most email users don’t pay much attention how they got the email. They don’t check whether they were put on TO (regular recipient, action required from them) or CC (just for information, nothing to be done).

As a consequence, if you send stuff around with folks on BCC, they also do not realize that they are neither on TO nor CC. Instead they may think “I can contribute something here” and press the “Reply to All” button. Obviously the regular recipients will wonder how someone, who did not get the email (from their perspective that is), can say something about it. And a split second later all but the novice email users realize that you had put an unknown number of other people on BCC.

So you will have a trust issue here! Luckily this situation can easily be avoided and here is my advice how to do it: Never use BCC. Instead just forward the email to all those people that you would have put on BCC. Now, there might be folks around who argue that this is too cumbersome. And indeed, if you send 100+ mails per day, it may be disruptive to always change into the “Sent Items” folder and back.

However, if you have read my post about the [cref 63 “Getting Things Done”] approach, you may remember that I recommend to have a rule in the email program that puts you on CC for all outgoing email. So just wait a few seconds until this copy arrives in your inbox and forward it then.

Meeting Minutes

Management, ,

Meeting minutes sometimes seem to have become a “lost art”. I mean, they are not rocket science, rather a bit dumb. Let me therefore share with you the in my opinion essential points.

  • If you want to follow only one advice, here it is: Write in a way that allows someone who has not attended the meeting to understand the minutes. This especially means that you must very carefully set the context for each topic. You get two things from that additional effort. Firstly, someone who has not attended the meeting will understand your minutes (surprise, surprise). Secondly, and perhaps more importantly, YOU will be able to understand your minutes in a few weeks. Chances are that you would not do so without setting context etc.
  • There is no such thing as a meeting without minutes. Depending on the type of the meeting you can decide to just write a short email that sums things up. But something should be written! This is the only way to ensure that people have a common understanding what has been discussed and decided.
  • Use a template, and please let it be the same template every time. It does not need to be extremely sophisticated but should support ease of reading. That means the reader should be supported in absorbing the content.
  • Each entry is clearly marked as a certain type. Usually you find: decision, information, action item. Add others as you need them (sometimes “status” is a different category).
  • Please only one (1) owner per action item. This person is responsible that the job gets done. This does NOT mean this person always has to do it in person (this is only one of several possibilities). He or she can also delegate it, do it together with someone else, etc. But he or she is responsible towards the meeting that the work is finished by the assigned due date.
  • Each action item also has a due date. There must never-ever be an action item without a due date. Period. This due date does NOT get adjusted when it is missed. Otherwise the pressure to work hard will be lowered (you don’t want that, do you?).
  • You should document who attended the meeting and who got informed about the outcome. So please put a list of attendees (also partial attendance, to be documented as such, counts) and a list of recipients into your document.

So nothing complicated here, right? One last word in terms of effort. Writing good meeting minutes takes time. Unless you are extremely fast, you can expect that the writing will sometimes take as long as the actual meeting. But this is normally time well spent. Especially if you are working for a client on a consulting project, you should be careful to document what was said.

So what should you do with those meeting minutes once you have finished writing them? Here is my take on it:

  • Send them to the participants and ask them to check carefully
  • Depending on when the next meeting occurs, people must either provide their feedback within a certain timeframe (I suggest 2-3 working days) or at the next meeting.
  • If nothing has been brought forward within the agreed timeframe, the minutes are considered to be signed off. This is critical for projects with external customers, but also good practice internally.

You can probably refine most of my points and also add quite a few more. However, these are the basics and if you follow them, you are most likely well above the average standard.

Gause/Weinberg: “Exploring Requirements. Quality Before Design”

Review, , , ,

[amtap amazon:asin=0932633137]

We probably all know that gathering requirements is not as easy as it may sound. And it’s also pretty clear that the issue is not primarily around technical things but communication and people. I can recommended this book (link to amazon.com and amazon.de) to everyone who is interested in or works in that area.

I came across the book during a project where requirements gathering was a very important aspect. I had certainly done this before on numerous occasions. However, this book greatly increased my insight into the underlying mechanisms, patterns etc.