How do we deal with our documentation?  It’s probably the most mundane, controversial and opinionated part of a project, but possibly the most essential part of a project and, more often than not, the most delegated.  However, documentation is an essential part of communication.  Communication, or rather ‘information logistics’, is the art of ensuring that information is in the right place, at the right time, with the right people, and in the right medium.  Information also needs to be stored and now this is can be in the cloud, on a remote server, on disc etc etc…etc.  We tend to be rely on the computer to do this menial work and also rely on information technology to ensure we can retrieve this information rather than the old fashioned ‘filing system’.

When did the ‘filing system’ become an ‘electronic database management system’?

This evolution took away the ‘push’ of data to people through a manual distribution system to a ‘pull’ system in which people can or cannot ignore an email or electronic notification.  It’s difficult to ignore a full in-tray; or are people today more efficient and handle information overload better than they used to and can they multi-task, be involved in everything, and even do their own work as well?

In this day of IT solutions for everything and information at the push of a button or a tap on the screen use are we being fooled when we think this can be applied directly to projects?

Some time ago I was asked to review a “Document Management Plan” for contractual correspondence.  As an end user what I need to know is “what is the subject’, “where is it kept”, “when was it received / sent” and “who is taking care of it”.  I immediately recalled a Government system I had used that utilized a relatively simple and, after a while, memorable numbering system, that could address every subject for an engineering design or construction project utilizing 3 pairs of digits and a unique sequential number.

However, to my horror, and shattering any delusions of simplicity and practicality, I discovered that there were seven fields and a 23 character alphanumeric code.  With such a level of detail retrieval should be easy, I thought, or rather expected somewhat stupidly.  Unfortunately upon close inspection this complicated code just identified sender, recipient, contract title and a sequential number and that the document in question would be a letter. The code also advised as to the generic discipline, but in our multidisciplinary team in multiple locations the code reference was, quite literally, a waste of space.  But the ‘code’ was incorporated on the top of every letter filling up space and sparking another debate as to the font size because it took up too much space.

But why do we, as humans, need this complicated reference?  We don’t.  A person can quickly assimilate that the piece of paper is a letter, who the receiving and sending parties are, and its subject in an extremely short space of time.  But, the computer, being a very hard working idiot, needs to be told everything, and every time.  What we do need is a retrieval system and this is where there is a rift between how a digital system works and human sense.

So why do we fool ourselves that this “code” is of any use.  Only the sequential number is of any use as it is unique but it tells us nothing about the letter; we need a subject reference.  Unfortunately this means that the Project Manager, or similar, must allocate a file reference as opposed to classifying the document for the computer to know what to do with it”.  The Project Manager may then have to assign an actionee rather than depend on the generic and decision-free distribution list.  Distribution to “all users” may give the impression of efficiency but is it effective?  Is it nice for everybody to know or is better to have a ‘need to know’ which focuses the project team’s efforts and prevents the human habit of interfering in other people’s business and possibly adding to any confusion or inefficiency within the project.

It must be a management responsibility to ensure that correspondence is classified by subject or discipline or area of work.  For the PMPs (Project Management Proponents) amongst us, WBS (work breakdown structure) could be the start of a filing/retrieval system and can lend itself very nicely to a DBS (document breakdown structure).  With a few simple modifications this easily becomes a ‘filing system’ and, hey presto, we have some semblance of order and structure to our documentation if the management will is there.  After all it was fairly common and rigorous in BC times i.e Before Computer.

Maybe files and filing systems aren’t really needed and the Electronic Systems of the world are what they are held out to be and can contribute to the successful delivery of a project.  However, one of the main reasons for projects ‘failing’ or not being as successful as they could be has been cited as a lack of communication.  As I said earlier ‘information logistics’ requires the right information, in the right place, at the right time, and in the right format, and (most importantly) to the right people.  We should really ask the question “are Electronic Filing Systems really what they are held out to be?”

In a not too far gone time, and perhaps somewhat politically incorrect time, when filing was done manually and without computers or spreadsheets an engineer once wrote “filing should be simple unless one has a particularly dim office staff’…unfortunately with a computer being defined by some as a hard-working idiot perhaps this is the case?

Bio:

MBA, MSc DIC, BSc; Chartered Engineer, Chartered Geologist, PMP

Over thirty years’ experience on large multidisciplinary infrastructure projects including rail, metro systems, airports, roads, marine works and reclamation, hydropower, tunnels and underground excavations.

Project management; design & construction management; and contract administrative in all project phases from feasibility, planning & design, procurement, implementation, execution and completion on Engineer’s Design and Design & Build schemes.