What’s in a Project Name?

Editor’s Note: Rachael Warner helps organisations around the world improve their communications and writing through tailored coaching and training programmes. She recently wrote a LinkedIn post on naming transformation/change programs that garnered a lot of attention, and I asked her to write a guest post for Strictly Internal on the topic. Here’s what she said…

We love naming things in change, don’t we? Every change project gets a name. And then any service or tool in that project often gets a name, too. Then sometimes the name’s a bit long-winded, so it gets an acronym. There’s sometimes a logo. (Don’t get me started on logos.)

It all helps make the work feel real – it gives us something tangible when so much of the change is still taking shape.

But all these names have been bothering me, so a few months ago, I wrote a LinkedIn post about how I think project names can quietly undermine change comms. It struck a chord – but it also sparked a fair bit of pushback.

People told me that naming and branding a project helps employees connect with it. That it gives the change an identity and something people can rally around. And they’re totally right.

So when Kevin asked me to write an article about this very topic, it felt like the perfect opportunity to reflect on what I was trying to say.

Because I wasn’t really arguing against names or branding. What I was trying to get at – and what I see more clearly now – is that naming only works when it helps employees make sense of what’s changing.

To be clear, I’m not talking about what you call the project in the change team. That’s fine. The problem I see is when these internal names end up in employee comms when they weren’t created with employees in mind. (I’ve made that bold because it’s an important distinction.)

Done well, a name or brand can absolutely be useful. It can make something tangible, give it energy and make it easier to talk about. But when the name wasn’t created for employees and we still use it with them anyway, it can pull focus away from what’s actually changing for them. The story becomes about the project itself, instead of what people need to know or do as a result of it.

And that’s when it stops helping.

This isn’t just about project names

We name tools, frameworks, systems, ways of working, and whole strategies. We give them initials and turn them into acronyms. We talk about them as if they’re household names. Inside the project, it all makes perfect sense. Outside, it often makes none.

It’s how we end up with lines like “The Horizon Programme is moving into Phase Two” or “We’re rolling out the new WPS Tool”.

I know the pushback: “If you communicate it well, people will understand.”

But that’s exactly my point. Why make them do that extra work? Why ask employees to learn another label, then learn what sits behind the label, then only then understand what’s changing? It’s another step their brains have to take.

Why focus on the tool name when you could focus on what they’re actually going to get out of it? When you could just tell them straight what’s changing and how it helps them?

Because to the people who built it, the name is meaningful. But to everyone else, it’s just another layer to get through before they get to the bit they actually care about. You guessed it… What’s in it for me? (WIIFM)

What goes wrong when project names go public

✅ They can confuse more than they clarify. Employees don’t have time to decode what “Project Elevate” means for them. If they can’t see the relevance, they’ll tune out.

✅ They can shift focus away from what matters. Employees don’t care what a project or tool is called. They care about what it helps them do – whether it makes their job easier, faster or less painful.

✅ They can create distance. Names and acronyms can make something sound official but also alien. They can reinforce the sense that this is a “project” happening to people, not for them.

Take tool names. I once saw comms about a new system that let employees get back into their account if they forgot their password – no need to log a ticket with the IT Help Desk. A genuinely helpful change. But the messages focused on the tool itself (and its acronym), what it stood for and how it worked.

For me, the story shouldn’t have been “We’re launching the new ARS* tool” – it should’ve been “You can now get back into your account yourself, no need to contact IT.” That’s what people care about.

(* That wasn’t the name of the tool, I’m just being childish.)

The bigger point

The issue isn’t naming or branding – it’s forgetting who it’s for and expecting it to do the heavy lifting.

Instead, ask:

• What do people actually need to know?

• What do they need to do?

• How will it help or affect them?

Then tell them that, in clear, human language. 

TLDR: When you step into employee comms, the job isn’t to promote a project identity, it’s to make change understandable and doable. 

The name should never be the story. The story is what it means for the people who have to live with it. 👊

I run bespoke in-house comms and writing programmes to help organisations talk and write about change – shaped around your context, your people and your projects.

More of a solo learner? Join the waiting list for my new self-study change writing course.

Otherwise, come and say hi on LinkedIn or subscribe to my Comms Nerd email for practical comms, writing and storytelling tips.

Thanks for having me again, Kevin!

Rachael previously wrote for Strictly Internal on how to boost your change comms — you can view that article below.