The Problem That Only Shows Up When You Need Something

Good documentation doesn’t get much attention when it’s working. Engineers find what they need, production teams work from the correct revision, and changes get made to the right file. The documentation infrastructure is invisible precisely because it is functioning as it should. The moment it stops functioning, it becomes very visible indeed.

Nobody can find the current version of a drawing. A change gets made to the wrong revision because two versions of the same part exist in different folders with nothing to indicate which one is current. The production team is working from a file that was superseded three months ago and nobody told them. These are not dramatic failures – they are the ordinary consequences of documentation that has been allowed to drift from a manageable state into an unmanageable one. And in a manufacturing environment, ordinary consequences have real costs.

What We Found When We Arrived

The client on this project was a manufacturer who needed complete technical documentation for a profile bending machine – assembly drawings, part drawings, and a bill of materials – all developed in Autodesk Inventor and properly managed through Vault. The machine existed. The engineering work had been done. What hadn’t been done was maintaining the documentation in a state that made it usable for the people who needed to work with it.

The file structure had grown organically over time. That phrase – grown organically – is a polite way of describing what happens when documentation is treated as a byproduct of the engineering work rather than as a deliverable in its own right. New files get added as they are needed. Folders accumulate without a clear logic. When something changes, the old version sometimes gets archived properly and sometimes just gets left where it was with a new version created alongside it. References between parts and assemblies that were correct when they were created become incorrect when files are moved or renamed. Over enough time and enough changes, the structure reflects the history of the project rather than the current state of the design.

What this project had was broken references throughout the assembly structure, inconsistent naming conventions that made it impossible to understand what a file contained from its name alone, multiple versions of the same parts sitting in different locations with nothing definitive to indicate which represented the current approved design, and a Vault database that had not been kept in sync with the actual state of the files. The documentation existed. It just wasn’t usable in the state it was in.

What the Work Actually Involved

Rebuilding documentation in this state is methodical work. It requires going through the file structure systematically, understanding what each file is and how it relates to the others, resolving broken references one by one, and making decisions about which version of a duplicated part is current and what happens to the others. None of this is technically complex in isolation. The difficulty is the scale and the interdependency – a change made to resolve one reference can break another, and understanding the full dependency structure of a large assembly before making changes requires careful analysis.

The first step was establishing what the current design actually was – identifying the assembly structure, mapping the relationships between components, and determining which files represented the approved current state of each part and assembly. This involved working through the existing Vault database, cross-referencing against the physical machine and any available engineering records, and making documented decisions about how conflicts between versions were resolved.

With the current state established, the file structure was rebuilt to a consistent logic – a folder hierarchy that reflected the assembly structure of the machine, with naming conventions applied consistently across all files so that the name of a file conveyed meaningful information about its content, revision status, and position in the assembly. References were resolved within the new structure and verified. The Vault database was updated to reflect the rebuilt structure accurately, with revision history preserved where it existed and documented where it had to be reconstructed.

The output was a complete documentation package – assembly drawings, part drawings, and a structured BOM – that matched the current state of the machine and was organised in a way that the production and maintenance teams could navigate without needing to call the engineering department to interpret it. Drawing formats were standardised, revision blocks were completed, and the Vault workflow was configured so that future changes would be managed through a consistent process rather than accumulating in the same way the previous documentation had.

Why This Kind of Work Gets Deferred

Documentation cleanup is consistently deprioritised in manufacturing engineering environments, and the reasons are understandable. It produces no new engineering output. It doesn’t advance the development of a new product or resolve a technical problem that is blocking production. From a resource allocation perspective, it competes with work that has more visible immediate value and usually loses.

The problem with that logic is that the cost of deferred documentation work doesn’t disappear – it accumulates and gets paid in a different form. Every engineer who spends time searching for the correct version of a drawing rather than finding it immediately is paying part of that cost. Every production error that traces back to work being done from a superseded revision is paying part of it. Every handover between teams that takes longer than it should because the documentation doesn’t clearly reflect what was actually built is paying part of it.

These costs are diffuse and chronic rather than acute and visible, which is why they tend not to trigger the same response as a dramatic production failure. But they are real, they compound over time, and they are entirely avoidable with documentation that is maintained properly from the beginning – or restored to a usable state when it has drifted from one.

The Quiet Determinant of Handover Quality

Documentation work is not glamorous. It doesn’t involve solving novel technical problems or developing new engineering capabilities. What it does is determine whether the engineering knowledge embedded in a design is accessible to the people who need to work with it – in production, in maintenance, in future engineering projects that build on the current one.

A profile bending machine with clean, complete, properly managed documentation takes two days to hand over to production. The same machine with documentation in the state this project started in takes two weeks – and generates a stream of queries and clarifications throughout the production process that consumes engineering time that should be allocated to the next project. The machine is identical. The documentation is not.

If your CAD documentation has reached a state where finding the current version of something requires institutional knowledge rather than just knowing where to look, the right time to address it is before the next handover – not during it.