Holdfast Training Services Trial Blog

Thought I’d share with you all my slightly chaotic first experience of being responsible for a contractor deploying off-shore!

Background

The Glen Lyon Floating Production Storage and Offload (FPSO) vessel (pictured) requires an upgrade to their existing Helideck Management System (HMS) to bring it into line with upcoming legistlation changes from the Civil Aviation Authority (CAA), no later than 31 Mar 21.

I am the project engineer responsible for delivering the upgrade.

Fugro Engineering (HMS vendor) had taken part in trials with the CAA earlier this year and as such, their HMS was the first to be certified as compliant with the new legislation. It was decided that although they will not be the chosen vendor for the installation, we should employ Fugro to conduct a survey of the existing HMS and ask them to come back to us with a detailed gap analysis and proposed modifications. This gap analysis would then form the basis of the client SoR that I am writing later this year.

I liaised with Fugro and arranged that 1 x service engineer would deploy off-shore for a period of 7 days to conduct the survey. They requested that I provide them with an array of documentation (block diagrams, commissioning reports, general arrangement drawings) prior to deployment. After checking that releasing documentation to Fugro was ethically sound from a commercial perspective (they are a competitor to our existing HMS vendor), I obliged. I would later come to regret not asking them whether that was all they required.

Finally I warned off the off-shore team that there would be a contractor deploying to conduct a survey of the HMS.

What Happened

On the first morning of the survey, after conducting a visual inspection of the system and looking through physical documentation, the Fugro engineer then inserted his own USB hard drive (big no no!) into the BP system to, in his own words, “download recent service visit data for data integrity verification”.

This hard drive then “accidentally” fell off the desk and swung into an open cabinet beneath and hit what I can only imagine was a big red button. This consequently managed to shut down the Integrated Marine Monitoring System (IMMS) and the Differential, Absolute and Relative Positioning Sensor (DARPS). In short, this meant that the whole HMS was effectively shut down, meaning that no helicopters could take off or land. The engineer was unsurprisingly stood down, pending a review of the incident.

Key Mistakes

Thankfully there were no serious consequences arising from the incident and the HMS was back up and running in short order and the engineer erased all of the data extracted from the system onto his hard drive. There were a few key mistakes leading up to the incident which could have easily been avoided:

1: Failure to confirm data requirements. As mentioned above, I had naively assumed that the documentation I had sent over prior to the survey was sufficient for their needs. I should have confirmed this and asked whether there were additional data requirements from the live system. This would have then enabled me to warn off the off-shore team, who could have ensured that the engineer was adequately supervised.

2: Inadequate Survey Scope of Work. The “normal” procedure for off-shore surveys is the production of an “survey scope of work”, which is typically produced by the off-shore sponsor. This job fell between the cracks because the survey was co-ordinated between the Aviation Technical Advisor and my department, both of whom are on-shore. The consequence of this was that when the engineer arrived, the off-shore team were not entirely sure what the purpose, scope and limits of his visit were, which ultimately resulted in the incident occurring. It was an assumption (that word again) of mine that the off-shore team were fully aware of the survey and would be on hand to ensure that it went smoothly.

3: Inadequate off-shore induction. The particulars of BP’s policy on IT security were not included within the induction briefing given to the engineer, specifically the use of unauthorised USB devices.

Key Takeaway

*Stakeholder Engagement is vital!* “Stakeholder engagement” is a phrase that I have glibly written numerous times of the course of phase 1 exams and projects. This experience has certainly brought to the fore that the lack of it can has calamitous consequences. As a project engineer and single point of accountability in BP, there is a lot of work that goes on around me and it is ultimately up to me to ensure that everybody is suitably informed, briefed and fully understands what is happening, when and by whom. This is doubly important in the oil and gas industry; I’m in the awkward position of being ultimately responsible for contractors off-shore, without the luxury of being physically present to ensure that it runs smoothly!

Making assumptions is a dangerous game and a mistake I will certainly not make again. To finish with the universally applicable advice of my first Troop Sgt – “Sir, it’s good to trust, but it’s much better to check”.