Sometimes it’s hard to make the real name of an application stick.

In our organization, development projects are given a certain name, and the resulting application at times is supposed to have a different name. This probably wouldn’t be a problem except that, due to Agile methodology, we are in frequent contact with the stakeholders. Therefore, they hear the development team refer to the project by the name that the development lifecycle has been given. There are times when the final software’s name hasn’t been agreed upon yet, so all there is to call it is the same name as the dev project.

However, because so many people talk about the project using that name, it becomes difficult to then change mindsets and call it by the application’s real title later on.

I see this as one of the challenges for the documentation. I’ve got to pick the right name—but which name is the right one? The official name, or the one that most people are using?

I’ve decided to use the real name. If managers and stakeholders are going to go to the trouble of choosing an official name for the software, than that’s what I’m going to use in the documentation. And if that’s what the users see while they’re using the software, then it makes sense to me to call it the way they see it.

It got a little tricky with the latest project, where its name was changed a couple of times. Then it appeared that the software would simply use that same title. But what was my surprise when I started seeing a new title both on the login screen and in the application.

So I asked the program manager, and he confirmed that the application name is indeed different than the dev project’s. So that name became how I refer to the application in the documentation. I also try to use that title when talking about the system. I want to get the real name in my head. And maybe that will help other people, especially the stakeholders and users, use that same name.

This points to one of the benefits of documentation: establishing a common vocabulary between users, support, and the development team, in turn cutting down on confusion. It just may take a little while to get there. But in creating the documentation, in a way I do have the last word.

Related entries (auto-generated):

Technical Communicators as a Point of Contact between Users and Project Teams

The Technical Communicator as Project Manager

Teaching Project Management How to Work with Technical Writers

Why Writers Should Be Involved Throughout the Project Lifecycle

A Bug-Fix Cycle at Project End Is Good for Everyone