Naming convention for projects?

Our Marketing team is using a naming convention that was specially programbed by our Workfront Super Awesome Tech Person. Here's an example: CEM_FY16-16675_ Graduation Photo Request So the first three letters are a code for who our customer is which is generated off of the Company field. The FY16 is obviously the fiscal year. The next set of numbers corralates to the Workfront generated Reference Number. The last part is what the actual request is. Hope that's helpful.

We have some groups (1800+ users over many departments) who have set up naming conventions, mainly based off their old systems. Rather than naming something by customer, we have a dropdown for it. Some projects get rolled into programs, which would be likely another part of a naming convention otherwise. We've found that naming conventions end up unreliable and custom data elements are preferred. These custom data elements are much more reportable (matrix reports, filters, etc) and they dont fall victim to fat-fingered people like me.

As another poster mentioned, we also use cutom fields to identifiy characteristics of projects, rather than using the name field. We have domains, or areas of our systems, each with a 3 character abbreviation. We added this as a custom field. We then combine this with the reference number, to get a project number, eg. RUW-123456. We also have custom fields for project type (investment, enhancement, etc), and product type. our project name is simply the text name of the project. Of course, the custom fields are then reportable.

We use a format that contains the type of project, locale and launch date, e.g... Direct Mail - Sales Brochure - Q3 - FY17 - ANZ This allows us to report on progress and also gives clear visibility of who is doing what, and for where.

To replicate another post, we have custom fields to help categorise and sort projects, whcih isnt linked to the project name. That way you can categorise and sort based on user drop down boxes and maintain the consistency.

Our team uses the following -Reference number: I'm not sure why they want to add this to the name of the project -Country: Where the project was requested or where it will apply -Department - Description

our projects are pieces, so the name of each project is the visible title you see on the piece. For example, our open enrollment letter project would be called Open Enrollment Letter. Additionally (as others have stated), we have custom fields that capture program, form number, revision date, and customer info. So we can run a project report where you would be able to see that the Open Enrollment Letter was created with a trackable form number and revision date, and was made for our Benefits Division for their Enrollment Program. By doing this, we will also be able to run reports that categorize our projects by customer, program, etc., without having to force PMs into duplicating this data (once in the project title, and once again in the metadata). Since our users find this is all information that they need to do their work, we've also adjusted our "My Work" area to show this information in each task and request they are assigned.

Ia gree with some of you: Use custom fields and then you are able to filter by Department, Country, Area , etc.

for our naming it comes out more system-based; as we use InMotion to proof (i know i know, Workfront has a better option but it's entrenched as heck here...) so instead we had things drive via channel (our Marketing is heavily print but there is a good bit online) and then area of business (DiY - consumer or DiFM - commercial); followed by an auto-number and then Job Name: ECOMM - DIY - AUTOGENERATED INMOTION NUMBER by DEPARTMENT - JOB NAME or PROMO -DIY--1234 Dec. AAP Buyers Guide and the name makes it easier for all sides to quickly know what it is / pull reports from the job area and more! it's a good hybrid system we've used for a little over a month now.

Personally, using the year in the naming of your project can get you into trouble depending on your organization. Sometimes scope creep or circumstances cause things to shift, next thing you know you're having to make adjustments to the name of the project which can cause discomfort. We use as an example "EGD160001 - coded_description" (EGD=team acronym doing the project) (## = year the project starts) (#### = sequential order just to keep track) (coded_description = we leave flexibility to the lead to tie the name back to other teams so they can communicate in whatever fashion they'd like at that point.) We then use the dates within WF to really track the project status vs letting the name with a date in it bias people. Hopefully that makes sense or helps?!