I've not had much to do with the Oil & Gas Industry but, some years ago, I did have one interesting consultancy job with the major company supplying Fire & Gas Alarms for the Morecambe Bay Gas Field. Natural gas was discovered in Morecambe Bay in 1974 and, four years later, commercial exploitation started.
Offshore production platforms are hazardous places (do you remember the terrible loss of life when the Piper Alpha platform caught fire?) and so they are provided with very sophisticated systems for detecting both fire and gas build-up. Platforms are also large and complex, resulting in thousands of points to be monitored and relayed back to a central display in the control room. Above all, the systems must be reliable so the computers involved in processing the data must be designed to reduce the possibility of failure and incorporate principles of redundancy to mitigate the effect of failure.
Well, the Fire & Gas Alarm company had produced an innovative design to meet these requirements. Hundreds of microprocessors spread around the production platform had to 'talk' to one another over cable and, at the control room, a series of industrial grade computers had to 'crunch' all this data to give the operators a picture of the situation. Needless to say, problems had arisen in producing the necessary software and making sure all the different parts worked together properly. The Fire & Gas Alarm company was under pressure from the end user to 'sort it', so they invited consultants from a number of organisations to attend a one-day brainstorming session. One of the invitations went to a University with a strong electronics department that we'd had dealings with. The University was unable to provide a member of staff on the appointed day but, being familiar with the type of safety-involved systems we produced, suggested that I might attend.
The brainstorming session was attended by a few academics, but the attendees mainly seemed to be from international consultancy organisations. The Fire & Gas Alarm company made a presentation describing the history of the contract and the architecture adopted and then an intense discussion about "what next?" ensued. Soon, the buzzwords were flying thick and fast from the international consultants as they attempted to dazzle everyone with their experience and grasp of the essential way forward. It appeared to me that there was too much re-inventing of the wheel, too little seeking to analyse where the project had lost its way and, to be unkind, too much creating jobs for highly-paid consultants. Based on what we'd heard, my view was that the basic approach was perfectly sound and that the technical staff already involved were competent. The problems seemed to lie in the project management and decision-making. I bided my time and then expressed these views in simple language, stressing that a more detailed hardware and software review was needed to separate the good bits from the bad bits in what had been produced. The day ended with one of the international consultancy firms and I being asked to submit priced suggestions. To my amazement, I got the job (perhaps simply because my approach appeared to cost a lot less).
So I ended up spending two days a week in Slough (!?!) whilst we tried to move things forward. It took some time for me to get my head round the complex systems they'd produced. I also arranged individual interviews with everybody involved to see where they thought the problems lay. This took a while as there were half a dozen hardware engineers, dozens of software engineers and their managers. There were one or two issues with the hardware but the hardware engineers seemed to be well on the way to providing acceptable solutions. Most of the problems were with the software. As the job had fallen behind, extra programmers had been brought in to accelerate the job but this created extra interfaces as the job was divided into smaller parts. This required additional documentation to keep track of the required functionality and try to ensure that each software module could 'talk' to the next. Changes in this documentation were frequent as people introduced new ideas or tried to work around problems. In fact, not much software was being written - the programmers spent most of their time meeting one another to iron out snags in the documentation. Frustrated by their inability to make progress, morale was low. The sheer amount of paper circulating was impressive.
I have never worked with a smarter bunch of people and their collective knowledge and experience was awesome. I struggled to keep up in software discussions, but I was determined not to bluff. I tried to strip away complexity and get people to focus on the essentials of the problem so that the teams, who wanted to be productive, could be given sound direction which would not have to be reversed in a couple of days. We started to see some improvement but we were still worried that the sophistication which had been offered to the end user was not achievable in a realistic time scale.
Accordingly, a somewhat less ambitious specification was agreed with the end user as Phase 1 which gave him perhaps 80% of what he wanted. The remaining functionality was deferred to Phase 2 and I'm not sure that Phase 2 was, in fact, ever implemented. The simpler requirements of Phase 1 gave a 'light at the end of the tunnel' that the job might actually be delivered. Fresh estimates were made, by the software engineers themselves, of the manpower required to complete Phase 1 in the newly-agreed timescale and the result showed that we only needed about a quarter the number of staff. The software engineers were self-employed and on short-term contracts, so it was quite possible to lay them off, but I had sleepless nights at the thought of formally recommending this action. I'd made friends with the people I was working with and expected to be reviled for my part in putting them back on the job market (I've always thought I'm too soft to be in business but others may disagree).
To my surprise, I was presented with a huge bouquet by the team and congratulated on "telling it like it is". The demand for software engineers was high and none of them would have any difficulty in moving into another contract. They'd been unable to convince management of the problems in the project and were just pleased that a hopeless situation had finally been addressed. Of course, it was logical to terminate my own role, as well. We went our separate ways, leaving the much-reduced group to finish off Phase 1.
I often think with fondness of the team I worked with. My only disappointment was that I didn't get to visit an offshore platform. At one stage, I was going to visit a Morecambe Bay platform as part of a team investigating a site problem but the visit was called off at the last moment and never re-arranged.
Is there a moral? I think it has to be "Keep it Simple" (sometimes called the 'KISS Principle - Keep it simple, stupid'. This is a modern re-working of "Occam's Razor", one of the contributions to logic and philosophy by William of Ockham, a 14th century Franciscan Friar).
