What’s in a Name: Considerations for Defining the Naming System for Your Documents and Data

©2015 Mark Henderson

If I were a betting man, I’d lay a tidy sum on the side that most of you reading this have never given serious thought to how and what to name your documents. But, if I were to prove that the methodology you use to identify (and control) your documentation can have a significant impact—either positive or negative—to your bottom line, I might quickly move that wager to the other side—that you would consider your documentation nomenclature schema more intentionally.

Your system for document identification and control is your document nomenclature (or naming) system. In general, documents are often identified by their number and controlled by their version. Now, I said in general; that is because some organizations have a business need to assign ownership, and therefore control, within the document identifier. For example, all drawings are produced and revised by the Drafting Dept., so the document identifier—usually a numeric or alpha-numeric document number—might have “DWG” as part of the document identifier indicating it’s a drawing, and therefore owned (i.e. controlled) by Drafting. But, in general, when we refer to controlling documents, we’re talking versioning.

Versioning all documents is critical to managing documentation!

Rule #1 in versioning:  Do it! Rule #2:  Refer to Rule #1. Versioning all documents is critical to effectively managing documentation and maintaining any semblance of order and document integrity. Best practices for managing versions—or the cons of bad or non-versioning—is a discipline unto itself, and can be a standalone subject for a future whitepaper. I am only discussing the approach for identifying your document versions.

When defining version nomenclature, keep it simple—the simpler, the better. I prefer a whole number, such as 1.0; others prefer a single, uppercase alpha, such as “A”. Some like to add a date, such as a release or approval date. I disagree; I prefer adding document dates to document’s revision and history page, if for no other reason that adding a date to your version ID violates the “keep it simple” rule.

When defining version nomenclature, keep it simple.

That said, I certainly understand the need for identifying versions iteratively during development and validation (i.e. pre-release) phases. Wendy and I use iterative versions all the time—and I do mean all the time. As consulting writers, we denote deliverables in whole numbers, and iterative versions between us as 1.1, 1.2, and so on. Similarly, most businesses use the whole number (or alpha) to denote release or approval, and single decimals to distinguish iterative versions not yet approved or released. Software developers can iterate so frequently and so rapidly—especially agile development—they need a special approach for identifying versions, both for the software being developed and for the corresponding documentation. Most software development organizations have a system for checking out and checking in software that versions each increment checked out and in; user document development usually follows and is similarly versioned, oftentimes in parallel. What you don’t want is to have your versions looking like IP addresses, because it’s darn hard to figure out what version you’ve got when it reads something like v.! Again, emphasis should be on keeping the version identification simple, even in software development.

So when it comes to identifying, or naming, your documents, it probably will come as a surprise that absolute simple is not always the absolute best. It’s just not that simple, darn it! For example, if I identify the first document produced as “1”, and the second as “2” and so on (and that is as simple as it gets), how do I know if I have a drawing or a policy by looking at the document number? Or, next year, after I get “downsized” or promoted or brain-drained or gone, exited by any number of means, how will the folks left behind know how to search for this or that document? My point is that oversimplifying your document naming method can create inefficiency and errors (a.k.a. cost you money).

In naming your documents, simple is not always the absolute best option.

On the other hand, over-complication can create the same, or even worse. Usually, over-complication is the result of so-called “smart numbering” systems. In my opinion—after playing with about a gazillion documents spread throughout hundreds of different client nomenclature schemes—the more groups of IDs set between dashes, the “dumber” the number, and I have seen some dumb numbers!

I believe the minimum elements of a document ID should be the document type (e.g. DWG-, BOM-, PLAN-, PROC-, FORM-) followed by an alpha-numeric document number, and of course, the version. The number of characters in the document number should be dictated by the size of the organization and the number of documents envisioned, in total. When deciding to include additional information in the document number, do so judiciously, and with the knowledge that you’re adding complexity and probably not nearly as much value you think.

The ideal element of a document ID should be the document type followed by the alpha-numeric document number and the version.

One of the biggest problems I’ve found with “smart numbering” systems is they are more difficult to search in enterprise document databases/document management systems (DMSs). This costs time—often, lots of time when multiplied by the number of users in a large organization—and that is time wasted.

Documents need to be clear, concise, and valid; and, they also need to be easy to find. And search capabilities of the DMS aside, it’s the name (or document ID or number) that enhances the document’s ease of being readily located.

Documents need to be clear, concise, valid, and easy to find.