A reader got in touch recently and asked for more info on document version control. Version control is used for lots of different project management assets. You’ll come it across it in particular in coding, where developers need to keep meticulous logs of what’s been changed and what version is the current version of the code.
The main elements of configuration management aren’t that different when we’re talking specifically about documents.
I honestly thought I already had covered that in the blog – it’s certainly the subject of a chapter in my book, Shortcuts to Success: Project Management in the Real World. (The chapter is only a few pages long; even I can’t spin out version control for more than that!)
The quick version is this: document version control is a way of making sure you know which is the current iteration of a document.
Why would you want to know this? Because it’s important everyone is working from the same version of a document. Imagine the hours lost if someone on your team was working from out of date requirements, for example.
Actually, I don’t have to imagine that situation, having been in it! Learn from my mistakes and keep tabs on how your files are evolving with version control.
How To Get Started With Document Version Control
Configuration management has always seemed to me to be a fancy title for something that’s very easy to do.
The easiest way to version control your documents is to have your software tools do it for you.
The reader was using Google Drive but I don’t think this will let you save previous versions of documents. Microsoft SharePoint will, if you set it up to do so. Every time you save a document back to the repository it creates a new version so you can always to back and see the changes that have been made.
Non-Software Version Control for Documents
If you don’t have software that can do it for you, you can control your document versions manually. Add a table to the front of the document that says the version, the author, a brief summary of changes in that version and the date.
Here’s what that the table would look like:
|0.1||1 March 2017||Nanette Bailey||First draft|
|0.2||15 March 2017||N Bailey||Review by |
|0.3||22 March 2017||N Bailey and F |
|Wider review |
by project team; section 6
|0.4||28 March 2017||F Jacobs||Final review by all |
|0.5||3 April 2017||N Bailey and F|
|Final version |
|1.0||14 April 2017||F Jacobs||Issued|
|1.1||27 April 2017||N Bailey||Updated |
Versions are 0.1, 0.2 etc until such point as the document is approved. Then it becomes version 1.0.
Subsequent edited versions become 1.1, 1.2, or if it’s a major update, 2.0.
Just like they name new iPhones, or software versions! Do not worry about the numbers going up and up. In one of my projects we’re currently on version 15 of a technical spec and you know what – it’s all fine.
You’ve then got numbers to use to refer to (and dates for extra backup) so that when you are talking to your team members you can reference the version you are using or expecting them to use. They can quickly see from the front of the document if they have the right/most current version.
Most of the document templates I use already have this table set up at the front. Once you’ve got it done, it’s easy to copy and paste the format to other documents.
It’s not the most interesting part of project management but good document version control will keep you organised!