DataLeaf ICT - Leaf IT to us!
Homepage
DataLeaf ICT
Diensten
Producten
Techniek
Vacatures & Detachering
Artikelen
Contact




projectadministratie.jpg






PDF Afdrukken E-mail
Geschreven door T0t4lch40s   
Friday 16 July 2010


Failures in communication

Author: T0t4lch40s

 

“Write a blog, you must” is what the assignment read. OK, so maybe it didn't come from Yoda himself but I still feel compelled to do so. Your manager could be considered your Yoda, right?

For a long time now I've been telling myself to write blogs about things that are on my mind. I was just assuming I'd get to write a private blog first, with a whole lot of nonsense in it, and have some of my closest friends read it first. And of course, laugh out loud. Faith decided otherwise.
I shall now attempt to write an informative, professional, accurate, easy to read blog, without any practice whatsoever, so bare with me.
 
If any of you have ever visited the website failblog.org, you probably know where the title of this blog stems from. If not, shame on you :D.
At failblog the comments on posts are called “Failures in Communication”.
It though this was a very appropriate title for my blog, because that is exactly what it is about.

I will now start by giving some examples of situations in which communication clearly failed. After that I will of course give some guidelines on how to improve this.

Examples
I am pretty sure everybody has had and/or seen some failures in communication.
Here are a few of the ones I encountered.

Example 1: employees do not know what other related company's and/or their employees are supposed to be doing.
My sister and I went to the City Hall of some city. We needed to find out something about a building. Us – being quite unfamiliar with this sort of thing – were assuming that the people at City Hall would know where to go.

The receptionist sent us to a counter in City Hall, they would know what to do! The woman there informed us we couldn't get the information there and after asking a colleague she told us we needed to ask the “chamber of commerce”.

We called the “chamber of commerce” (Kamer van Koophandel) and they told us we needed the department of “land registry” (Het kadaster). They would know that to do !
We called that department and they said we could apply for this information by letter. If we needed the information sooner we could also go to the “land registry” counter in City Hall ! They would know that to do ! (haven't heard that before...)

Ow my … , we just came from there. Thankfully we didn't leave and could just go back inside and get to the right counter. Finally we got our information.

We had to call several companies to find out we had to go back to the first one and tell THEM we should be able to get that information there.
Apparently nobody knew what to do...

Moral of this story: If those companies knew what they (and others) were doing, we wouldn't have wasted so much time there.

Example 2: inter-department communication
At a company someone I know works at, there are several IT departments.
Turns out an employee of one of the departments (A) has outsourced the building of a website to an external company. The other department (B) manages all the sites in a CMS (Content Management System). So about a week before the site is supposed to go live, department B gets a call from the external company that the site is finished and is ready to be placed in the CMS. They are all very confused, because they've never even heard of this site. And furthermore, the site doesn't meet the requirements that are stated for all the sites in the CMS.
The external company had to be paid more to change the website, and department B all of a sudden had some extra work they didn't plan for.

Moral of this story: If department A would have let department B know about the website in time, there wouldn't have been a problem

Apparently things like that happen a lot there and now they decided to merge the departments. That's their way of fixing this. But if there's still no communication, it won't change anything.

Example 3: meetings without notes
Very often we have meetings between managers and programmers, about what and how to make the functionality requested by customers.
Ever so often we don't make notes.
Next thing I know we're having the same conversations and discussions again because we don't remember what we decided on.
And I'm being used as a oracle of sorts, because I'm the only one who remembers the conversations.

Moral of this story: If we had made notes, we wouldn't be “reinventing the wheel”, sort of speak. I could make money with this oracle business !

Example 4: We speak a different language
A manager was discussing some functionality with a programmer. The programmer was talking about client instances (as in a different website for each client), the manager replied to that, thinking that instances were divisions inside a website of a client. Of course they didn't agree on the subject, because they were talking about different things.

When hearing a conversation between managers and programmers, I often notice that they speak a different language. They use the same terms, but have a different meaning for it.

Moral of this story: Discussions can take long or have a wrong outcome when you think the other person is talking about the same thing, when in fact he isn't.

I don't think I need to give any more examples, because surely you yourself can think of a few situations in which communication has gone bad.

Guidelines

It is of course very easy to have a situation gone bad and afterwards examine them and see what should have gone different. The only problem is that you want to prevent these things from happening.
So I wrote down some guidelines which I hope will help improve communication.

Communication between companies and/or departments (because sometimes it's almost the same thing)
How could the situations in examples 1 and 2 be partly prevented.

Protocol:
In case of actions that involve other departments make sure you have a protocol that has to be followed. In case of the website (example 2): If department A had followed a protocol this would probably have stated that they should inform department B that a new website is developed. Department B could then immediately have told them there are guidelines.
A protocol can be some work, but it helps to have a guideline on what to do when.
If you don't have a protocol, everybody is going to do things the way they please which might be different for everyone.

Hold a person responsible
If you want to make sure something gets done the right way, make one or two people responsible for it. They are the ones that have to make sure it gets done right. Make sure they know that they will be held accountable if things go wrong.

If nobody is responsible, nobody will take responsibility.
If somebody is responsible, you have a contact point. You could have them keep you up to date about the status of the actions and overview these actions performed by other employees.
Of course, if you do make someone responsible, you will have to inform the other employees who's responsible, otherwise it won't have any effect. Maybe the next tip will help with that.

Create an operation overview
If you have a large company, it might help to have an overview of the actions and responsibilities each department and/or other companies/departments have.
In smaller companies, you might want to do this for each employee.
Also, while creating this, have the departments/employees write down what they think their actions/responsibilities are. Also have them write down what they think other companies/departments/employees do.

This might create insight in what companies/departments/employees need more explanation.

Communication inside departments
So how about communication inside departments, can we improve that? I think so.

Notes (dictionary calls it minutes, but that's just too weird a word for me)
Of course the easiest way to improve not remembering what a meeting was about or what was decided, would be to make notes.

But in order to make these notes have any effect at all, you have to do more.
First assign one secretary, make sure they make a document in which they extensively describe the key-points and decisions of the meeting.

During the meeting make sure the secretary understands what has been discussed and has had time to write it down.
If you have a meeting with a lot of participants, it would be best to have the secretary not be part of the conversation. This way they can keep writing while the others are talking, so you'll minimize the risk of having to wait for the secretary often during the meeting. Another thing you can do is record the meeting, in which case the secretary doesn't have to write too much down.

Also, at the end of the meeting, agree on the location the document will be placed at. Make this an easy to find location, and give the document an easy name. Using the name of the meeting and the date and time of the meeting would be best.

Why go through all this trouble?
One person needs to be responsible for the notes (see previous chapters) and this persons needs to understand what has been discussed in order to be able to write a  document that makes any sense whatsoever.
If you only write keywords nobody will remember what the conversation was about if they read it after a week. Better write too much than too less.
As for the location and naming: notes that can't be found, won't be read.

Also, if you like, you can have the secretary make a list of all the actions that were discussed. For instance “Hank will e-mail Sandra to inform her of the impact”.
They can be e-mailed to every member of the meeting, or be managed in a task list. Actions can be easily forgotten and people usually don't want to read the entire document to find what actions they need to perform.

Even if you just have a 10 minute conversation in which you discuss even just a tiny thing that is important or relevant I'd advise to make notes of it.

Define terms
The easiest way to make sure you are all talking about the same thing is to make a list of terms. In conversations use these terms, and in case of doubt you can ask  which term they are referring to.
This will help solve and prevent a lot of misunderstandings.

Speak their language
When explaining something to a co-worker, manager or client, try to phrase your sentences in their words. This helps in understanding their point of view.
Often people in different work environments (co-worker vs. manager) have a very different view on things.
Trying to place yourself in their view will make communication easier.

Do not assume anything
While in conversation, do not assume too much.
Do not assume that when you use a term which is very common, the other person will know exactly what you mean. Unless of course you have a term definition and are using those.
Do not assume that when you say things like “easy” and “simple” that means the same to the other person as it does to you.
Do not assume they know the context of your question. In which situation a certain action should be enabled or disabled for instance.
It's better to be specific and sometimes make a full sentence with context instead of half a sentence without context.

Give an intro
When you're working on something and run into something that you have a question about, it is best to not start you conversation directly with the question.
The case usually is that your co-worker is also working on something (completely different), and has no idea what you are talking about.
So start with a short intro on what you're working on and then proceed to your question. I assure you this will help get an answer a lot quicker.

Codeword
This is a solution me and my co-worker thought of, in case we forget to “give an intro”. If we have absolutely no idea what the other person is talking about, we say “context”.
This means the other person should first tell us where he's at with his head.

Conclusion

There are still a lot of failures of communication out there, but hopefully with these guidelines we can fight them !
I hope you found this as informative as I found it boring to write (just kiddin').

PS. As English is not my native language, I sincerely apologize if any of the words in this document have not been translated correctly. I compared the amount of search results in Google, and as we all know “Google knows best”. Maybe your dictionary is just old fashioned.

 

 
Volgende >

Failures in communication

Lees meer...
 

Nieuw in SQL Server Reporting Services 2008 R2

Lees meer...
 
Linq2SQL performance: Associations vs Datacontext queries
Lees meer...
 
Increasing security by implementing a WCF based service router
Lees meer...
 
Prince2 ondersteuning in softwaretools (2)
Lees meer...
 
Links