How do you format your project names??

  • 25 July 2023
  • 9 replies
  • 266 views

Userlevel 2
Badge

I would love to get some thoughts from you guys! 💡

 

What have you found to be the most effective way to name your projects? 🤔

 

I know that having a standard naming convention across my projects helps a lot with easily being able to identify important information as well as helps knowing how and what to search for when trying to locate a project - But project names aren’t only important for my internal team!

​​​The project name is included in every notification that is sent from your project to the customer - that is a large number of touch points that can be used to act in your favor!

 

With task names we have best practices to help promote customer engagement that have proven to be incredibly helpful - But I think that we can use a lot of those same best practices for our project names. 

  • Clear Project Name
  • Customer Centric
  • Eliminate Confusion
  • Concise Wording

 

Practice

Let’s say, for internal clarity, I need to include the following information in my project name: 

  • Customer Name 
    • Example: ACME
  • Customer Account ID
    • Example: F37126403
  • Customer Location
    • Example: Lehi
  • Project Purpose
    • Example: Onboarding

How would YOU name this project to help promote customer engagement?? 


9 replies

Userlevel 4
Badge

We’re lucky - we run one project per customer so it’s simple to name them “Blah Blah Blah Construction”..

For this example, I’d name it ..

 

ACME [F37126403 - Lehi] - Onboarding

Userlevel 7
Badge

@Sara Fowers you bring up such a valuable point that the project name shouldn’t only serve the internal team! It should also serve the customer! (Imagine being a customer and trying to find a task assignment email but you don’t remember the name of the project “F37126403 Onboarding”)

 

@Casey Wilt brings up another great point that if you are onboarding a multi-location client (Imagine you’re onboarding all the Waffle Houses on the East Coast to a new point of sale) then the complexity of naming projects will grow. 

The key for multi-location onboarding projects is naming the project with the following info (that info in the middle is the secret sauce):

{Customer Name} [Store Number/Unique Identifier that the customer is familiar with] - {Project Purpose}

so that would look like:

Waffle House [F37126403] - Onboarding

I would avoid any internal-generated customer id’s that the customer is NOT familiar with. However, I understand that this may add a layer of complexity of getting the store’s id, but in my experience that info is readily available.

Userlevel 4
Badge

Great topic, @Sara Fowers !

 

I go back and forth on this, but on a different level I’m starting to find myself leaning into the customer’s perspective more and creating project names that make more sense for them.

 

For example, rather than “[Customer Company Name] Onboarding,” consider “[Provider Company Name] Onboarding.” In other words, if I’m Nike and I purchase Hubspot, Hubspot’s onboarding project name would be “Hubspot Onboarding.”

 

Reason being, Nike is not onboarding onto Nike, they are onboarding onto Hubspot.

 

The logic is that the customer is onboarding onto the provider’s platform, not the other way around.

 

Still thinking this through, but it’s food for thought...

Userlevel 2
Badge

@Mark Mitchell INCREDIBLE 😲

I love the idea of including the provider name to have it be even more so curated for the customer - I never thought of that.

In that case I can see how it might get confusing internally if the projects all have that name - how would you recommend combating that confusion? 

Userlevel 7
Badge

I feel like that’s where the Program Management feature in GUIDEcx comes into play. Then instead of having a project-focused approach, you search by customer name and then see which projects they have opened under them. That opens the door for a more customer-centric onboarding approach!

Userlevel 4
Badge

@Mark Mitchell INCREDIBLE 😲

I love the idea of including the provider name to have it be even more so curated for the customer - I never thought of that.

In that case I can see how it might get confusing internally if the projects all have that name - how would you recommend combating that confusion? 

I used to name my recurring weekly meetings as follows…

[Our Software] x [Client Name] - [Focus of call]

So all of my meetings read as…

  •  DESTINI x ABC Construction - Working Session
  • DESTINI x XYZ Builders - Training (1/2)

Just reading the meeting name told me who I was meeting with and what we were doing. And worked the same for them!

Similar format probably works nicely for project name too.

  • SOFTWARE x Client - Onboarding
  • SOFTWARE x Client - Additional Service

Same mindset as @Mark Mitchell but avoids the trap that we’d immediately fall into where 40 active projects have the exact same name if it was just “DESTINI Onboarding”

Userlevel 7
Badge

I think we’re getting somewhere! 

 

Userlevel 4
Badge

Yes, still thinking it through for the same reasons. It definitely resurrects elements of the conversation we continue to have of a PILOT vs PASSENGER experience that would necessitate differing syntax of project names for the provider vs customer. Also, to have persona-specific experiences i.e. Executive Sponsors receive experience overviews focused on high-level progress, and technical resources get an overview that describes exactly how they would participate in the project 🤔🧐🤔🧐🤔🧐🤔🧐🤔🧐

Userlevel 5
Badge

ok - so here’s a FR for you @Mark Mitchell and @emaynez. How about an internal/external project name so you can have the best of both worlds?

Example:

Internal - <Client Name> - <Client Account ID> - <Project Type>

External - <Provider Name> - <Product Type> - Onboarding

 

And to make things more complicated how about a 3rd party option that is <Client Name> - <Product Type> - <Provider Name> Onboarding

 

How ‘bout them apples?

Reply