TL;DR
Your assumption that you need to track changes across multiple revisions is limiting your scope of change control options. So is your use of the Microsoft Word format. I'd reconsider both unless you can:
- ensure you have a single document owner, and
- track textual changes independently of your change-control approval process.
However, if you can't change either your assumptions or your tool-chain, I've included some suggestions about submitting changes through a centralized document owner and implementing revision tracking that might prove helpful. Your mileage may vary.
Types of Document Artifacts
Living Documents vs. Baseline Documents
A living document changes as a project progresses. For example, a specification document may get updates when feature foo is replaced with feature bar, or when feature baz is modified in some way. This type of living document may have sign-offs or approvals, but isn't intended to be compared to legacy versions of itself and is therefore relatively easy to maintain.
A baseline document is an historical artifact. You might create a baseline specification at the start of a project, and then create new specification documents at need during the life of the project. All such documents are kept as artifacts of the project, but need not be revisions or even directly comparable. They are simply snapshots of the project's specifications at given points in time.
Bastardized Documents
I'm deliberately using the term bastardized documents instead of "hybrid" or "shared-editing" because the need for complex change tracking is generally a result of ad-hoc editing. For example, if you route a document around to 37 people, all of whom are free to make revisions directly to the document, those changes need to be merged, conflicts resolved, and some sort of traceability for the changes needs to be implemented.
Assign Document Ownership to Preserve Sanity
Free-for-all changes are generally just a Bad Idea™. I'd strongly suggest a simpler approach where:
- Documents have a single owner.
- Documents are line-numbered.
- People can submit requests for changes, referencing line numbers as needed, to the document owner.
- The document owner makes changes and submits them to the approval body at need.
- If required, the change requests can be kept as historical artifacts.
Again, this is largely independent of the issue of change tracking within the document itself. However, actual revision control systems (think SVN or Git) can serve some of the same purposes and track the full history of textual revisions, too. More on that below.
The Value of Tracking Historical Versions
Whether there is actually any value in this is really a political question. From a practical standpoint, what the specifications used to be is less useful than what the product/feature needs to do now.
Version (or revision) tracking is really an independent issue from change control. For change control, you need to be able to define the changes (and perhaps the associated business cases) and get appropriate approvals for the new to-be specifications. If the changes are subtle, it's sometimes useful to see the as-is and to-be versions side-by-side so that the differences are more obvious, but the central feature of change control is that you're authorizing changes, rather than tracking historical versions.
With that in mind, you only need to track the most recently-approved version and the new (currently unapproved) version. This violates your assumptions as outlined in the original question, but may be worth considering.
Tracking Historical Revisions Separately from Change Control
How you do this is largely dependent on your technical implementation of process. If you must stick with MS Word, you might consider:
- Always keeping change tracking on.
- Add hidden notes attributing specific changes to people, meetings, or milestones that aren't captured by change tracking.
- Hide the changes/notes unless you're doing some sort of document archeology.
This works up to a point, but gets messy and confusing fairly quickly. If you use a more flexible format such as OpenOffice or Markdown, or even just a utility to dump text from Word to ASCII at need, you can store textual revisions in a source control system like Git. Personally, I often use Markdown or AsciiDoc as the native document format so that I can store textual revisions in Git, and use Pandoc to pretty-print the documents in PDF, HTML, or Word format when needed.
This separates the complexity of revision control from the process of change control. It allows one to go spelunking in the revision history for side-by-side comparisons of any arbitrary pair of revisions, as well as the inclusion of notes and explanations in the history itself (e.g. Git logs or Git notes).
Example of Document-Owner Model with Revision Control
As an example of the document-owner model coupled with a text-based source format and a revision control system, consider the following. If Bob is the document owner, and Alice isn't savvy enough to edit Markdown or commit changes to Git herself, then Alice might submit a document change request to Bob saying:
Please change line 17 to say "embiggen the widget" instead of "minify the monolith."
and Bob can make the changes, attributing them to Alice, and submit the new document through the change control process for approval.
Word-Processor Based Options
Your mileage will vary a lot of you don't use a text-based native format, or don't use a revision control system. However, similar things can be done (albeit in a more limited way) with Word and LibreOffice documents, each of which supports various types of change tracking, document versioning, and version comparison.
If these features serve your needs, great! If not, at least you now have a few alternatives to your process or tool-chain that you can consider.