Friday, May 16, 2014

Reality beats Fiction

What follows is a genuine email from one of my engineering ‘colleagues’
Client (MAJOR OIL COMPANY) have a great respect for this boy
He’ll go far

In case you don’t get the subtlety, the ‘handrail’ is not a real handrail (not part of the rig)
Third line is a masterpiece of self promotion from a man who obviously does fuck-nothing

The irony is that in trying to satirise the world of the office worker in my stories I couldn't even begin to approach the levels of absurdity contained in this email.



You write about a key gap and threat to EPC that has been identified, but needs flagging appropriately.
In short ‘yes’ such a doc exists, but the attached excel docs that I produced need conflating, updating and expanding; to provide the handrail to which you refer.
This is very much where I perceive my part in EPC lies: To capture the design thinking so others can actually design!

So I can relieve the pressure on you to manage considerations and the resulting identified threats by capturing them for you in this way:
• risk (probability of occurance + impact)
nb. Risk is neutral and comprises Threat and Opportunity and Impact is affected by the identification and leverage of strengths and weaknesses of the organizations involved.
• threat (intent + capability = Threat)
• Opportunities (situational Understanding + relevant engineered design solution)

I can then improve the collective situational awareness using this product. Achieving Situational Understanding begets the opportunity to seize more opportunities. The increased tempo possible from forecasting such threat then means threats are managed out by problem solving. The hard part is making the document focused upon ‘deliverables’ (probably combine the two excel docs attached into one??) so the client actually reads it too, despite there being so many facets of threat to consider.
1. The action on the XXX CoF threat should be included in an expanded version of the RS Register and publicised among PROJECT.
2. EPC Project Team are treating the HPU loc issue as a Threat (the effect, Delay) to Structural capability this will treat the impact of the deadlines.

3. I agree we need to talk over as a EPC team the design analysis/constraints/obstacles and perceived threats and opportunities. This doc can be used as this handrail.
The outcomes based document attached is a parent doc wot I wrote, and gives the simplified version of what we are going to do and what effect we wish to achieve as we work towards identified objectives (scheduled of course) and the fully functioning outcome.


Tom said...

is it possible to write something technical coherently? The humor is, alas, lost on a simple layman like me, but would probably be fall-out-of-my-seat hilarious in a Monty Python skit

Garth said...

Tom: It is absolutely imperative that technical writing is coherent - yes there is an element of jargon, but technical reader needs to be 'in on the joke' - in this case there is nothing technical at all - the author is employing the old 'bullshit baffles brains' technique