For example, people can leave a meeting thinking they're on the same page when they're not. Work gets done with the wrong assumptions, and then it needs to get redone when the misunderstanding is discovered.

In this article, I'll go over five tactics you can use to prevent the kinds of miscommunication that can derail a project.

Tactic 1: Define terms

The same words can mean different things to different people. That’s why it’s so helpful to define key terms when discussing a project. Otherwise, it’s easy for everyone to walk out of a meeting with completely different ideas about the next steps. This can send a project in the wrong direction.

One memorable example happened in a meeting where I was discussing a software component with teammates and other stakeholders. We were all using the term ‘docked’ to describe the placement of the component, but we hadn’t been specific about what that meant because we each assumed our definition was everyone else’s definition.

Later on, when I was about to implement the feature, I decided to double-confirm the specifics just to be safe. I privately asked everyone what the word ‘docked’ meant to them. Everyone had a different answer.

One person defined ‘docked’ as ‘touching the bottom of the screen’. Another defined it as ‘touching any side of the screen’. Yet another defined it as ‘near the bottom of the screen but not necessarily touching it’. At that point, I realized we needed to reconvene and define what we were actually talking about. This extra clarification saved the project from going in the wrong direction.

After this incident, I made it a point to define key terms as soon as possible instead of waiting. This has led to more productive discussions.

Tactic 2: Walk through concrete examples

When discussing project requirements, it’s helpful to walk through concrete examples, using visuals or other types of demos where possible. This might sound obvious at first, but I’ve seen too many discussions that went nowhere because everyone was speaking in generalities.

For instance, I remember a user interface project where the requirements seemed clear, the designs looked great, and we were ready to move forward with development. As I thought more about the requirements, I realized there were a couple of issues that would make the project impossible to complete as described. I tried to communicate my concerns, only to be met with answers such as, ‘That should be fine,’ and ‘Can’t we just XYZ?’

I was getting nowhere with generalities, so I sat down with the project’s lead designer to look at the mockups and walk through some concrete examples of how the user experience would behave. From this discussion, it became clear that the user interface’s options would contradict one another in many scenarios. By the end of the discussion, we had come up with a set of requirements that would actually work.

From that day on, every time I saw a discussion get bogged down in generalities, I made it a point to walk through concrete examples wherever possible. This approach has made it much easier to get everyone aligned around a shared understanding.

Tactic 3: Write things down

With all the discussions that happen during a project, it’s easy for information to get lost. That’s why I’ve found it helpful to keep a written record of decisions, questions, and other information.

Without a written record of key info, here are some things that can go wrong:

• People who need information don’t receive it;
• There’s nowhere to reference decisions;
• It becomes easier to miss the misunderstandings that would have been exposed if the results of a discussion were recorded;
• A stakeholder can request something, forget requesting it, and then ask why that request was carried out;
• It’s harder to get outside feedback on ideas – this is especially problematic when a person with useful context wasn’t in a meeting where a relevant topic was discussed;
• Project scope can expand to an unmanageable size because of unrecorded requests.

As for how to keep a record of key information, it could be a shared document, a ticketing system, a spreadsheet, an app, or whatever your team is most comfortable with. What’s important is that everyone is aligned around whatever methods are chosen. Otherwise, people won’t participate and decisions won’t be recorded.

Recording information isn’t the end of the story here because there are still problems. Sometimes, information ends up in scattered documents that no one can find. Sometimes, documents become outdated and this can lead to misunderstandings.

While I don’t have a perfect solution for the problems of scattered or outdated documents, one thing that helps is to reduce the number of agreed-upon places to store information. For example, maybe each project can have one shared folder containing all relevant docs, or maybe there’s a grouping of project tickets that everyone refers to. The important thing is that the team is aligned on a method that isn’t too cumbersome to implement.

Tactic 4: Allow time to think

Good decisions happen when people have time to think. By ‘time to think’ I mean two things: an agenda ahead of meetings so people have time to prepare, and space to follow up after a meeting since it’s common to think of something after a discussion ends.

By allowing time before and after the meeting, you can avoid the twin problems of ‘I wasn’t prepared for the meeting,’ and ‘I thought of an important idea after it was too late, and now I don’t know how to bring it up.’

If you don’t give people enough time to think before and after discussions, you create the perfect conditions to produce the least thought-through decisions.

Tactic 5: Confirm decisions

Make time to revisit and confirm decisions after the initial discussions. I’ve lost count of the number of times I’ve been saved by double-checking.

Here are some benefits of confirming your understanding:

• You can reveal a misunderstanding or miscommunication;
• You can discover a change that hadn’t yet been communicated to you;
• You can communicate a change you may have forgotten to share before;
• You can change the initial decision with new information you’ve gotten from examining a project more closely.

When in doubt, confirm. When not in doubt, confirm anyway. It’s better to confirm now than to be surprised later.

Conclusion

To recap, you can avoid plenty of miscommunications by defining key terms, walking through examples, writing things down, allowing time to think, and confirming decisions.

It can be hard to remember all of that, so the common thread is this: clarify everything. Make sure everyone has a clear and consistent understanding of the goals and key ideas so that your projects won’t get derailed.

If clarifying everything seems tedious, remember this: one hour of clarifying a project now is better than one month of fixing it later.