This post originally appeared on September 13, 2010 on BetterProjects.net.
A few days ago, a few more than I intended due to the sudden onset of an illness I am just now getting over, I asked the followers of this blog about how they went about increasing the revision number on a document. Am I ever glad I did that without just ripping off a post from the hip. Not unexpectedly, you all had some awesome answers that I’d like to point out and then toss in a few thoughts of my own.
But before we begin…
Before I do that, I have to ask one question though… do we put too much thought into this question? Does it even really matter? When put into the greater picture of projects, programs and products, I really don’t see that it does matter. Who really thinks about the revision number of something when they set out to do a task? We generally think of things in two ways: how we do it now and how we did it previously. Sometimes that ‘previously’ can have multiple iterations if we’ve spent enough time in the same role. You could argue that there is a third way, how I want to do things, but that is something that usually comes before a revision number increment of a document and thus doesn’t exactly fit our overarching question.
If it doesn’t really matter, then why do we fight over it so much? I’ve seen knock-down, drag-out fights over this seemingly insignificant issue. Often this is a ruse for people who want to bicker about bigger issues but can’t find any other way to win their arguments. Others see this issue as a question of correct, at least in their mind, methodology and not updating correctly is a failure to adhere to the rules. Whatever the reason, I’ve seen many a good project team member go down roasted in flames over something that can be as simple as on which side of a decimal a number should increase. What is most important here is to provide a recognizable way to indicate to the readers of a document that something has changed and that it is in their best interest to seek out those changes.
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!)
Keeping it simple (kind of)
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.
A Pet Peeve
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.
Wrapping It Up
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.
Subscribe to Ted Hardy
Get the latest posts delivered right to your inbox