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. |
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.