The Institution of Structural Engineers The Institution of Structural Engineers
Back to Previous

Organising project data

Date published

This overview offers ways to deal with the complexities of information systems in large and small practices.

The ability to scale the management of data, to better categorise, find and share data across departments, disciplines and teams is becoming essential in modern design environments. There are many ways to manage data and some are better than others.

File names

The technical limitations (what is and is not allowed in a file name) of different operating systems relies on their chosen method of storing data. This does not mean the physical hardware, but rather a filesystem, such as FAT32, NTFS, exFAT, etc.

Each of these systems has different limitations on file names, for instance some may differentiate between upper and lower case letters, others may not. Each operating system will have detailed documentation explaining which characters are permitted.

Aside from the technical limitations on file naming, there are ways to name files to enable easy manipulation of data. It would be advisable to ensure file naming is compliant with the local National Annex to ISO 196502:2018. For the United Kingdom, for example, this would be UK National Annex to BS EN ISO 1965-2:2018. This would result in the following naming convention – details of which can be found in the relevant standard:

  • ProjectRef-Originator-Volume-Level-DocumentType-Discipline-Number-Revision-Suitability_Description_Date_Author.FileExtension

However, even if the relevant standard is not followed rigorously (as may be the case where interaction with other disciplines is minimal, the client or design team requires otherwise, or name limits are encountered) the file name should at the very least contain the following elements:

  • Date-Name-Version-Author.FileExtension

A useful format for dates is reverse size order (YYMMDD) which means folders ordered by name will always be listed in ascending or descending chronological order.

You’ll note two important aspects of the convention above: 

  1. Underscores and hyphens (Unicode ‘Hyphen-Minus’) are both used in different places to separate items of information. Hyphens are specified in ISO 19650, while information separated by underscores is useful but not specified by the standard. 
  2. There are no spaces between any of the information categories. This is presumably a conscious decision by the writers of ISO 19650, as often during file operations (copying, renaming, creation etc) spaces can cause errors in poorly checked scripts. It can be argued that this would be a good convention to follow regardless of task or if ISO 19650 applies in order to make working with files generally less time consuming and tedious. 

Ideally, a changelog (as described below) should also be provided to allow tracking of changes when the software itself does not have this capability.

Sensible folder structures

It is better to reduce the number of folders in a folder structure to around three or four levels at most. The most pertinent technical reason is because of file name lengths which can cause errors indicating that the file name has exceeded the allowed limit. This is most often related to the folder structure rather than the file itself and is more common in older versions of operating systems. Modern operating systems have generally increased the file name limit such that this is less of an issue than it once may have been.


In software development, versioning and collaborative working is usually based on a framework called ‘Git’. Files are downloaded locally, modified before being ‘staged’ and then ‘committed’ back to the server they originated from.

The system allows for branching of different versions with different code bases and is completely auditable – with the ability to revert changes within a branch. ‘Commits’ are required to have descriptive names in order to prevent the problems often encountered when a strict naming convention is not enforced, ie a folder full of ‘file_update 1’ file_update 2, ‘file_new version(2)’, etc.

While there are projects currently attempting to implement such a system for structural models, drawings, etc. they are not yet mature enough for everyday use.

Whilst these systems are being developed, engineers should try to maintain a sensible structure for versioning, facilitated by naming structures as described previously to permit easy differentiation between versions.

Common version number suffixes include P (Preliminary), T (Tender), C (Construction), and are incremented numerically. P1 being the first preliminary issue of a document, P2 being the second, P3 the third and so on. Some may choose to start at P0. 

Version number and suffixes should not be easily confused, and generally should be explained via some consistent documentation. For example, the use of the suffix P may mean ‘Preliminary’ to some professions, ‘Production’ to others, and thus the suffix P1 may be unintentionally ambiguous when working collaboratively. 


A changelog is a file (usually plain text) that details the changes in a particular version of a file or program. They are often hosted on websites for downloadable software or as a text file / message when installing an update to a program.

Changelogs include details of the latest software alteration, appended to the list of previous amendments allowing alterations to be tracked through versions of a model, effectively acting as a revision table for the file.

Structural models may be changed significantly between revisions, and it is good practice to note what these changes are, why they have occurred and who has made them.

Even if a single person is working on a particular model, changes can often be forgotten, resulting in potentially inaccurate results. This is especially true for cases where a single person has worked on a model for a significant amount of time.

It may not be practical to note down every single change between versions in exacting detail. If 50 nodes have been moved by a fraction of a distance, there is seldom significant change in the model or the outputs.

However, if a loading condition has changed, a load combination, members or releases removed or added, etc., these should be noted in a changelog to allow easy interrogation of results or comparison between different options within a structural scheme.

The scheme for a changelog should be consistent, an example of such a changelog is given below: 

  • 2020-02-29 Major update to geometry following issue of architectural set of drawings (dated 20200226). Many changes. Refer to markups designated (20200229_JobNo_Markups-for-structural-model) for details of geometry alterations and member removals / required additions. 
  • 2020-03-01 Minor changes to model loads to include increased snow load from extended canopy. Analysis results recalculated, no significant change in forces/moments. 
  • 2020-03-01 Incorporated changes from latest set of architectural drawings (set received 20200229). Geometry fixes; gridlines L and G adjusted to suit new drawings and nodes adjusted to suit. Cantilever on grid F, 1-3, lengthened from 1000 to 1500 and redesigned. 

It is clear from each of these dates what part of the model has changed. In the case where there are large numbers of changes to the model, there is reference to a set of scanned in markups that is included with the model file. 

Related Resources & Events

A image of a person holding a digital pen sketching on a Pad device.

Digital in discussion: do digital design tools compromise creativity?

An expert panel discusses whether structural engineers should fully embrace automated design tools, or if it compromises creativity and expertise.

Date – 8 July 2024
Author – Various
Price – Free
A construction site revealing a concrete structure and scaffolding against bright sun is shown.

Analysis and strengthening of concrete buildings 1950 - 1985

Exploring concrete buildings from 1950-1985, this series provides insights on reuse project challenges, cost-effective surveys and investigations, corrosion and fire management, historical building modelling, and the sustainable application of carbon fibre reinforced polymers for their strengthening

Date – 2 May 2024
Author – Various
Price – £180 - 280 + VAT
Rear view of male architect photographing construction site through digital tablet

Building modelling

This webinar examines historical building modelling methods and how to utilise modern computer-aided analysis to assess the structural behaviour of existing concrete buildings.

Date – 12 March 2024
Author – Tony Jones and Sebastian Kaminski
Price – £45 - £70 + VAT