Tuesday, April 24, 2012

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.

1 comment: