University College Northampton Records Manual

The UniversityOfNorthampton Records Manual

Version Control of Documents and Records - Guidance

Guidance to be used for the IS Department

Version D3.0

Not an OfficialUniversity document

Compliance

Compliance with this document is recommended for all University Staff. Compliance may be mandated to external bodies through The University of Northampton Contracts.

Issue record

Version / Date / Comments
AD1.0 / 5th January 2006 / draft discussion document (not an official University of Northampton document)
A FD2.0 / 23rd January 2006 / Finalised draft approved for use within the IRS Department and to be presented to Records Management Group for final University approval
D3.0 / 16th June 2008 / Extensive rewrite to simplify in line with the requirements of TUNDRA

Contents

1Purpose

2Scope

3Definitions

4Introduction

5Why bother with controlling Drafts and implementing Version Control?

6Version Control basics

7Version Control Process

8Changes to existing Version Controlled Procedure, Guideline or Policy Records

1Purpose

The purpose of this document is to outline a single consistent process for the drafting and version control for new documents and recordswhich will provide an identifiable process flow for documents under development.

2Scope

This guidance applies to all staff at all sites thatcreate or amend documents and records.

3Definitions

Version Control

Managing changes to documents as they are edited, reviewed and finalised and providing an auditable trail of the various versions throughwhich they pass.

Hard Copies

Copies of documents held in a non electronic format such as paper

Master copy

The document which will be gradually amended to form the final record

Compiler

Member of staff acting as custodian for a document under development, and the person authorised to make alterations to the text.

4Introduction

One of the main problems faced by all staff is the ever increasing and routine duplication of information via email, shared drives, or hard copies. This can include the sending and receiving of copies for review, or agenda and minutes of meetings, or for information, which means that several staff members will be holding potential near identical sets of information. This duplication takes up valuable computer server space or office floor space and makes information more difficult to locate. Without the inclusion of identifying version details it can become difficult to identify what the current version is. As such staff are unsure whether staff are consulting or amending the most up to date draft or version.

5Why bother with controlling Drafts andimplementing Version Control?

Document control would not be necessary if documents were only prepared and released once and never ever get amended. This is not generally the case, as most documents go through various iterations before being finally issued as official University records. Even fairly simple documents may be reviewed, amended, and re-released on several occasions.

Some of the problems that draft and version control can overcome include:

Having to print out and compare several documents all of which could be the latest.
problems in determining the difference between documents;
superseded documents remaining in circulation;
staff referring to, or working from an out-of-date document;
staff working on superseded documents creating several new unapproved or unreviewed drafts or versions
not knowing who madewhat changes to copies of the documents;
difficulty in identifying who holds the original

6Version Control basics

One person (compiler) should have sole responsibility for making changes to the master copy. Any proposed changes to the master copy by other members of staff should be fed back to the compiler who should highlight the changes to be discussed on the master record but should not amend the existing text until agreement has been reached (the ‘track changes’ functionality in MSWord allows for this and can be used to attached the name of the person proposing the changes to the suggested new text). This ensures that documents go through a formal approval process and are not solely reliant on one member of staff’s interpretation of the issues.

Mark the status of the document and of the copies made of it so that other staff can identify whether something is a draft for consultation or discussion paper, a reference copy, a finalised version to be presented to a committee for approval, etc.

7Version Control Process

Requirement for a new document is established and a review group identified to (if required) discuss the issues and put forward ideas as to the content.

Compile the first draft discussion document and complete the first boxes in the issue record table which looks like:

Version / Date / Comments
D1.0 / 22nd Dec 2007 / draft discussion document on [subject]

The version box is filled in as version 1.0 to indicate the originating document. If a small correction is made to the document such as amendments to spellings then this would create a minor draft version change and this would be expressed as 1.1 (the .1 indicating that a small change has been made). This would look like this:

Version / Date / Comments
D1.0 / 22nd Dec 2007 / draft discussion document on [subject]
D1.1 / 2ndJan 2008 / draft discussion document on [subject] amended for spelling changes

This is then issued to a review group either by email or in paper format (and a response date specified) and any proposed changes are then returned to the compiler who includes these proposals in the document using the track changes function or by otherwise highlighting proposals (this could mean highlighting one persons amendment ideas in one colour, someone else’s in another and so on). For example the original text might read “Richard of York gave battle in vain” and any changes proposed by Dick are highlighted in red and those proposed by Harry are shown in green so their proposed changes would be shown thus: “Richard of York gave battle [got blotto] [gained burgers] in vain[vinegar][Vanuatu]”

This new document is then called 2.0 and the issue record now looks like:

This document is then used as the basis for a discussion for a meeting of the review group and an agreement is reached as to which changes to accept. The document is then passed back to the compiler who makes the changes as agreed and this document is then issued as the formal version needing Committee or other approval processes to be carried out (depending on what has been decided at the review group meeting).

At each Committee review stage the document will go through a similar process as described above, which will create new major or minor versions as appropriate until the document is issued as an official University record when it should be noted by an Ras shown below:

Version / Date / Comments
D1.0 / 22nd Dec 2007 / draft discussion document on [subject]
D1.1 / 2ndJan 2008 / draft discussion document on [subject] amended for spelling changes
D2.0 / 5th Jan 2008 / Draft discussion Document on [subject] including proposed amendments from review group
D3.0 / 9th Jan 2008 / Finalised draft to be presented to XYZ committee for approval (not an official University of Northampton document, but might in some circumstances be retained as a record)
R4.0 / 29th Aug 2008 / Procedure as agreed by X Committeeand in operation as of today’s date (this document then effectively becomes a formal record as it documents a procedure being worked against at a certain point in time). To be reviewed by the X Committee on or by the 29th August 2010.

8Changes to existing Version Controlled Procedure, Guideline or Policy Records

All policy documents, procedures and guidelines are reviewed after specified periods of time and more often than not this leads to alterations to the core document. Any amendments made to a formally issued record of this type should create a new master copy, so that the content of the Version R4.0 is not altered except to highlight that it has been superseded and on what date (a watermark of the word ‘superseded’ should also be added to all pages). This is shown as:

Version / Date / Comments
D1.0 / 22nd Dec 2007 / draft discussion document on [subject]
D1.1 / 2ndJan 2008 / draft discussion document on [subject] amended for spelling changes
D2.0 / 5th Jan 2008 / Draft discussion Document on [subject] including proposed amendments from review group
D3.0 / 9th Jan 2008 / Finalised draft to be presented to XYZ committee for approval (not an official University of Northampton document, but might in some circumstances be retained as a record)
R4.0 / 29th Aug 2008 / Procedure as agreed by X Committee and in operation as of today’s date (this document then effectively becomes a formal record as it documents a procedure being worked against at a certain point in time). To be reviewed by the X Committee on or by the 29th August 2010.
R4.0 -NOT TO BE USED. PLEASE SEE R5.0 FOR CURRENT VERSION / 30th Sep 2010 / Superseded by Version R5.0 as from this Date

The new version should have gone through the same process as before to reach a position as being a record (in the case above version R5.0) and thus:

Version / Date / Comments
R4.0 / 29th Aug 2008 / Procedure as agreed by X Committee and in operation as of today’s date (this document then effectively becomes a formal record as it documents a procedure being worked against at a certain point in time). To be reviewed by the X Committee on or by the 29th August 2010.
D4.1 / 4th Sep 2010 / Minor changes in text identified and altered. Finalised draft as created for X Committee to review
D4.2 / 8th Sep 2010 / Includes amendments agreed by X Committee
R5.0 / 30th Sep 2010 / THIS DOCUMENT SUPERSEDES VERSION R4.0Procedure as agreed by X Committee and in operation as of today’s date. (this document then effectively becomes the new formal record )
To be reviewed by the X Committee on or by the 29thSeptember 2012.