“Which copy did you send to the client?”
There is a pause. The project manager sent one yesterday. The project director had also made some changes and asked someone else to tidy up the formatting. That copy went out this morning.
Both documents look professional. Both have the same title. Both are marked final.
Unfortunately, they say different things.
Now someone has to work out which changes were approved, what the client received, and whether anyone has already started work using the wrong information.
Problem: Different Copies Become Different Instructions
Two people are controlling the same document
When a project team prepares a set of plans, reports or specifications, several people will usually contribute. That is normal. The problem starts when they independently arrange changes, formatting and release without coordinating the final document.
For example, a project director asks for a copy of a management plan to review. They make changes and ask an administrator to enter them and reformat the document. Meanwhile, the project manager is doing the same thing with another copy.
Each person assumes they are improving the latest version. Neither realises that the other copy contains changes theirs does not.
The project manager might be the only person authorised to approve changes, but that does not help much if someone else can quietly produce and issue a competing version.
Small changes create larger inconsistencies
The differences are not always obvious. A revised table might appear in one copy but not the other. Page numbering changes, references point to the wrong sections, or different names are used for the same equipment.
Formatting can introduce errors too. A table row disappears, a chart becomes unreadable, or an appendix is left out when the document is converted to PDF.
The team then wastes time comparing files and reconstructing what happened. Worse, the discrepancy may go unnoticed until someone orders equipment, prepares a tender or completes work using the wrong requirement.
The newest file may not be approved
A recent modified date does not tell you whether a document is suitable to use. It could be an unfinished draft, a review copy containing suggestions, or a file someone opened and saved without making an authorised change.
Likewise, “Final” in a filename proves very little. Once you have “Final”, “Final Revised” and “Final Use This One”, you have a naming problem as well as a document control problem.
A document can also be correctly approved and stored, yet still fail the project because the contractor is using an older attachment or a printed drawing left in the site office.
Solution: Coordinate Changes and Control What Is Issued
Project document control should make it easy to identify the right document, understand its status, and know who can change or issue it.
I believe the most useful starting point is to put one person in charge of coordinating the final production of each important document or document set. Support that person with clear storage arrangements, revision records and an issue process that everyone follows.
Give each document a controller
Identify who coordinates the document from draft through to issue. On a small project, this might be the project manager or administrator. On a larger project, it could be a document controller working with discipline leads.
You do not need one person controlling every document on a large project. You need a clear controller for each document or defined set, so there is no uncertainty about who brings the changes together.
Separate this responsibility from approval authority. An administrator may incorporate comments, check formatting and prepare the issue package. The project manager or technical approver still decides whether the content can be released.
Reviewers should send their comments through that agreed process. A senior manager can request changes, but should not independently arrange for another copy to be formatted and issued.
Name a deputy as well. The process should continue during leave without people creating an unofficial alternative.
Set up one controlled working location
Decide where the working files belong at the start of the project. Explain the folder structure, document numbering and access arrangements before people begin saving documents wherever seems convenient.
The location should be accessible to the people who need it, including staff in other offices. If the official system is slow or difficult to use, investigate the problem. Otherwise people will keep private copies simply to get their work done.
Use one authoritative working record for each document, supported by its version history. Keep issued revisions as identifiable records within the system. You still need the history; you just do not want several competing masters.
Where practical, send internal reviewers a link to the controlled document rather than another attachment. Check that the link opens the intended draft or approved issue for that recipient.
This follows the principle in Single Source of Data: the team should know where to find the information it can rely on.
Choose how people will edit and review
A check-out and check-in system can prevent two people editing the same controlled file independently. Someone checks the document out, makes their changes, then checks it back in with a useful explanation.
However, check-out does not stop someone downloading a copy and asking another person to change it elsewhere. People still need to follow the agreed process.
Collaborative editing (such as through Sharepoint, Google Workspace or a similar document management system) can also work, provided contributors use the same working document and someone coordinates the review and release. Define who edits which sections and how conflicting comments will be resolved.
Microsoft’s guidance on checking files out and in explains that check-out is for exclusive editing, while co-authoring requires leaving the document available for simultaneous editing. I recommend that you make sure versioning is turned on, so previous versions are also kept.
Choose the method that suits the work. Neither method replaces approval of the document that will actually be issued.
Make document identity and status obvious
An important project document should show enough information to identify it without relying on the email it arrived in.
Usually this includes:
- Document title and unique document number.
- Project name or number.
- Revision identifier and issue date.
- Status or purpose of issue, such as draft, for review or approved for use.
- Author, reviewer and approver, where required by the project procedure.
Use the organisation’s or client’s established conventions. Keep the information consistent between the filename, cover, headers, footers and document register.
Explain what the status means. A document issued for review should not be used as an instruction to proceed. Similarly, a newer draft should not displace the approved issue just because it is easier to find.
For templates, direct people to the controlled originals. As discussed in Easy to Find Forms and Templates, private collections can leave staff working from outdated requirements before drafting even begins.
Record what changed between issued revisions
Once a document has been formally issued, later revisions should explain what changed. “Updated” is rarely enough to help the next person understand the difference.
A useful revision entry might say: “Revised Section 4 delivery responsibilities and Table 2 inspection dates following approved change CR-014.” Record the revision, date and relevant approval reference with the document or its controlled record.
Tracked changes, comparison reports or drawing revision marks can help reviewers identify alterations. Follow the project’s requirements for what remains visible in the issued copy.
Automatic version history is useful for recovering edits, but it may contain dozens of saves that have nothing to do with formal issue. Make the approved milestones clear.
Where a revision changes scope, cost or an agreed commitment, follow the change approval process too. Updating a file does not itself authorise the underlying change. Refer to my post Document All Changes, Variations, and Agreements.
Check the complete package before release
Before issuing a document, review the actual files the recipient will receive. Checking the editable source alone is not enough if the issued PDF has missing pages or unreadable figures.
I would check that:
- All agreed comments have been addressed or resolved.
- The revision, status and approval details are correct.
- Headers, footers, page numbers and section references agree.
- Tables, charts and appendices are complete and readable.
- Related documents use consistent names, figures and requirements.
- The issue package contains every listed attachment.
For a document set, coordinate the checks across the set. A plan may refer to an inspection schedule that was revised separately. Both files can look correct while the instructions conflict.
Avoid changing an approved document while correcting an issue. If a correction is needed, return it through the appropriate check and approval process. Do not assume that every change made during formatting is harmless.
Keep a record of what was issued and to whom
For formal issues, record the document numbers, revisions, issue purpose, date and recipients. A transmittal or suitable system record can provide this information.
The record should identify the actual files sent. “Latest drawings attached” is not enough if you later need to establish whether the contractor received Revision B or Revision C.
Where appropriate, request acknowledgement of receipt and follow up if it does not arrive. An email being sent is not the same as the recipient being able to open every attachment or access a restricted link.
Keep receipt, technical acceptance and approval distinct. A contractor confirming that a package arrived has not necessarily checked or accepted its contents. Similarly, a submission to the client’s records team may still be awaiting review. Track whether it was received, queried, accepted and stored, so the project does not assume the work is complete too early.
Replace superseded copies where people work
When a new revision is issued, tell the affected users what it replaces and whether they need to take action. Saving it in the correct folder is only part of the task.
Check the places people actually use documents: site folders, printed drawing racks (rare, I know, but it still happens), downloaded laptop files and copies supplied to subcontractors.
Remove superseded copies from active use or clearly identify them as superseded. However, you should still retain the historical records required by the project; do not destroy the evidence of what was previously issued.
Where controlled paper copies are necessary, identify the holder and arrange replacement. A footer saying “uncontrolled when printed” does not physically remove an obsolete drawing from someone’s desk.
For teams working without reliable internet, agree how current offline packages will be prepared, identified and refreshed. They need usable documents on site, together with a practical way to recognise when those documents have been replaced.
Explain the process and test that it works
Include the document control arrangements in your Project Management Plan or link to a short project procedure. Explain the steps to reviewers and senior managers as well as the people doing the administration.
A simple instruction could be:
“Send comments on the inspection plan to the nominated controller. The controller will consolidate changes in the project document system and arrange technical review. The project manager authorises issue. Only the approved issue is to be used for inspections.”
Also explain who uses the document and what happens after an update. Clarify Who Uses Documents and Why covers that part of the task in more detail.
Then test the process. Ask someone to find the approved document and identify its revision. Check a recent issue against the register and a site copy. If the answers differ, fix the cause.
Keep the controls proportionate and maintain continuity
A small internal project may manage adequately with an agreed folder structure, limited editing permissions, a revision table and recorded approvals. A complex design or construction project may need formal workflows, dedicated controllers and tracked distribution.
Use the controls needed for the consequences of an error. Making routine filing unnecessarily difficult encourages people to bypass the system, which defeats the purpose.
Arrange backups and recovery through the organisation’s systems, but remember that recovering a file does not establish which revision was approved.
When responsibilities change, hand over document locations, current issues, outstanding reviews and access arrangements. Include these in the Formal Handover Meeting and associated handover documents. At completion, confirm that the required records and editable source files have reached their agreed destination and been accepted.
Lesson: Control the Changes and the Final Issue
Keep good control of formal project documents. Several people can contribute, but someone must coordinate the final production and ensure that changes come together in the correct file.
Make the approval authority clear, record revisions, and check the complete package before issuing it. Then make sure the people doing the work receive the right revision and replace superseded copies.
Do not assume that having a document management system means your documents are controlled. The team needs to understand and follow the process, including the project director who only wants a few quick changes.
A document is useful when people can find it, trust its status and use it for the intended work. That is what your document control process needs to achieve.
Hi, I just found your website… As a new PE and gaining more and more responsibility I’ve found your website very valuable as a lessons learned. I like your short posts but they are extremely informative as I can apply them to my own workspace/projects. Just wanted to say thanks, Thanks!