When it comes to Document Control, don’t re-invent the wheel

My last blog addressed the question of where Document Control should ideally report to. I suggested that if you know what it is then you’ll know where it belongs. I also wore a Rabbit suit as an Easter fashion statement but I still got some serious feedback.

The blog before that one addressed a tired old cliché regarding Rocket Science and whether Document Control is or not. I said it’s not and neither is building a bridge but there is a science to doing either properly. I could add that neither is designing an emergency shutdown system or blow out prevention system for an Oil rig but, if you get those wrong you might produce something that looks more like a rocket.

This week I shall tackle another worn out cliché - ‘Don’t re-invent the wheel’ (I think they should re-invent the cliché; keep the wheel out of it). I interpret this expression in two ways. Firstly that if you try and re-invent the wheel you are obviously wasting time and resources because the wheel has already been invented but secondly that you shouldn’t do it because if you do anything other than plagiarise the original then you will have got it wrong. I’m OK with enhancing the wheel by the way; that’s different.

When we talk about Document Control we are almost always referring to Projects and the design, procurement, construction, commissioning, close-out and handover of an asset.
When I learnt how to do Document Control we always reported to Project Controls or Project Services, which makes perfect sense to me. Not only is it a service to the project as a whole but also it is a control function and an integral part of the suite of project control functions. From the ownership of the function came a set of detailed business requirements and the delivery of those requirements evolved into what we called best practice process. Somewhere along the road, that changed. It started with the proliferation of EDMS tools that were designed for everything to do with document content management but nothing whatsoever to do with Document Control. Did I say nothing? I mean nada, big fat zero, zilch, not even a soupcon or a smidgen. Come on somebody argue with me. Bring it on. I don’t care how big or hard you are, you’ll lose.

Industry believed the sales pitches and the IT consultants who said they could do anything and everything and beyond because they wanted the long configuration work. But what eventually happened was that best practice process was compromised in favour of what the systems were capable of. That was a case of the wheel being re-invented and of course getting it totally wrong. The next thing that lumbered awkwardly down the road was something called Information Management. Some companies adopted it and promoted their best Document Controllers to be Information Managers and that worked out fine but most didn’t do that. Most IM people came from IT (cue: blood curdling screams!). The final re-invention from a perfectly good wheel to something that isn’t round and can never function properly, had begun. Now you find Document Control reporting to IM who report to IT.

 The vast, gaping flaw with that approach is that the business requirements have been either greatly diminished, if not entirely lost and forgotten. IT believe that the solution to the ‘problem’ is an IT solution and they push back on the business to compromise and reduce their requirements. To add to this sorry tale of woe something else happened. A new generation of ‘Document Controllers’ that were trained to do what an inadequate system was capable of doing without ever been shown what Document Control can and should really deliver with all of it’s many splendored facets and fabulous shiny aspects. So many of this generation of system users have never even heard of some of the techniques and principles that I consider the essential best practice keys to the business called Project Document Control, let alone learn to apply them, understand them and become expert practitioners.

In a design phase of a project or programme, Document Control can and should provide high value data and reporting into the Planning function, Cost Control, Procurement, Engineering, Interface Management, Risk Management, Q.A., Assurance and Project Management as well as staffing and resources scheduling. During the construction phase of a project or programme you can add Site Queries, Certification, Commissioning, Operations and Contractor Management and Legal (fighting adjudication and litigation and winning insurance claims for flooded sites). I’m not talking about the distribution of information here, yes we do that too.

I’m talking about the power of reporting and the information that feeds to all of these departments, disciplines and functions. If the business processes are in place and the procedures, contractual instructions, taxonomies and standards and all of these things are correctly defined and integrated between departments and supported by management, then you can start to define the functional requirements of a software system to help you to do the job as efficiently as possible.

 All of these things have been done before but there are experts in the field of putting them all together and delivering world class project Document Control. The wheel’s already there, why re-invent it? True - Document Control is an established discipline, but as expert practitioners at a fundamental level and in every aspect of Document Control, we can identify and deliver opportunities for continuous improvement, and that’s highly valued by our customers. There’s always room for Improvement - and enhancement; there is however, no need to re-invent the wheel.

Win an iPod in the 1st Annual Document Control Easter Bunny Blog Hunt

I'm sitting here in my Easter Bunny suit that I just picked up from the dry cleaners. I've got my trusty old Remington typewriter and a pint of rare Bourbon you can’t buy north of the Mason Dixon line. I've got a couple of packs of Luckies and a full tank of petrol I nabbed before the pumps ran dry. But I'm indoors, it's dark and I'm wearing sunglasses so let's hit it and see who can get all the Easter eggs in my Famous Annual Document Control (DC) Easter Blog Hunt.

Barton takes his role as Easter Bunny very seriously.

All you have to do is write a response in the comments section and the person that finds and answers the most questions with the best arguments, in the opinion of the venerable panel of judges, will be awarded this year's prestigious mystery Easter DC Blog prize, which will be a new iPod Nano. In the case of a tiebreaker, there's bonus points for spotting any of the musical, cinematic or literary references.

It's kinda hard to concentrate because my friend Maxine's started her ladies only dance class upstairs and the 70s New York Disco Funk is reverberating the floor boards, meanwhile there's hailstones battering  the window like I'm under fire. Last week it was so hot the hens were layin’ hard boiled eggs and this week half the country's a ski resort. It's a crazy world brothers and sisters but whenever someone asks me "How's life?" I always say "Compared to what?".

So lets begin the hunt. There are other threads somewhere on the theme of 'Where does DC belong'? I think I enjoyed reading and participating in those threads more than most others and as I was contemplating setting my annual Document Control Easter Blog Hunt, I started to think about why that is?

I think the reason is that to properly understand where DC fits and where it should report to, you must first define 'What is Document Control'? There's a twist to that of course, which is, are you talking about Project DC, Construction Site DC, Offshore HUC DC or Operational DC or internal corporate DC? (did I miss any?). But that raises another question ‘What are the differences between them'?

I think that to define what DC is you have to really understand everything it can be. I know that perspectives vary greatly from one sector to another and one country to another and between people from different disciplines and functions within those sectors and from those countries. So a Safety Manager working on an operating Oil refinery in the US might have a very different perception about what DC is to let's say a Procurement Manager working on the design phase of a new FPSO that’s getting built to operate in the North Sea. Then again, the QA Manager working on a new High Speed Rail line in the conceptual design stage will possibly have an entirely different point of view. This might not only be contingent on their professional capabilities relative to their role. Their understanding will have been developed throughout their exposure to DC. So, a QA Manager on a Rail project that came from finishing the handover and completion of a Nuclear Power Station will probably have a different set of references to someone who was previously working in a Biscuit factory.

An iPod Nano will be the Easter Bunny's first prize. 

Why is that? Theres an old Indian story of 5 blind men walking along the road where they come across an Elephant Keeper coming the other way with his Elephant. Having never encountered one before, they all proceed to try and figure out what the Elephant looks like. One grabs the tail, one grabs a leg, another gets the trunk, one holds an ear (did I miss anyone?) and they all thank the owner and continue along the road but they start arguing about what an Elephant really looks like. The one that got the ear says it's like a huge Banana leaf, the one with the leg says no, it's like a big fat tree trunk, the one that grabbed the trunk protests that it’s like a huge long snake...........well, you get the picture. That's my take on how come everywhere you go, people think of DC based on their own experience and what they needed or wanted from it in some context combined with how it was allowed to function on that particular project or based on that companies standards. Some companies actually try to apply their standards globally and some just let everyone make it up as they go along. It's no wonder that most people don't actually know what Document Control really looks like.

Of course it doesn't help that it's dark and we're wearing sunglasses.

So what do you think DC really looks like? What are it's features, it outputs, it’s benefits and is it fundamentally a service function or an admin function or is it like an extension of QA or maybe even a driving element of the Project Controls and PMO suite?

Can DC feed valuable data into Planning progress reporting? Cost Control? Procurement? Staff forecasting? Expediting? Risk Management? Commissioning? Data Control? Asset Management? Executive Management Dashboards? Maybe I’m giving out too many clues.

I know of a very big, lets say public sector (you're paying for it) infrastructure programme that shall remain nameless to protect the guilty. They didn't know what DC was and where it should sit so they placed it under PR! Articulate that to the Marines. Eventually they moved it under the Technical Directorate but they didn't know what it was for either so they let IT decide what to do with it. Naturally IT couldn't understand that DC is not a problem for which there's an IT solution. So, having a massive disposable contingency fund (did I mention that it’s your money?) they decided to give it all to some world famous consultants to figure it out and guess what? They used all the money up.

Needless to say it doesn’t work. That fact might never be fully appreciated because they don't know what it could and should be or how to recognize that it’s not there! So they'll blame something and someone else when something big disappears down a hole. (Clue. not a Rabbit hole, no White Rabbit).

Well that’s all from me before I say anything too controversial. Please make sure you respond in the comments section on the blog and see how many little golden eggs you can collect and remember what do points make?

Endorsements.

Have a safe and happy holiday.

If it's not rocket science, why do so few people understand it?

I'm confident that most of the people who read this blog will agree that there are distinct differences in the application of project Document Control versus the application of other information related functions such as Records Management or Operational Document Control or non-technical Document Management. Then there are differences across sectors of Engineering as to how Document Control is approached and generally understood.

There are experts in the field of Records Management that are highly competent and very experienced but really would not have the first idea of how to set up a project Document Control function. There are people with degrees in Information Management who don't even know what we mean by project Document Control. Believe me this is not conjecture, I have had the honour of having to work with many such people; I learnt something from them and I like to think some of them learnt something from me. For example, when I want your opinion, I'll give it!

(Of course I also know some world class Information Managers and even some Records Managers who understand what Document Control should look like, but they all started out as Document Controllers themselves).

Meanwhile, if you think I'm stretching the facts, consider this. The Gartner Guide is used by many businesses to select the best EDRMS tools. If a system sits in their 'magic quadrant' then it's considered a safe bet. Well I've been interviewed by two representatives from Gartner on two separate occasions, where I was involved in a system selection process. On both occasions, so that they could understand the requirements for the system, I had to explain at length and from scratch, what Document Control is, how it works and why it's important. They could then begin to understand the difference between content management which is their area of expertise and Document Control, which is mine.

Many, many companies have invested hundreds of millions between them (conservative estimate) in these systems, having taken advice from such experts and from Records Management experts and Information Management experts and of course the 'A' list consultancies who know that these systems are a meal ticket for them, only to discover that they need to spend millions more on customisation, more consultancy and on bolting on things the system is not designed to do. For example bulk upload metadata without content. In that time of course they may also have lost money on claims, lost work and missed deadlines, KPI payments, been hit with disallowed costs etc, etc for lack of traceability and proper reporting.

(Obviously there are realms of content management and record management requirements outside of project Document Control whereby an EDRMS content solution makes perfect sense, particularly for big corporations and global enterprises however, a proper Document Control database is also needed and there are so many examples where that alone would more than fulfil the requirement).

I have complete respect for my fellow colleagues and for their expertise in their own fields. Obviously good Records Management is essential. Patently, for the sake of our planet, good Operational Document Management is paramount and of course there are thousands of other business sectors like Legal, Banking, Retail and so on where there are different requirements in Document/Content Management.

The fact is however, that on engineering projects, without best practise project Document Control the Records Manager won't have everything they need to archive and the Operations team will have neither the complete record or the quality and compliance across the docbase that is critical not only for Safety but for the performance and maintenance of the asset.

This is one of the multitude of reasons that Deliverable Schedules are so essential. Getting the information up front from Contractors and Vendors so that you can plan the distribution and approvals but also so that you know what you should have to handover and that the supply chain have signed up to it. Which takes me back to bulk uploading of metadata without file content; it's a fundamental requirement of project Document Control. If a system doesn't have that then I need something that does.

A very common syndrome is that many businesses have compromised by adjusting how they work according to what the system they've spent so much on is capable of. The words tail and dog spring to mind.

I'm interested to know others experiences across different sectors. I personally believe very strongly that there are key pillars of best practise that apply in all sectors, be it Rail, Aviation, Oil and Gas, Civils, Mining, Defence. Meanwhile I have spoken to Nuclear Power owner operators who, like the Gartner reps, had no idea what I was talking about. It was all new. Same in Aerospace, same in Mining, Utilities etc and even when companies do acknowledge a need, there is still a vast spectrum in their levels of understanding and therefore across the standards and application of Document Control across these sectors.

An obvious result of this lack of understanding is reflected in the quality of people that get hired to do Document Control. Where there is no recognition of the function as a discipline, people will be hired with little or no experience because they are cheap and they'll do what they're told by someone else who doesn't know what needs to be done. Then someone decides that a new system will solve their problems, so they get some expensive consultants to send in some business analysts to define requirements. They get the requirements from the users who don't know anything but the consultants don't care because they can deliver a system that they know will generate more work for them when the business wises up that the requirements were inadequate. It's called the 'long con'.

I heard of a major airport programme for example where all the legacy drawings were lost; out on the site somewhere, thrown into old containers and nobody could remember where. So they had to re-survey the whole site. I've heard of facilities being built to hundreds of rejected drawings that are currently operating. I had a colleague that worked on a massive refinery programme where one of the US design houses engaged in a long running battle with him because he insisted that they keep the same drawing and document numbers throughout their lifecycle and uprev them when they resubmitted. They insisted that he was wrong and that they always change the drawing number and keep the revision the same! You couldn't make it up.

I am trying to highlight, again, the need for recognition of expertise in the field of project Document Control, specifically. I am interested in others views and experiences on the subject and I am interested in raising the profile of so many highly professional practitioners that I've had the great pleasure to work with over the last 30+ years, many of whom I count as close friends.

I've lost count of the number of times I've heard people dismiss Document Control with the tired line 'it's not rocket science'. No it 's not, neither is designing a bridge, but there is a science to delivering first class project Document Control and it's value is immeasurable. The people who can deliver that should also be recognised and valued.

Faulty approaches to Project Document Control cost millions and put projects at risk

This week, I would like to throw a spotlight on a ubiquitous irony that results in the unnecessary waste of millions of pounds across all engineering and construction sectors.

Industry does not recognize professional expertise in Project Document Control.

Placing the broader question of generic Document Management and Information Management to one side, I have personally witnessed millions of pounds poured down the drain for the simple want of going out and finding a Project Document Control expert to write best practice procedures, select the right software tools and find the right people to provide a proper function from the start of a project. I have also seen such professionals employed and ignored whilst others with no experience make costly decisions.

The irony is (and this is common across every engineering sector) that Document Control is under resourced and companies are reluctant to budget appropriately for it. What is then very common, is that rather than spend a small amount of money investing in a professional with a proven track record in successful project delivery, projects choose to engage expensive consultancies who then deploy business analysts, who spin their wheels whilst re-inventing wheels, who attempt to configure systems that were never and will never be fit for purpose and justify this on the basis of meeting user requirements, where the users are also unqualified to provide requirements. Another frequent mistake is to assume that an IM or an IT person will know what to do; but like most professions, it requires many years hands-on experience to own the big picture and be capable of success under all circumstances.

This sounds ridiculous and it is, so why does it happen all the time? Why do all my peers in this business have very similar tales to tell? There are a number of typical reasons. In some industry sectors and especially in the public sector, many managers ‘hide’ behind established consultancies to make decisions for them. Often these consultants are integrated into the project team and paid for under ‘operational’ cost which circumvents the red tape and lengthy writing of business cases even though it can end up costing ten times as much for a solution that fails and no-one ever uses.

A more common reason is that nobody wants to make the effort to understand the detail of the requirement because they have better things to do and when a technology salesman tells them he has a one stop solution that does everything - they want to believe. They already think, incorrectly, that Document Control is a problem for which there is an IT solution. There are so many systems out there that have bolted on some concession to ‘Document Management,' whatever that means! There are software systems that started out as CAD systems, Configuration management systems, Collaboration portals and file sharing systems, Planning systems and more. As someone who has been very successful over 30 years delivering world class standard Document Control or should I say North Sea standard? I can tell you categorically, that no software system can accommodate and support the processes and functions necessary at that level unless it has been written from the inside out around those processes and specifically for that purpose.

For an experienced professional, there is no mystery about the right ways to set up and deliver best practice Project Document Control. There seems to be endless confusion however, when people are tasked with the delivery of that function who lack the experience and the knowledge that comes with it.

It starts with understanding the proper application of key principles appropriately for the sector and type of project. There are highly valuable techniques to numbering, revision coding and taxonomy for example that when applied well can make money by increasing efficiency, communication, accuracy of content and distribution, hastening the review and approvals cycle and providing key operational information. On the other hand, when these methods are not applied, it can lead to a real life disaster.

Document control in the Design, Engineering and Construction industry is not something random that you make up according to someone’s good idea. There are well proven essential principles that can only be prescribed and applied by an experienced practitioner.

A further irony is that the reluctance to spend a little money comes from underestimating the critical importance and the great value of the function and in believing that it’s a small risk that might need to be mitigated. One major Oil and Gas owner operator recently assessed that by combining the right people, processes and software tools, they now save between 3 and 5% across all their projects globally. That amounts to tens of millions, if not more.

A clear definition will be what positions Document Control in the industry. It's time to get it right.

by John Barton


There has been a great deal of conversation recently, both within Document Control chat rooms on the web and within the Institute of Document Control over the right definitions of Document Control and Document Management. 

Definitions matter and I for one would like to see more debate, if not consensus among the Document Control community because a united front will ultimately help others understand what we do and why we should be recognised as specialists.

In particular, if we can get across the little understood difference between Document Control and content management or generic business document management, then we can get across the fact that the processes, technology and skills required to do each of them also differs. Who knows, we might even be resourced properly on our next job!

In my opinion Document Control is fundamentally about traceability; it is about capturing every detail about what happens to documents and drawings as they move from point A to point B. This is essential on engineering projects in particular, where an audit trail is required for the circulation of technical documents and drawings (deliverables) through, for example, revision and approval cycles and issuance to third parties. An adequate audit trail is a cornerstone of project management because it allows progress to be monitored. It is also essential when deliverables have been handed over to the owner / operator of the asset to support its ongoing operation. Finally, when there is reason to search the archive records to investigate what happened at a critical stage of the project lifecycle, adequate Document Control can for example disprove that delays and re-work were caused by untimely issue of information.

I like to make an analogy between Document Control and the postal system. You can do what you like with the content of a document during authorship, including collaboration without constraint but at some point, for example to meet a contractual deadline, the finished version needs to be transferred to another party inside or outside of the organisation. It gets assigned an ‘address’ in the agreed number structure format (which tells you not only where the document is scheduled to go but its type and where is from so its movement and permutations can be tracked) and submitted to Document Control (i.e. posted) to be logged, tracked and delivered.

Generic business document management on the other hand is about a much more widely applicable set of practices such as document storage and retrieval, where traceability is not the priority, there are no revision cycles or status changes and distribution is far simpler. Moreover virtual electronic filing cabinets, a.k.a. content management systems, are wholly inadequate for the task of document control, which requires specialist database technology.

To recap, Document Control requires particular processes, specialist technology and dedicated personnel. The sooner the various industries within which we work realise this, the sooner they will be able to mitigate project risks and deliver on time and to budget.