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.

Thursday, April 5, 2012

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.