1 : Principles to make managing documents easier
Even if you're not a document controller, it's likely that you'll need to manage documentation on a pr
oject. Remember that poor information management is the biggest cause of project delays and cost
overruns. Understanding good practice principles will help you and everyone else on the project tea
m. It's all about getting the right information to the right people at the right time. Let's start by introduc
ing some basic principles of good document control.
In this video, we'll discuss minimum requirements. In other videos, we'll talk about why good classific
ation is important and make some suggestions for how we can make use of files outside of Aconex.
Now joking aside, there are lots of standards around managing information and documents. All of th
em tend to suggest or recommend a few common elements. Most
are common sense, but all too often project teams try and do things differently for a variety of reason
s.
Maybe they're new to using a platform like Axonex or maybe they're trying to comply with guidelines
that are out of date and don't really work with digital information. Whatever the reason, it's always be
st to keep things as simple as possible. It's better to have a simple setup that everyone uses than a c
omplex one that few people use.
So what are the common minimum requirements that most standards recommend, and how does Ac
onex deal with them? First, there's a unique ID. In Aconex, this is the document number. It's the only
field that must be unique. Remember that this should always match what's on the hard copy of the d
ocument.
Then there's subject. Most standards specify this as a way of identifying the nature of the document.
In Aconex, this is often the discipline, like mechanical, engineering, or electrical. Next is type. And thi
s is taken care of the document type field, and it would tell us if the document was a drawing, a speci
fication, a report, and so on.
Then there's originator. And this is the author or document creator. In Aconex, we have the created b
y field. And that can be renamed if required.
Finally, there's dates. And this can be interpreted in many different ways. In fact, many projects use
multiple dates to record key date-based information. For Aconex, this would typically be the revision
or modified date and would indicate the date the document was last changed. In fact, the modified d
ate in Aconex is another field that's always there and automatically updates every time the document
is updated.
In one of the lessons for the associate learning, we discuss what Aconex projects require as a minim
um. If we add in the missing recommendations we see in most standards, we end up with this. If a pr
oject only used these fields to organize these documents, it would work. We could add more fields, b
ut the more we add, the more likely the mistakes will be made.
More fields often lead to frustration for people if there's a lot of information to complete for each docu
ment that is added to a project. The key to success is finding a balance between having just enough
information for efficient classification and having too much.
