by Margaret Gerasimenko
For any project or business, clear communications are one of the most important aspects in ensuring efficient and effective operations and delivery. But when communications are taking place between different groups – whether within a single company or between companies – there is the potential for miscommunication in terms, language, and meaning. Given this, how can we ensure that everything is clear and misunderstandings don’t happen?
Let’s take a simplified example using an internal IT project within one company – developing and deploying a new work tool. There are four main groups involved:
Each has different requirements when it comes to learning about the project.
The IT developers need to have a clear set of requirements about what is sought for custom software development, backlog of functionality in the form of use cases or user stories, and the timeframes involved.
The user group will want to know how the tool will change their daily work at a practical level – how will it make things simpler, easier, faster, or better, and what will they need to change to work with it?
Sales and marketing need something else, however; what does this tool bring to the company that gives it an edge over the competition? How can this tool be used in a marketing campaign to promote its impact?
For the C-level executives, however, knowing that developing a new tool will enable (e.g.) better sales recording and easier customer servicing due to a new linkage between previously separate accounts is of limited interest. For the C-level, the language needed concerns impact overall – how much more effective or efficient will this make the user group? How many more customers can be serviced in the same amount of time? What is that likely to do to the customer retention rate? And ultimately, what is the Return on Investment and impact on profitability?
Each group has its own frame of reference with regard to the project and its own area of interest. For an IT project, often highly technical, there is therefore immediately a clear challenge in ensuring that effective communication takes place across the entire project chain.
For example, to deliver effective services software developers need to be provided with an understanding of the use to which the tool will be put and what the user actually wants: there are far too many examples of IT tools that have been developed but that users utterly detest, often due to factors that developers consider to be minor or insignificant but that users find of out-sized importance.
This is all before the problems of specific language come into play. IT and project management are hardly alone in having their own languages and abbreviations that can seem impenetrable to the outsider.
On the other side of the coin though, users may often have a hard time putting into meaningful requirements what they actually want – “something that does something like…” can be an all too familiar starting place. And even organisations with extensive experience in cutting edge projects have the occasional communication failure between different groups (NASA’s Mars Climate Orbiter that used both metric and Imperial units is a fairly infamous example).
Everyone stands out for mutual understanding, but, in practice, not everyone can keep the way. ‘Information technologies’ is a difficult field where programmers speak their own language. And, even cording in several programming languages, they have one for conversations and for their closed introverting characters. Sometimes, it becomes a matter of principle to be a translator between a programmer and a non-tech savvy customer.
The task status in task tracking, when the task is postponed indefinitely.
It comes from ‘proper recognition’ or ‘proper respect’. Geeks often say that, praising somebody for something.
It origins from Greek ‘kydos' that means ‘recognition’ and ‘respect’ as well. The only difference is geeks say this as an introduction.
The phrase means there is no money anymore, and the budget has become empty.
The saying is rather popular in the UK and highlights the done status of the task.
This is an IT term meaning remain tasks necessary to be completed in team work.
Means ‘What the f***?’ and used in cases of emotional expression when the speaking person feel confused.
Means ‘Cry babies’. Programmers call the customers who are always annoying with complaints.
Futile attempt to make sure your management that their actions are full of absurdity.
Just a "Get Out Of Debt" job.
An IT person who follows the frames of strict compliance, corporate procedures and policies, doing not actual work. Enjoys using a hamster wheel.
Activity and meetings of IT hamsters.
A hired person who doesn't require learning. A new guy who is ‘plug-and-play’ in the team.
As a rule, though, good communication practices can ensure that miscommunication is avoided and that the requirements of all separate parties to a project are met.
Having identified lead contacts is vital. Actively examining the communications requirements of each user group and tailoring messages or communications where needed can help avoid misunderstanding and increase buy-in. Periodic, regular reviews of the project progress rather than long silences may seem obvious – but once meeting scheduling starts, it is still amazing how many people try to get out of them.
This is the main issue: ensuring effective communication, which is essential to enabling requirements to be met and problems avoided, takes effort and takes time. Holding the third user group workshop can seem to be yet another imposition on a busy calendar – but when it avoids days of wasted programming and expense, it’s really highly cost-effective.
Writing systems | Language and languages | Language learning | Pronunciation | Learning vocabulary | Language acquisition | Motivation and reasons to learn languages | Arabic | Basque | Celtic languages | Chinese | English | Esperanto | French | German | Greek | Hebrew | Indonesian | Italian | Japanese | Korean | Latin | Portuguese | Russian | Sign Languages | Spanish | Swedish | Other languages | Minority and endangered languages | Constructed languages (conlangs) | Reviews of language courses and books | Language learning apps | Teaching languages | Languages and careers | Being and becoming bilingual | Language and culture | Language development and disorders | Translation and interpreting | Multilingual websites, databases and coding | History | Travel | Food | Other topics | Spoof articles | How to submit an article
[top]
You can support this site by Buying Me A Coffee, and if you like what you see on this page, you can use the buttons below to share it with people you know.
If you like this site and find it useful, you can support it by making a donation via PayPal or Patreon, or by contributing in other ways. Omniglot is how I make my living.
Note: all links on this site to Amazon.com
[top]
