Not everyone gives thought to document naming conventions but this is one small area where you can help to bring clarity and ease of use to the many documents you produce on a project. By providing a consistent and easy-to-understand method of naming documents, it will make it much easier to organize information and find the exact document you are looking for.
What is it?
A document naming convention is simply a format that you consistently follow when saving your document and giving it a name.
There are a few reasons why it makes sense to spend a little bit of time to establish a document naming convention.
- Easily groups like information together
- Provides definition of what the document contains
- Makes it much easier to find a specific file
Have you ever needed to ramp up on a project and you wanted to start by reviewing some documentation, only to find that you’re looking at something like this?
And think about this…the part of the file name AFTER the dot has a consistent use (.xls for Microsoft Excel files, .doc for Microsoft Word, etc.) and doesn’t that make it easier to immediately get a piece of information about the file? You know immediately what kind of file it is. If you take advantage of creating a consistent use of the part BEFORE the dot, you can add even more easy-to-understand information about the document.
While any succinct convention will work, I personally use a convention that combines a lot of information in a fairly short amount of space:
Let’s break down each of these pieces.
Program/Project: The name of the program or project that this documentation is for. Whatever you use here, use the SAME name for all documents within the project (at least the ones that you produce). If it’s a really long name, use a commonly understood acronym or abbreviation. Something that would make it easy for anyone to know what this relates to. (Oh, and if you use project numbers, please don’t use that in the file name unless everyone who might need this documentation readily knows what the project numbers are, including a brand new person who just started today.)
Release: This is an optional element but I find it useful if you are working on the same effort across multiple releases. I usually abbreviate and just use an “R” with the release number (i.e. Release 2.4 would be “R2.4”) which helps keep the overall file name a little shorter. If you’re looking for the requirements document for the second of five releases, it’s much easier to have the corresponding release in the file name.
DocType: This describes the type of document. I use commonly used abbreviations, but you may choose to use a shortened word instead. I tend to use:
- Business Requirements Document = BRD
- Functional Specification Document = FSD
- Requirements Traceability Matrix = RTM
- Project Change Request = PCR (or Change Request = CR) (I also include the PCR number to help distinguish each change (i.e. PCR7))
Use the terminology that your organization is familiar with, but easily call this out right in the file name.
Description: For some documents, it makes sense to include a brief description. For example, on large projects I usually have multiple FSD documents for various functional areas. I would include a description of what functionality is in that document so it’s easy to find the right one. And if you want the docs to appear in workflow order instead of alphabetically, add a number to the front (i.e. 02-Ticketing).
For some documents like the BRD where you have a single document for the release, you may choose to skip this element. But if you have separate requirements documents for any reason (multiple iterations, different BAs working on different functional areas), then be sure to include a description to make it easy to find the right document.
Version: Include the document version number in the file name to make it easy for people to know that they have the right version. Every time you publish a version of the document, increment the number. (Multiple versions that only you see don’t need to be versioned since no one is referencing them.) You can use whatever numbering convention you like (for example, whole numbers for major versions, with decimals (i.e. 2.1) for minor versions) as long as each time you distribute the document it has a unique number.
If you’re using any kind of document management system where you “check in” the document, I have a couple recommendations:
- Use the version numbering that the system will use so that it matches up whether you’re looking at the document outside the system or within it.
- Many systems only consider the document a new version of the same document if it has the exact same file name. If that is the case, save a copy of your document (or rename it) without the version number portion of the file name. Use that copy to upload to your system and let the system assign the next version number. But if you email a copy to your team (or outside recipients who do not have access to this system), be sure the file name includes the version number.
Extension: Thankfully, this one is handled automatically for you by the application that you are using. Woo hoo! One that you don’t have to think about.
If I applied this convention to the files from the original screen shot above, it might look something like this:
Isn’t it easier to see like documents grouped together this way?
Here is a chart with some other examples to see how these elements might come together:
Additional Items to Note
There are a couple other “rules” I follow when naming files that I thought I’d share:
- Do not use spaces in the file name. This comes mostly from wanting to make sure that any links to files are clean and don’t get any extraneous characters added when spaces are converted. (URL’s will convert spaces to “%20” so the file name “Order System Spec.doc” would end up as “Order%20System%20Spec.doc”.) So instead of spaces, I use underscores to separate the sections, and hyphens if I want to break up information within a section (like the description segment).
- Use Capitalization. You can minimize the need for hyphens by just putting the words together and capitalizing the first letter of each word. Just smash the words together but use the capitalization to make it easy to read. This is similar to how website URL’s can be written to break up the words. For example, bobshouseofcars.com becomes BobsHouseOfCars.com.
Now, tell me what you think: Does your organization use a standard document naming convention? What kind of information is included in your convention? Any other tips or ideas you have for making the file name work for you? Even if you don’t currently have one, could you see any benefit in standardizing how you name documents on your project?