Elements Of Communication: Lost In Translation
Imagine five bright people sitting around one table, speaking what seems to be the same language, using common words, which could be found in any dictionary, and correct grammar. And yet no one really understands the others.
No this is not one of those riddles that make your head hurt when you try to solve it. I believe I am not the only one who was “lucky enough” to attend numerous meetings that were just like that.
But wait, it gets even worse. If people sitting in a meeting don’t understand each other, that’s one thing. In most cases, they aren’t even aware of it. And so, the meeting continues, people comment on ideas they only think they understand, and others reject or accept these comments which they think they understand, and…. and then it’s time to call it a day.
The Lack of a Common Language
The reason for this unfortunate phenomenon is the lack of a common language. Not a universal language for all products and all projects. This is not realistic. I’d settle for a common language per project.
People working on a project together need a common vocabulary. This is true for every two people communicating, but it is even more crucial when different people come from different disciplines and professions.
Software is not limited to any closed set of domains. We create software for controlling cars and for word processing, for accounting and for security, for navigating space ships and for playing a virtual game of soccer. Even within the same domain, different products might be built upon different concepts, and use the same terms for different purposes. This makes any professional conversation a challenge.
The challenge is even greater when different people look at the same product from different perspective. The vocabulary of a tester might be completely different than that of an architect.
Take for example the term “Event”. What do you think of when you hear it? Do you think of an entity set by a user for future reference (like an event in a calendar), or do you think of something that happened within the system you create which has to be reported to the user? If you are a UI developer, wouldn’t you just think of an event as a programming language construct used for communication between components? And as an architect you might understand it as an element in UML.
Without defining the exact meaning of the term Event in a certain context, any communication become potentially ineffective.
Creating a Project Vocabulary
So what we should do is to create an agreed language for each project. It should be agreed by all the people involved in the project. All of them! And it should be defined to create the minimum possible confusion (no confusion at all is a realistic goal).
1. Capture Concepts From Requirements, Architecture and Design
First gather all the people which will be involved in the project and try to define together concepts based on the requirements of the product. Capture both nouns and verbs.
Make sure everyone understands these concepts and agree on their meaning and implications (as far as anyone can say at that point).
During the meeting, write the concepts down with their definitions. Everyone should see what you write and accept it. Make them even sign it ;)
Do the same after the initial architecture and design activities.
Congratulations! You now have your official project dictionary v1.0.
2. Avoid Assigning New Meanings To Well-Known Terms
Don’t use terms everyone thinks they know and assign them a new meaning. This is quite a challenge, but it will save you some major headaches.
In the Event example above, the term Event is very confusing because of the already well-known meanings it has in several contexts.
3. Publish The Project Dictionary
Defining the dictionary is a major step in the right direction. Now, make it available to everyone in the project.
Don’t send it via e-mail, and never give people a hard-copy. Use an online publishing method, such as a Wiki. The dictionary should be just a couple of clicks away from your team members.
A platform such as a Wiki is especially great for this purpose. Using a Wiki every team member (as well as other stakeholders) can access the information, add comments and update it. This makes your project dictionary a living document.
4. Expand The Project Dictionary Whenever Someone Looks Surprised
Whenever you are in a status meeting, a brainstorming session, a review meeting or any other kind of project-related gathering you should look for surprised faces. When you see surprise on someone’s face stop the meeting and take a couple of minutes to understand the reason for the reaction.
There could be, of course, many reasons for being surprised during a meeting. But a common reason is some new concept or term which the listener thought he understood until that moment. Alternatively, it could be a concept he had never heard before.
In either case, open up your project dictionary and add the concept. Make sure everyone agree on its meaning.
If by chance the concept is already defined in your project dictionary, search for some new (and surprising) implication which might have caused the surprised reaction. Better to find it now, or it will blow in your face later.
5. Revisit The Project Dictionary Whenever There’s a Major Change in Requirements or Design
Every major change in the requirements or design might introduce new concepts or alter existing ones. This would be a good time to revisit the dictionary and make the necessary additions and changes.
And again: make sure everyone understands the new terms and concepts and agrees on their meaning.
6. Keep The Project Dictionary For Future Development
When the project goes into the maintenance phase, make sure the online project dictionary is still accessible. It should be in reach for anyone who will have to deal with the product in the future.
***
Whenever you start a project make it a habit to maintain a project dictionary. Don’t be misled by the fact that all the people around you are probably speaking the same language. Each of them might have a different view on concepts and terms which are going to be the basis for every discussion and task during the project.
Establishing a common language for the project as early as possible will help you reduce errors, eliminate ineffective discussions and avoid frustration.
June 7th, 2006 at 7:44 am
Excellent article. I have been thinking about this same concept for a few years now. I think I was blocked by trying to come up with a corporate glossary. I like this, smaller scale, approach a lot more.
June 7th, 2006 at 12:22 pm
This sounds like a good idea, but I can’t help but wonder at the cost/benefit. Yeah, miscommunication can bite you hard, but the worst case is so infrequent that I’m not sure you really buy enough with this practice to be worth the time and effort of maintaining an organic/adaptive dictionary. And less-than-worse cases just aren’t that “expensive”.
June 7th, 2006 at 1:28 pm
I’m torn on this. I like the idea very much, but I’m afraid it’s maybe too idealistic to work very well in practice.
1) It has the potential to suck up a lot of time. And even though it’s “up front” time, and for the sake of avoiding wasted time later on, I’m not sure the trade-off is worth it on a lot of small-to-medium sized projects.
2) People are willing to go to disturbing lengths arguing over the silliest things, technical people moreso than most. And the meaning of critical (and non-critical) terms used in the management of a project is far from trivial. The frustrating arguments and dissent normally encountered in the long term may not be avoided, but just moved up.
But tempering those worries are two other considerations…
1) Everyone knows (or should know) that such rules aren’t one-size-fits all. Small projects and small teams have different dynamics than big ones. A small project would be more impacted by the up-front time, but is probably less likely to suffer from serious miscommunication issues, so the extent to which this advice is followed can probably vary from project to project, providing more ROI as project size increases.
2) Even if the frustrating verbal fallout is not avoided by this strategy, at least it can prevent the technical consequences that result from misunderstandings and miscommunication that goes unnoticed or untreated.
As a qualified professional, Mr. Wyssocky surely has experience with this strategy or he wouldn’t be recommending it. What has been your experience implementing this strategy in teams and projects of varying sizes?
June 7th, 2006 at 2:50 pm
This is a response to the two comments above (WaterBreath’s and Jacob’s).
You are both right. Of course this idea does not fit all projects and all teams. If you read my FlexDev article (http://blog.qualityaspect.com/2006/05/10/flexdev/) you would notice I argue that no methodology/practice can possibly fit all projects.
Having said that, I must say that generally, the higher the cost of maintaining such a dictionary is, the greater the benefit is. If you are having a hard time deciding what some terms mean, your team members will probably be confused by these terms. Not making a decision is just putting off the problem until a later phase in development. This is risky.
So, in my opinion, investing the time in defining these concepts is probably cost effective in most cases.
Of course, you should always stay alert, and make sure you are not wasting too much time on isoteric details. It’s your call: you should know when enough is enough.
Lidor
June 8th, 2006 at 6:51 am
I had read the FlexDev article, but didn’t make the connection between then and now that you had written it.
Anway, thanks much for the response.
June 20th, 2006 at 11:51 am
I think it’s a fine idea but I just wonder if people are even aware enough of miscommunication to accept that it’s worth doing. Or to express the suprise you mention in #4 that would motivate editing the project dictionary.
Perhaps a prerequisite practice would be team members’ regularly sharing reflective learning (thoughts prompted by your later reflective journal post.