Document version control made easy (with examples)

A reader got in touch recently and asked for more info on document version control and how to do it. It’s not that hard to do for Word documents, or you can rely on software like SharePoint to make it a whole lot easier.

In this article we’ll discuss the principles of version control for files so you can get started, whatever software you use.

What is version control?

The quick definition is this:

Document version control is the process of tracking and managing different versions (or drafts) of a document so you know which is the current iteration of a file.

Version control is used for lots of project management documents as well as other assets.

You’ll come it across it in other areas of your work as well, particularly in coding, where developers need to keep meticulous logs of what’s been changed and what version is the current version of the source code.

In that environment it’s part of project configuration management. The main elements of configuration management aren’t that different when we’re talking specifically about documents.

I honestly thought I already had covered this topic on 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!)

Why is version control important?

Why would you want to know which is the latest version of something?

Version control is important because then you know everyone is working from the same version of a document. And you know they’ve got the latest version.

Imagine the hours lost if someone on your team was working from out of date project requirements, for example.

Actually, I don’t have to imagine that situation, having been in it! It became part of lessons learned for our projects. Learn from my mistakes and keep tabs on how your files are evolving with version control.

This process is important because it helps keep an audit trail of how the file was changed, who saw the changes, whether or not they have been approved and when it all happened. For project managers, that’s useful information.

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.

(If you care about this kind of thing: your configuration management plan is part of your project management plan.)

The easiest way to version control your documents is to have your software tools do it for you. Project management collaboration tools often have this feature baked in. If you can find the right tool.

Every time you save a document back to the repository, your software creates a new version so you can always to back and see the changes that have been made.

However, that approach is not without its issues either. I discuss those below, so read on for some considerations for relying on your software.

How does version control work?

Version control works because the process makes sure no one is over-writing or changing the information entered into the document by someone else.

In other words, someone ‘checks out’ the document and works on it. You can see what it looks like using Dropbox for teams in the screenshot below.

Once a version is completed to the point where you want to get feedback from other people, you can then make it available for them to see. Then other people can access and do their changes, comment on the changes already made, accept, reject and edit.

You carry on like that until you have a final version of the document that everyone can agree to.

How to do version control for documents

Some software has version control tools built in. Microsoft SharePoint, for example, was a life-saver when I was using it, because it kept copies of previous versions. You could configure how many versions it kept.

Then if someone messed up a version or you wanted to compare what had been changed, you could easily review a file from several iterations ago.

Google Docs has built-in version control in that you can see the revision history of your online documents. Dropbox has the same: log in via the web browser, navigate to the file and then click version history to see past copies. This has saved me plenty of times in the past!

Check the software you use — maybe it already has version control features or they could be switched on.

If you don’t already backup your documents beyond simply saving another copy with a new version number, then read how to choose a backup solution for your project data.

So how do we do it?

Add a version control table to the front of the document that records:

• the version number
• the author
• a brief summary of changes in that iteration of the document
• the date.

Let’s look at how to create that table.

How to use document numbering in a version control table

If you don’t have software that can do it for you, you can control your document versions manually.

Here’s what that the table would look like:

Version	Date	Author	Rationale
0.1	1 March 2017	Nanette Bailey	First draft
0.2	15 March 2017	N Bailey	Review by architect
0.3	22 March 2017	N Bailey and F Jacobs	Wider review by project team; section 6 updated (new dates)
0.4	28 March 2017	F Jacobs	Final review by all stakeholders; project team comments incorporated
0.5	3 April 2017	N Bailey and F Jacobs	Final version for signature; costs updated
1.0	14 April 2017	F Jacobs	Issued
1.1	27 April 2017	N Bailey	Updated deliverables (section 5)

Version control numbering works like this.

Each draft of the document is saved as an incremental number: 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. The ‘.x’ part of the number represents a small change. We rename the document to the next whole number if it’s a major update, e.g. 2.0.

This makes version control for Word on documents really easy, just add the table at the front of the document and change the file name.

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.

Note: If you make a totally new file for a totally different purpose, the numbering of that file goes back to 0.1 again. Add the number to the file name. You can have Project Charter 0.1.docx and Business Case 0.1.docx. The numbering is specific to each file. Just saying.

The rationale column is for a brief description which highlights what is different about this version compared to the last one. It may have no changes beyond the version number, because the ‘change’ is that it has been approved and become version 1.0, the ‘final’ one (at least until the next update!). Or you may add a couple of words to reflect what’s happened in the file so readers can quickly spot the differences.

You’ve 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. If you are creating a spreadsheet, add a tab at the front with the name ‘version control’ and use that as a way to record the dates and updates for each edition as the file gets updated.

In my experience, software project teams find this way of working pretty easy as they are already familiar with configuration management and the concepts of keeping versions. If you are working with a team who does not have this background, they may benefit from you explaining a bit about what version control is and why you are doing it, before you expect them to understand what you are talking about.

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.

Using ‘v’ in document file names

I don’t use v to stand for version in my file names, unless we’re doing very informal numbering and the docs are more for my own personal use than a formal part of the project management process. I prefer to stick with just the number.

However, if you want to include v in your file names, go ahead. It would make the file name look like this:

Project Pancake Charter v1.2.docx

Personally, I think that looks too informal for large projects being run with a super structured methodology, but do whatever suits your team.

What to do with old versions

So what do you do with all the old versions of the files you’ve created?

It’s best practice not to simply save over the past copies. In other words, don’t just hit ‘save as’ and update the file name. You want to make a separate copy, which may or may not be stored in a separate location in the central repository.

Towards the end of the project when you are preparing your handover and archiving, you may decide that you don’t need to keep every single incremental version. During the project close phase you can make decisions about what files to keep and which to delete.

I tend to save them all. Unless they are copies of a working file and genuinely not needed, I want to keep the whole set of files as it represents the project’s history of changes, and if you don’t have an issue with server storage space, then why not?

Check your document management policies and see what your organization wants you to do.

Managing automated document version control

While Google Drive, Dropbox and SharePoint will save copies of your past files, that’s not the smartest way to do version control. You don’t need a snapshot of the version every time someone hits ‘save’.

It is better to use good document management principles, and keep the versions you need. Use the reference table on the front sheet (or back if that works better for you) of your file so you know what’s the latest version.

In other words, don’t rely on software to magically do your document versioning for you. Auto-saves aren’t a replacement for good file management.

The other issue with using automated versioning is having to deal with conflict resolution. This happened recently on one of my projects.

A colleague and I were working on the same spreadsheet. She was in it and I was in it, multiple times over the course of a couple of days, and because of conflicts, Excel kept saving different versions. In the end, she had to go through all the versions we had accidentally created and consolidate them all. Try to avoid that by starting out as you mean to go on!

It’s not the most interesting part of project management but good document version control will keep you organized! It doesn’t take much time once you get the hang of it.

Your next steps

• Review which of your project artifacts should be under version control and check they are.
• Talk to your team about the versioning system you are using (if you have one) so everyone understands what is expected of them.
• If you don’t have one, talk to the team about how you are going to start putting your files under document management and why it’s a good idea to do that.
• Then start numbering your files!