Axiom Extranet
A place for Axiom knowledge to hangout

File Naming and Version Control

Jared Robbins Content July 20, 2018

File Naming

Issue Date: September 13, 2017

Benefits of Consistent File Naming and Version Control

 Consistent file naming makes it easier to:

1)    Locate the exact file you need

2)    Ensure that you are always working with the most current version

3)    Recognize client-submitted and client-reviewed materials easily

Why Have Standardized Project File Names?

 Standardized project file names including 1) client name abbreviation, 2) short title, 3) module/workshop number (if applicable), 4) type of deliverable, and 5) version number are necessary for effective project management across teams and clients.

 

Special Notes

  • These standards are required for files that are submitted to clients (eg, content outlines, scripts, betas, PDFs) and for internal “working” documents/files.
  • If a client requires MLR codes in filenames, please add this number to the PDF version of the asset that will be uploaded into the MLR system and maintain the original filename for the asset itself (word document or PPT etc.) For example:
    Asset: AZ_BCLS_M1_AandP_SB_v3.0.docx
    PDF MLR file:     20170901_ AE3980_AZ_BCLS_M1_AandP_SB_v3.0.pdf

Who Is Responsible for Adhering to these Standards?

 Everyone on the team is responsible for the proper naming, filing, and maintenance of their respective project files.

How Do I Name a Project File?

 A file name is generated based on the following information:

1)    Client name abbreviation

2)    Short title

3)    Module/Workshop/VLE number (if applicable)

4)    Type of deliverable

5)    Version “number” (NOTE: for purposes of this SOP, the term “version number” is intended to serve as the unique identifier for the file. However, the “number” may contain letters as well as numbers.)

Example of a project file name: “AZ_BCLS_M1_AandP_SB_v1a.docx”

Which File Types Fall Under the Project File Naming Standards?

 All files require standard file naming, such as:

·         Content outlines

·         Scripts and Storyboards (Audio, Podcast, Print, Video, eLearning, etc.)

·         Facilitator’s guides

·         Participant’s guides

·         PowerPoint presentations (for live workshops, virtual sessions, standalone decks)

·         PDFs of print layouts

·         Proposals

·         Status/Contact reports

·         Timelines

·         Master print layout files (InDesign)

What Are the Preferred Names/Abbreviations for Some Common Document/File Types?

 ·         Content outlines = Outline

·         Facilitator’s guides = FG

·         Participant’s guides = PG

·         PDFs of print layouts = L

·         PowerPoint presentations = PPT

·         Proposals = Proposal

·         Storyboard = SB

·         Status reports = SR

·         Timelines = Timeline

·         Virtual learning experience = VLE

·         Virtual instructor-led training = VILT
When Do I Change the Version Letter/Number of a File?

·         The letter portion of the version number should be changed on an as-needed basis when planning to make a major series of edits to a document, file, etc. In addition, it is always a good idea to change the version letter when making a series of edits that may need to be reversed or when you take a document home to work on it, etc. NOTE: In the event you need to make a local copy of a document (working at client site, from home, etc), please be sure to e-mail your entire team to let them know that the most recent version of the document is with you, and not on the server. This helps avoid current-version confusion. But try to avoid working locally.

·         The number portion of the version number should only be changed when:

–         Submitting to a client (eg, v1d becomes v1.0 before submission)

–         Making changes to a document AFTER client review (eg, v1.0 becomes v2a)

Exception to the Rule

Version numbers for programming-related folders should only change if a major internal update is made to the program or when submitting programs to the client for review/approval.

Special Notes

Never directly change the file name of a PDF generated from any DOC, PPT, Layout, etc. When preparing a final pdf to go to client, always make a copy and change the file name, so as not to break the connection with the source file.

Version Control

Issue Date: September 13, 2017
What Is the Process for Changing a Version Letter/Number of a File? 1)    Document initiation:

a.     When a document is initiated internally, it should be named with a “1” and a lowercase “a” as the version number (eg, AZ_BCLS_M1_AandP_SB_v1a.docx).

2)    Internal updates:

a.     To update the version number when needed, save a copy of the document and assign the next lowercase letter to the version number (eg, AZ_BCLS_M1_AandP_SB_v1b.docx). Move the previous version of the document to the “Old” folder.  Only the current version of the document should sit in the root folder.

3)    Internal reviews:

a.     When a document is sent for medical review, ID review, and/or editorial review, the individual performing the review should add their initials to the end of the EXISTING file name (eg, AZ_BCLS_M1_AandP_SB_v1b_TH.docx)

b.     If that document is going to several reviewers in a row before going back to the author (or person making the revisions), each reviewer should continue to add initials to the EXISTING file name (eg, AZ_BCLS_M1_AandP_SB_v1b_TH_LML_JE.docx)

c.     Once the document returns to the author (or person making the edits), that person deletes ALL initials and increases the version letter (eg, AZ_BCLS_M1_AandP_SB_v1c.docx)

4)    Client submission:

a.     Once a document is ready for client submission, the person responsible for submission should ALWAYS save a copy of the document, remove the lowercase letter, and replace it with “.0” (eg, AZ_BCLS_ M1_AandP_SB_v1.0.docx). The “.0” will serve as the unique identifier to everyone internally that the document was in fact a client submission.

5)    Receipt of client comments:

a.     When a document is returned from the client with their comments, the person receiving the file (this person is usually the PM) is responsible for saving it to the From_Client folder within the appropriate deliverable folder. When saving the person adds on the end of the filename: “CC” for client comments and the date received (eg, AZ_BCLS_ M1_AandP_SB_v1.0_CC_4-20-17.docx). This ensures that a copy of the document, with comments as received from the client, is kept intact and the files are easily identified as such internally.

6)    Incorporation of client comments:

a.     The person to accept/reject client edits or to make other additional edits renames the file as described in number 1 above—this time indicating the next official version number (eg, AZ_BCLS_ M1_AandP_SB_v2a.docx) and saves it within the main root.

 

Special Notes

  • A document should not be named “FINAL” or “DELIVERED” or “CERTIFIED”. If we all follow the guidelines in this SOP there should not be a need for a special identifiers on the filenames, as everyone on the team will know which is the most current version of the file and the X.0 tells us it was client delivered and with the way clients come back for updates the file is really never FINAL.
  • Dates should ONLY appear in the client comments version of the file. The date should NOT be added in by a writer, ID, PM, etc on working versions of the document.
  • Be sure to consult the project proposal to ensure that you are not taking a document/file beyond the agreed-upon number of drafts/versions. When in doubt, confirm with PM.
  • When you see a document with a lowercase letter as part of the file name, you’ll know that this version has never been submitted to the client.
  • When you see a document with a “.0” as part of the version number, you’ll know that version went to the client.
General Information
SOP Issue Date September 13, 2017
Related SOPs Network Folders

 

 

 

About: Jared Robbins