Today I’m going to share with you a simple tool that can drastically increase the clarity of communication with your customers, stakeholders and within the project team. A Shared Common Language. Furthermore, you can implement this tool immediately within your project today.
A common problem on many projects
A problem that I’ve seen occur on numerous projects is a basic lack of agreement on common terms used throughout the project. I’ve lost count of the number of times I’ve seen people on projects using the same word to describe different things, arguing about the meaning of a concept, or simply using a term incorrectly. Maybe you’ve also come across this during your career?
It could be that I’ve been incredibly unlucky in the projects I’ve worked on over the years, or it could be that this is actually a common problem. In either case, it ‘s a theme I’ve seen repeatedly across projects, and one that causes no end of confusion, delay and wastage. Three things that we should all aim to eliminate in our projects.
A Shared Common Language
The simple solution is to implement a Shared Common Language for your project, team or whole organisation.
A Shared Common Language is a shared glossary, or dictionary, of common terms and concepts used throughout the project or across the organisation. (Thoughtworks uses a similar concept that they call Business Terms).
That’s it. Nice and simple, right?
You can put together you Shared Common Language in a table with two columns; Term and Meaning. And then use one row per term.
Here’s a quick example:
| Term | Meaning |
| Accelerometer | A device that senses changes in speed along its axis. |
| Backscattering | Reflecting light back in the direction of the source. |
| Coma | The cloud of diffuse material surrounding the nucleus of a comet. |
| Drogue | A small parachute used to slow and stabilize a spacecraft returning to the atmosphere, usually preceding deployment of a main landing parachute. |
(These terms are taken from The Rocket and Space Technology Glossary – Yes, for once it is Rocket Science)
Scope
The Shared Common Language can cover three main areas:
| Business Terms | Terms used within the business domain. | e.g. Underwritten |
| Technical Terms | IT-specific or other technical terms | e.g. API |
| Project Terms | Terms used within the project process. | e.g. Phase |
Please don’t underestimate the value of defining even the most obvious terms. I’ve encountered horrible misuse of basic terms such as Sprint, User Acceptance Testing, Service Bus etc.
Finding meaning
It’s important to get a consensus on the meanings of each terms, and while you may never get 100% agreement, it’s important to get the team to agree to use a particular meaning for the duration of the project.
In regards to which meaning to use, I like to use the following hierarchy to determine which meaning to use.
- Organisation- the terms the existing client organisation use.
- Industry - industry standard terms.
- Team-defined terms – terms defined by the project team
If the client organisation already has a meaning, then use that meaning. Otherwise use the industry standard meaning. Lastly, if no industry standard exists, then agree on a meaning within the team.
Tip: Part of getting teams to agree on one meaning often includes getting people to acknowledge that they agree on how to use that term within the team or organisation, even though they personally may use the term differently outside of the team or organisation.
Note that nowhere in the list is terms most favored by the Project Manager/Scrum Master/Project Lead etc. Unfortunately I’ve seen a number of occurrences where the leader of the group insists on using their terms. My advice, if you are that leader, is to put your ego aside, stay humble, and use the meanings defined from the hierarchy above.
Using the Shared Common Language
Your Shared Common Language should be documented and distributed to project team members, stakeholders etc. You can use any tool you like Word document, wiki etc. It can also be included with any project documentation, where applicable, to enhance understanding. It’s also great to give to new starters who join a team or project at a later date.
Here’s to better communication and better projects.
