Give the child a name

Before Plantronic became a substantial production-planning system, it needed a name that described the system rather than the organization around it.

The earliest visible milestone in 2025 is almost comically small: references in the project wiki changed from an earlier working name to Plantronic. No scheduler became faster. No factory data was imported. No user got a new screen. Yet the rename marked an important transition.

The name was chosen by the client’s project manager, not invented by the software team as a branding exercise. It survived all the way into production and rallied dozens of early adopters behind one recognizable initiative.

A client project often begins as “the tool for this team” or “the new version of that spreadsheet.” Those names are convenient while a problem is still local. They become restrictive once the software coordinates planning across teams and source systems.

A proper name creates a boundary. Plantronic was not the factory, the source system, or a single planning view. It was the application responsible for turning several kinds of operational information into an inspectable planning process.

A working title is already teaching the organization

Introducing software into an organization starts long before production. The name appears in meetings, invitations, tickets, demonstrations, documentation, support requests, and conversations between future users. Every repetition teaches people what the thing is and where it belongs.

That is why I hate working titles that do not make it to production. A working title does not remain an innocent placeholder once people begin using it. It builds a shared mental model. Changing it later means more than renaming modules and links: the organization must unlearn one identity while learning another. For a while, both names coexist, and every conversation must spend time establishing whether everyone is still talking about the same thing.

There are exceptions. A small discovery group may need a disposable label, and confidential work may require a code name. But once a project is introduced to the people expected to adopt, operate, or explain it, the name should be treated as durable.

Plantronic demonstrated the benefit. When someone used the name, there was never doubt about where the project was heading or who should communicate with whom about what. The name gave everyone a stable point of reference while the software itself was still taking shape. It helped materialize an idea into an organizational reality.

Names become architecture

A name alone cannot rescue a muddled design. It can, however, make muddle easier to see.

Once the application had its own identity, questions became sharper:

Which concepts belong inside Plantronic?
Which facts remain owned by external systems?
Which changes are planning decisions rather than imported truth?
Which reports explain Plantronic’s state, and which merely repeat source data?

Those questions appeared repeatedly during implementation. Task routing, team workloads, process transitions, SAP-facing imports, public views, and reporting all needed boundaries. The project name became shorthand for one side of those boundaries.

This matters especially in consulting work. A code name borrowed from a customer or an existing system quietly encourages accidental coupling. Developers reproduce vocabulary and assumptions without deciding whether they belong in the new product. A distinct name gives the team permission to model the problem deliberately.

Rename while it is still cheap

Renaming later is expensive. The old term spreads into repositories, modules, database identifiers, deployment scripts, documentation, and conversation. Even when a technical rename is possible, the mental model lingers. The social migration is usually larger than the code diff.

January 2025 was early enough. The wiki change preceded most implementation milestones and happened before broad adoption hardened the earlier label. From the first adopters through production, Plantronic remained Plantronic.

Looking back after the project was completed, I like that its history begins this way. Long projects are remembered through large releases and difficult migrations, but their direction is often set by smaller acts of clarification. Giving the child a name was one of them.