Words Matter: Why Your Project Team Should Be Aligned on Definitions

Client’s design vendor: “Who is doing the information architecture?”

Me: “We are.”

Client: “You are? I thought you didn’t do CMS development.”

Me: “We don’t. I meant the sitemap and content model framework. What do you mean by information architecture?”

Have you ever had a conversation like this? Yeah, me neither. That was totally made up.

Ahem.

The importance of defining terminology

If you find that project discussions get derailed by stakeholders and vendors/consultants misunderstanding each other or laboring over semantics, take a step back and clarify terms.

Here are just two ways aligning on lexicon can mitigate risks and make your project less painful:

You’ll have clarity about the work that needs to get done, what it helps you accomplish, and who will do it.

A few years ago, my client hired a user experience agency to redesign their website. The client asked for a content strategy as part of that engagement. The client’s understanding of content strategy was the content strategy quad. The user experience agency didn’t have the same understanding.

So, instead of true UX content strategy, they delivered a tactical editorial framework specifying how many blog posts, white papers, and other content formats to deliver at what frequencies. (We’d call this an editorial plan.) As a result, the client was without a guiding compass to help them decide what content goes on the site and why—which was the “content strategy” they thought they’d requested. Had the UX partner and the client been in early agreement about what content strategy was, this problem could have been avoided.

You’ll have stakeholder alignment on the importance of key concepts, artifacts, and outcomes of your project.

This one is important, and easy to miss—especially if you never get everyone in the room at the same time. 

In a recent project, after we were done with individual stakeholder interviews, we held a group strategic alignment session. It quickly became clear that we’d missed something important in our early interviews: The business folks, the technology folks, and the content folks were all using different words to describe what we thought of as the “author experience.” Some were saying front end, some were saying back end, some were saying content management system. And, because of that, they all had misaligned definitions for what the terms they didn’t use were.

Had we not stopped and taken time to define the terms that kept derailing our conversations, it’s very likely we would have delivered something that did not meet the needs of at least one of those stakeholder groups. Similarly, they would have continued to have circular discussions—as they had been for quite some time—because no one picked up on the fact that they weren’t talking about the same thing. Eeks.

Define early and often

It’s important to ensure alignment on terminology at project initiation and at key milestones along the way. Here are some tips to get it done:

• Get consensus right away. Your statement of work (consultant side) or project brief (internal) is a primary opportunity to start defining your shared vocabulary. Keep in mind that while the people involved in those initial discussions may arrive at shared definitions, others who will be involved may not think the terms mean the same things. So start every stakeholder interview with a short description of the purpose of the project as you understand it, and a description of what artifacts or deliverables will be provided along the way.
• Speak up. In stakeholder interviews, avoid letting what you think might be a varied use of a term slip by. Stop and ask what the stakeholder means when they say <insert term>. And keep a list of terminology you believe is being used differently by different people.
• Get the group involved. If you have the opportunity to do a workshop or working session with a group of stakeholders representing different areas of the business, start out with some definitions you know to be problematic and define them as a group. Keep adding to that list and stopping to discuss as you go.
• Keep a record. Document your definitions to remind the team where you landed. Here’s an example of some definitions documentation from a rolling project status document:

Whether the definitions for terminology you align on represent exactly how you define the terms doesn’t really matter. What’s important is that everyone is using the same terms the same ways.