Certificate in Software Project Management
Project Documentation & Control
•
Certificate
Document, Version, and Records Control
Introduction
Software projects generate a large body of information: requirements, designs, source-code explanations, test evidence, contracts, meeting decisions, risk logs, user manuals, release notes, security records, and operational instructions. These materials are not merely administrative outputs. They provide evidence of what was agreed, what was built, who authorized it, and how the product should be operated and maintained.
Document, version, and records control is the disciplined management of information throughout its life cycle. It ensures that people use the correct information, that changes are authorized and traceable, that sensitive material is protected, and that records remain available for the period required by organizational, contractual, legal, or regulatory obligations.
Poor control creates practical risks. A developer may implement an obsolete requirement; a tester may use an outdated acceptance criterion; a customer may receive an unapproved manual; or an organization may be unable to demonstrate compliance after an incident. Effective control reduces these risks without creating unnecessary bureaucracy.
Learning Objectives
By the end of this chapter, you should be able to:
distinguish documents, controlled documents, records, and informal working material;
describe the document life cycle from drafting to secure disposal;
design review, approval, distribution, access, versioning, storage, and retrieval controls;
apply a practical naming and version-identification scheme;
explain the relationship between configuration management and document control;
select suitable controls for confidential, personal, contractual, and regulated information;
identify weaknesses in a document-control process and recommend improvements.
1. Fundamental Concepts
Documents, information, and records
A document is recorded information and its supporting medium. In a software project, a document may be electronic or physical and may contain text, diagrams, tables, code snippets, signatures, or embedded evidence.
A controlled document is a document for which the organization has defined requirements concerning identification, review, approval, change, distribution, access, and retention. Examples include an approved requirements specification, test strategy, deployment procedure, or information-security policy.
A record is evidence of an activity, decision, transaction, result, or obligation. A signed approval, completed test report, audit trail, meeting decision, release authorization, or incident report is normally a record. A record is not simply a document that is old. Its defining characteristic is evidential value.
A working draft can be edited freely by authorized contributors. An approved document has a defined status and must be changed through an established process. A record should normally be protected from unauthorized alteration; corrections should be made through an auditable amendment or annotation rather than by silently replacing the original.
Document control and configuration management
Document control focuses on recorded information. Configuration management is broader: it identifies and controls the configuration of a product and its components, including source code, infrastructure definitions, build scripts, test assets, documents, and baselines. Document control is therefore one important part of configuration management.
A project should identify which information items are configuration items. The decision should consider the item's effect on quality, safety, security, contractual obligations, operational continuity, and the ability to reproduce a release. Not every informal note requires formal control, but any item used to make, verify, operate, or govern the product may require it.
The control principle
A useful control principle is: the more important the information, the stronger the evidence and restriction required to change it. A brainstorming note may require only a date and author. An approved security architecture may require named reviewers, segregation of duties, electronic approval, access restrictions, retention rules, and a complete change history.
Controls must be proportionate. Excessive approval layers can delay delivery and encourage people to bypass the system. Insufficient control can produce unauthorized change and unreliable evidence. The project manager should establish a risk-based balance.
2. The Document Life Cycle
A document life cycle describes the stages through which controlled information passes. Organizations may use different names, but the underlying logic is similar.
Document life cycle from drafting through review, approval, distribution, storage, archival, and disposal
Figure: Document life cycle from drafting through review, approval, distribution, storage, archival, and disposal
Figure: A controlled document life cycle. Maintenance may lead to a new draft, while retention decisions lead to archival or secure disposal.
2.1 Identification and planning
Before drafting begins, the project should determine the document's purpose, owner, intended audience, security classification, required format, review frequency, and retention requirement. A document register can record:
Field
Typical content
Identifier
Unique document code
Title and type
Requirements specification, test report, procedure
Owner
Person accountable for accuracy and maintenance
Status
Draft, under review, approved, superseded, archived
Version
Current revision identifier
Classification
Public, internal, confidential, restricted
Approvers
Roles or named authorities
Retention
Required preservation period and trigger
Repository
Authoritative storage location
The owner is accountable for content, but ownership does not necessarily mean the owner performs every edit or approval. Separating preparation, review, and approval reduces the risk that an individual authorizes their own unverified work.
2.2 Drafting
Drafting should use an approved template where consistency matters. A template may include document identifier, title, version, author, date, status, change history, approval section, page numbering, and classification marking. Templates should not become substitutes for thinking: the content must fit the decision or deliverable being documented.
The working file should be stored in a controlled workspace rather than circulated through uncontrolled email attachments. Editors should record significant decisions and link requirements, risks, defects, or change requests where traceability is needed.
2.3 Review
Review confirms that the document is correct, complete, understandable, consistent with related information, and suitable for its intended use. Review types may include:
peer review, which examines technical quality;
stakeholder review, which checks business or user suitability;
compliance review, which checks contractual, legal, security, or regulatory requirements;
editorial review, which improves clarity and consistency.
A review should define scope, participants, entry criteria, comments, decisions, action owners, and closure evidence. Reviewers should identify whether a comment is a correction, clarification, recommendation, or approval condition. The author resolves comments, while an appropriate reviewer confirms that significant issues have been addressed.
2.4 Approval and baseline
Approval is an explicit authorization to use a document for its stated purpose. It may be recorded through an electronic workflow, a reliable digital signature, or a controlled approval record. Merely placing a file in a shared folder does not demonstrate approval.
A baseline is an approved, identified version that serves as a reference point. Changes to a baseline must follow change control. Baselines support reliable comparisons, release reproducibility, and investigation of later disputes or defects.
Approval authority should match impact. A minor editorial correction may require the document owner and a peer reviewer. A change affecting contractual scope, safety, privacy, security, or production operation may require customer, product, security, or change-control-board approval.
2.5 Distribution and access
Distribution means making the correct approved information available to the correct audience. The repository should be authoritative: users should know where the current approved version resides and should not rely on copies saved in personal folders.
Access control should follow least privilege, meaning a user receives only the access necessary for their role. Common permissions include read, comment, edit, approve, administer, download, and delete. These should not automatically be combined. For example, an external reviewer may comment but not approve or delete.
Access should be reviewed periodically and removed when a person changes role or leaves the project. Sensitive documents may require multifactor authentication, encryption, download restrictions, watermarking, or restrictions on external sharing. Permissions should be applied to groups where possible, because group management is usually more reliable than maintaining many individual exceptions.
2.6 Versioning and change history
Version control answers three questions: Which version is this? What changed? Who authorized the change?
A practical scheme distinguishes major and minor changes. For example, version 2.0 may indicate a significant approved change to scope or structure, while version 2.1 may indicate a smaller approved revision. The exact convention is less important than consistent rules. A version number should not be increased merely because a file was opened, and an approved document should not be edited in place without updating its history.
A change history should state the version, date, author, summary of change, reason or change-request reference, and approval status. File names should contain a stable identifier and, where useful, the version and status; however, the repository metadata and workflow remain the authoritative controls.
A superseded document should be marked clearly and prevented from accidental operational use. It may remain accessible for traceability, but it should not appear as the current version in ordinary search results.
2.7 Storage and retrieval
Storage must protect confidentiality, integrity, and availability. A suitable repository should provide authentication, authorization, audit logging, backup, search, metadata, retention support, and recovery procedures. Storage location should be appropriate to the information classification and contractual obligations.
Retrieval is a control objective, not merely a convenience. A record that exists but cannot be found in time may be operationally equivalent to a missing record. Searchable metadata should include document type, project, owner, status, version, date, classification, and related release or change request.
Backups are not identical to records management. A backup supports recovery from system failure; a retention repository preserves information for evidential or business purposes. Backups should themselves be protected and tested through restoration exercises.
2.8 Archival, retention, and disposal
When a document is no longer active, it may be archived if it has continuing legal, contractual, historical, operational, or evidential value. Archived information should remain identifiable, readable, protected from unauthorized modification, and retrievable for the retention period.
Retention should be based on organizational policy and applicable obligations. It should specify the retention duration, the event that starts the period, the responsible owner, and any legal hold process. A legal hold suspends normal disposal when information may be relevant to litigation, investigation, audit, or regulatory action.
Secure disposal must be authorized and appropriate to the medium. Electronic files may require controlled deletion, cryptographic erasure, or destruction of storage media; paper records may require cross-cut shredding or an approved destruction service. Disposal evidence should identify what was destroyed, when, under whose authority, and by which method. Deleting a file from a visible folder does not necessarily remove copies from backups, synchronization services, recycle bins, or exports.
3. Governance and Control Design
A document-control procedure should assign responsibilities clearly. The project manager establishes the process and monitors compliance. The document owner maintains content. Authors prepare changes. Reviewers provide independent examination. Approvers authorize use. The repository administrator maintains technical controls. Records or compliance personnel advise on retention, legal holds, and disposal.
A simple responsibility matrix can prevent gaps:
Activity
Owner
Author
Reviewer
Approver
Define content
Accountable
Responsible
Consulted
Informed
Prepare draft
Accountable
Responsible
Consulted
Informed
Conduct review
Accountable
Supports
Responsible
Informed
Authorize release
Consulted
Informed
Consulted
Responsible
Maintain current version
Responsible
Supports
Consulted
Informed
Governance should also define exceptions. Emergency changes may need accelerated approval, but they should still be logged, risk-assessed, retrospectively reviewed, and incorporated into the normal baseline. “Urgent” should not become a permanent route around control.
Useful control indicators include the proportion of controlled documents with current owners, overdue reviews, unauthorized access events, unresolved review comments, retrieval time for sampled records, and the number of releases using superseded documents. Metrics should support improvement rather than encourage superficial compliance.
4. Applied Case: The Atlas Payroll Release
The following is an illustrative case.
Background
Atlas Software was developing a cloud payroll service for a regional employer. The project maintained requirements, an interface specification, data-protection assessment, test evidence, deployment runbook, and user instructions. Documents were stored in a collaboration platform, but teams also exchanged attachments through email.
Problem
During user acceptance testing, the test team used an older interface specification. A field marked optional in that version had become mandatory in the approved requirements. The resulting test failures delayed the release. In addition, a former contractor retained access to a folder containing employee-data samples, and the project could not quickly locate the approval record for the deployment runbook.
Analysis
The project had no authoritative document register, inconsistent file names, and no enforced distinction between draft and approved status. The collaboration platform permitted broad editing rights. Review comments were recorded in email, and the retention period for test evidence had not been defined. The problem was therefore systemic rather than the fault of one tester.
Approach and solution
The project manager introduced the following controls:
Each controlled item received a unique identifier, owner, classification, status, and repository location.
Approved documents were stored in a read-only baseline area; drafts remained in a separate working area.
A review workflow required technical, business, and security review where applicable.
Major and minor version rules were documented, and every change referenced a change request.
Distribution links pointed to the authoritative version rather than email attachments.
Access was assigned through project groups and reviewed at each release milestone.
A retention schedule was agreed with the customer, and legal-hold and disposal procedures were documented.
A release-readiness check required confirmation that test teams had the current requirements and that deployment evidence was approved.
Outcome
The next release used a verified baseline. The former contractor's access was removed, and the data samples were moved to a restricted location. The deployment approval was retrieved during an audit in minutes rather than days. The project also discovered that document ownership needed to continue after delivery, so operational owners were assigned before handover.
Learning points
The case demonstrates that document control is part of delivery quality, security, and operational governance. Version numbers alone would not have solved the problem. The project needed authoritative storage, status control, access management, traceability, and accountable ownership working together.
5. Challenges, Limitations, and Contemporary Practice
Collaboration and remote work
Cloud collaboration makes simultaneous editing and distributed review easier, but it can create duplicate copies, uncontrolled downloads, and uncertainty about the authoritative version. Teams should define which platform is authoritative, how offline copies are handled, and how external sharing is approved.
Automation and artificial intelligence
Workflow automation can assign reviews, detect missing metadata, notify owners of overdue reviews, and prevent release of unapproved documents. AI tools may assist with classification, duplicate detection, summarization, or comparison of versions. However, AI-generated summaries can omit qualifications or misinterpret requirements. Human owners remain responsible for accuracy, confidentiality, approval, and the decision to retain or dispose of information. Sensitive project data should not be entered into an AI service unless its security, contractual terms, retention behavior, and permitted use have been assessed.
Integrity and authenticity
A document's appearance is not sufficient evidence of authenticity. Stronger evidence may include authenticated approval workflows, immutable audit logs, cryptographic hashes, digital signatures, and controlled timestamps. These controls are valuable when records may be challenged or when release reproducibility is important. They also introduce costs and require key management, access governance, and recovery planning.
Human factors
Users often bypass controls when repositories are slow, search is poor, or approval responsibilities are unclear. Good design therefore combines policy with usability: simple templates, meaningful metadata, fast search, clear status labels, automated reminders, and training based on realistic project tasks. Periodic audits should examine how work is actually performed, not only whether a procedure exists.
Best-Practice Checklist
Before declaring a document-control process effective, confirm that:
every controlled item has an owner and unique identifier;
status, version, classification, and approval state are visible;
review evidence and change history are retained;
the authoritative copy is clear;
access follows least privilege and is periodically reviewed;
superseded versions cannot be mistaken for current ones;
backups, retention, legal holds, archival, and disposal are addressed;
emergency changes receive retrospective review;
the process is usable and proportionate to risk;
records can be retrieved and their authenticity demonstrated.
Chapter Summary
Document, version, and records control manages information from identification and drafting through review, approval, distribution, maintenance, archival, and secure disposal. Controlled documents require clear ownership, status, version identification, review evidence, approval authority, and an authoritative repository. Records preserve evidence and should not be silently altered.
Version control and baselines enable teams to know what information was approved at a particular time. Access control protects confidentiality and integrity through least privilege, authentication, segregation of duties, and periodic access review. Storage and retrieval controls ensure that information remains available and usable. Retention schedules, legal holds, archival safeguards, and secure disposal complete the life cycle.
Effective control is risk-based. It combines governance, technical safeguards, usable workflows, and human accountability. Automation and AI can assist administration, but they do not remove the need for responsible ownership and human approval.
Key Terms
Document: Recorded information and its supporting medium.
Controlled document: Information managed through defined identification, review, approval, change, and distribution controls.
Record: Evidence of an activity, decision, transaction, result, or obligation.
Document owner: Person accountable for a document's accuracy and maintenance.
Authoritative copy: The approved source regarded as the official version.
Baseline: An approved and identified reference version.
Version: An identifier distinguishing one state of a document from another.
Change history: A record of revisions, reasons, authors, dates, and approvals.
Superseded document: A former version replaced by a newer approved version.
Repository: A managed location for storing and retrieving information.
Least privilege: Giving users only the access necessary for their responsibilities.
Access review: Periodic examination of whether permissions remain appropriate.
Retention: Required preservation of information for a defined period or purpose.
Legal hold: Suspension of normal disposal because information may be required for an investigation or legal matter.
Archival: Protected preservation of inactive information with continuing value.
Secure disposal: Authorized destruction or erasure that prevents practical reconstruction or unauthorized recovery.
Configuration management: Identification and control of product components and their approved states.
Audit trail: Chronological evidence of actions, changes, or approvals.
Review Questions
Short Answer Questions
What distinguishes a record from an ordinary working document?
Why should a project maintain an authoritative repository?
What is the purpose of a baseline?
Explain the principle of least privilege.
Why are backups not equivalent to records retention?
Long Answer Questions
Describe the complete life cycle of a controlled document and explain the control objective at each stage.
Compare document control with configuration management in a software project.
Explain how review, approval, and segregation of duties reduce project risk.
Discuss the requirements for effective retention, archival, and secure disposal.
Evaluate the benefits and risks of using automated or AI-supported document-control tools.
Analytical / Application Questions
A project has three files named “Requirements-final,” “Requirements-final2,” and “Requirements-approved.” Design a practical control scheme that would eliminate ambiguity and preserve traceability.
An external tester needs to comment on a confidential test plan but must not download, edit, approve, or share it. Specify the access and workflow controls you would recommend.
During an emergency production change, the normal approval group is unavailable. Propose a controlled emergency process that preserves speed while maintaining accountability and retrospective evidence.
Multiple Choice Questions with Answers
Question 1
Which characteristic most clearly distinguishes a record from a working document?
A. It is always stored on paper.
B. It provides evidence of an activity, decision, result, or obligation.
C. It can never be revised.
D. It must be longer than one page.
Correct Answer: B. It provides evidence of an activity, decision, result, or obligation.
Question 2
What is the primary purpose of a document baseline?
A. To permit unrestricted editing
B. To identify an approved reference version
C. To delete all earlier documents
D. To replace access controls
Correct Answer: B. To identify an approved reference version
Question 3
Which practice best supports use of the authoritative document version?
A. Distributing attachments through many email threads
B. Allowing all users to rename files freely
C. Linking users to a controlled repository copy
D. Removing version identifiers
Correct Answer: C. Linking users to a controlled repository copy
Question 4
Least privilege means that a user should receive:
A. Administrative access to every project folder
B. Only the access necessary for assigned responsibilities
C. Access equal to the project manager
D. Permanent access after leaving the project
Correct Answer: B. Only the access necessary for assigned responsibilities
Question 5
Which activity is most appropriate during a document review?
A. Silently deleting disputed requirements
B. Recording comments, decisions, owners, and closure evidence
C. Approving the document without reading it
D. Changing the document status without authorization
Correct Answer: B. Recording comments, decisions, owners, and closure evidence
Question 6
What should normally happen to a superseded document?
A. It should be presented as the current version.
B. It should be clearly marked and retained when traceability requires it.
C. It should always be destroyed immediately.
D. It should lose its owner and classification.
Correct Answer: B. It should be clearly marked and retained when traceability requires it.
Question 7
A legal hold primarily requires an organization to:
A. Suspend normal disposal of potentially relevant information
B. Delete all project backups
C. Allow unrestricted access to records
D. Convert every document to paper
Correct Answer: A. Suspend normal disposal of potentially relevant information
Question 8
Which statement about backups is correct?
A. Backups automatically satisfy every retention obligation.
B. Backups are primarily for recovery and are not necessarily a records repository.
C. Backups never require access protection.
D. Backups eliminate the need for archival planning.
Correct Answer: B. Backups are primarily for recovery and are not necessarily a records repository.
Question 9
Who is normally accountable for maintaining the accuracy of a controlled document?
A. The document owner
B. Any person who downloads it
C. The external customer only
D. The storage device manufacturer
Correct Answer: A. The document owner
Question 10
Why should emergency document or configuration changes receive retrospective review?
A. To conceal that an emergency occurred
B. To restore accountability, traceability, and baseline integrity
C. To avoid recording the change
D. To remove the need for future approvals
Correct Answer: B. To restore accountability, traceability, and baseline integrity