Naming convention for projects?

[KellySa]

What naming convention are you using for projects? I'd love to hear what some others are using. We are currently using: program_projectdescription_date program: should match the “program” selected from the drop-down menu on the Standard Intake Form projectdescription: should match the “request type” selected from the drop-down menu on the Standard Intake Form , include week or quarter for weekly or quarterly communications date: should match the “go live/distribution” date selected on the Standard Intake Form , use a two-digit month followed by a four-digit year Examples: openenrollment_letter_112016 allemployeemeetings_q3presentation_082016

[Mohini__Mini_Si]

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.

[MartyGa]

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.

[MariaGr]

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.

[MatthewKe]

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.

[CommunityUs]

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.

[GabrielaLo]

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

[SkyeHa]

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.

[AbelardoMa]

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

[AdamMe]

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.

[nono1345]

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?!

[ScottSa1]

We haven't been using naming conventions for projects, just simply a descriptive title that the person seeing the project will have an idea about what the project is about. Then we use many custom data fields to put the descriptive information about the project so that we can filter in reports or display in reports. Curious, though, when using the naming conventions, what is your ultimate goal? Is it for record keeping? Filtering? And then curious why not use custom data instead of naming conventions? Not saying one way is better than the other, just curious so that we can determine at my organization if we are doing it the best way for our needs. Thanks!

[tadams-1146613]

At my company, we need to align the project name to be usable and compatible with other programs so we have the naming convention of: Fiscal Year Brand Market Location Season/Product/Program Name Media Type/Format Cheers! -- Scott Adams Workfront - Data Inspires Creativity Business System Analyst Lead

[angiet39887144]

We do something similar to this too. We do Year.Month ProjectName. So things like "2016.07 PresidentsClub" This is helpful cause it organizes things chronologically, but also makes us remember when we worked on certain things. We are slowly but surely moving to WebDAM so hopefully the timing of projects will have less of an impact moving foward.

[KarenRu]

Hi Angie, My comment is less about naming conventions- but curious about your move to Webdam. Did you purchase the WF integration? or is the product seperate? We're in the middle of implementing Web DAM as part of WF- and would love to talk to you offline regarding what you're doing- maybe we can share experiences. tks Karen

[PeggySe1]

We use PortfolioAbrv-ProjectName (such as MKTG-New Website)

[PhilipSt]

I'm enjoying reading these, as we are going through a discussion on how to name our projects consistently right now. I would love to see examples of some of the custom forms mentioned, to get a better idea of how to use them. Thanks, Phil

[SkyeHa]

Phil, good idea, a picture's worth a thousand words. I can't see a point in showing our custom form just because there are so many display logic bits, however here's a screenshot of my project view.

From top to bottom and left to right:

- we're grouping by Division -- a custom field

- our workers track and refer to pieces by Form number and Rev date -- these are custom fields

- the name of the piece is the title of the project, and this is a workfront field, along with our due date, % complete and status. Our upper management refer to pieces by their names rather than form number.

- Custom fields for Piece format, piece type and type of work all combine to indicate complexity. New pieces are more complex than revised pieces, brochures are more complicated than fliers, print is more complicated than PDF.

- PM and Priority are Workfront fields.

Many of our reports are set up in the same way. If we are reporting on projects, the fields we automatically include are Form number and Rev date, right next to the name of the project. For us this also keeps that project name field shorter, since it takes up so much room at the top of a project's page.

[CommunityUs]

Vittorio - When you reference using the sequential number in your naming convention is this a manual process or have you found a way to automatically generate that sequential number into the project name field? We are really trying to solve for the ability to have a sequential number in our naming convention without having to manually track and add this.

[pco88]

Hi Mary, if you haven't voted yet - you might be interested in upvoting this idea in the exchange. Thanks. "https://support.workfront.com/hc/en-us/community/posts/115001218447-autonumber-field-docket-numbers" https://support.workfront.com/hc/en-us/community/posts/115001218447-autonumber-field-docket-numbers

[BrookeVa]

We work with multiple clients so the way we set our projects up is like this: Billing Flag - Client Name - Client Project Description - ### NB - Rockfish - Rockfish Website Redesign - 1234 NB stands for nonbillable so that our accounting teams knows we do not have signature on a legal doc yet. Rockfish is the client. Rockfish Website Redesign is the name of the client's project we are working on and the 4 digit number is what we refer to as a "job #" and each project will have it's own unique number. Other billing flags that we use: R - retainer IWO - internal work order E - email approval INV - investment Giving each project a unique job number helps when it comes to logging time. PMs can easily say "bill your time to job # 1234" and the user can easily locate that on a timesheet or the search bar. The way we name projects is also helpful to our accounting team because it gives them the billing flag (letting them know if it's okay to bill), provides the client's name, and the project name. Hope this helps!