Upping the Revision Number

I am glad to see that not a single person said they had no structure or that their versions depended upon printed copies. Thankfully we’ve come far enough to realize we need structure and that printed versions are an inefficient method to maintain version control. (Ok, at least most of us have probably come to this conclusion!)

Nearly everyone suggested that an automated versioning system, usually in conjunction with a check-in / check-out system, provides the best way to manage the process of versioning. Only one person can be editing a document at a time and until they are done, the document is locked as is. Once the check-in occurs, the version increments automatically. There is no methodology dispute here and no haggling over the format of the number; its simply a function of the system.

I’ll use this point to ask the group another question… how will concurrent editing such as is built in to Google Docs and newer versions of MS Word change this paradigm? Allowing multiple people to collaborate on a single document in real time, each making changes, means automated versioning is really not possible. I personally see this collaborative authoring to be a good thing, but it will introduce complexities we hadn’t yet thought of.

Back to the point, I put 'sort of’ in my header and you’re probably asking why? Frankly, as nice as document control systems are, even large Fortune 500 companies, maybe especially these companies, have been somewhat slow to embrace this technology. I’ve worked with products from a few different vendors and while they’re nice, they’re usually expensive and the check-ins can be gruesome if no one first put a lot of thought into exactly how they should fit into everyone’s workflow.

The second problem comes when only the project team members have access to the tool and the stakeholders do not. At this point controls become moot. Within a project team it is often easier to enforce a disciplined approach to document management, but stakeholders, who may not see as much obvious merit in the approach, can make all the changes they want, which then makes the project team’s job that much more difficult when it comes to reconciling multiple marked-up copies of the same document.

If a version control system isn’t available, then general consensus was using a major/minor (X.Y) versioning system. Most took the path that the project team revisions took place in the minor number and reserved the major number for some sort of wider review.

Craig Brown suggested that the major number is often used as a way to denote review by a steering committee, if one is part of the review process. Cleggton uses the minor number for any time the document is reviewed and that the major number is a milestone , gate-review or baseline review where the document has reached a level of sign-off or buy-in from stakeholders.

iqi616 mentioned that they ask the reviewer to append their initials to any reviewed copy they are submitting. This is a practice I personally adhere to when reviewing a document for anyone else. I know how difficult it can be to manage having 20 people review a document and trying to keep it straight as to who said what.

Karyn C brought up a point about using the major number in the scheme to denote a document reference Id. The minor number then becomes the only revision number so that you always know you’re looking at revision Y of document X. While I’ve seen (and used) a document identifier as part of the document name, in combination with a more human friendly descriptive name, I don’t think I’ve seen it used in quite this way. Karyn C, I’d love to know the origin of this method if you could share it with us in the comments.

Craig Brown, co-owner of this site, commented that  documents marked as 'Final’ rarely are and should probably not use the file name in this way. I’ve not seen anyone do that around me in recent years, but it was common place when I started out as an analyst. My experience agrees with Craig, its just a silly practice.

I usually go a step further and say that putting the version number in the filename is nearly as silly. If you’re going to add anything in the document filename beyond the document’s actual name (and possibly a project/company reference number), I suggest ending documents with the date of the revision in the 'YYYYMMDD’ format. I say this because that way you don’t usually need to guess which is the newest as the different versions of the document automatically sort themselves in a file manager.

The last thing that was brought up by several people was track changes and/or read-only copies. Why list this as a 'pet peeve’ if so many people seemed to be passionate about it? I personally am in favor of the idea and find it incredibly useful, but have mostly given up on using it as my stakeholders seem to generally hate the function with an unrelenting passion. Maybe it is just the ones I’ve worked with over the years, but they either refuse to learn how to use it and thus don’t review the document, or I receive printed copies with changes penciled in because they won’t edit electronically unless they can make their changes inline and then highlight. It honestly became too much of a hassle for this analyst, so I adapted and moved on rather than spend even more time fighting against what was a losing battle.

Thanks to everyone who made comments. I definitely want to do this in the future with more topics. If you think of one you believe would be fun to do, drop me a note in the comments.