In some industries, there’s no such thing as a flexible deadline.
In 2017 BP sold the Forties oil and gas pipeline to Ineos in a deal worth £199m. At the time the pipeline carried 40% of the UK’s oil production and could move up to 600,000 barrels a day. This was a huge transition of a major asset. Our job at Vetasi was to move BP’s asset management IT system to Ineos’ infrastructure so that when it was fired up on day one of the new ownership, everything would work just as it did before.

This system handled inspections, scheduling and finance. Without it the pipeline not only wouldn’t function, it wouldn’t be allowed to function. Unless it could show its operations were safe and efficient, Ineos wouldn’t be granted a license to operate.
We had four months. Extending the deadline was not an option.
Delays to the project would be hugely expensive. If Ineos used the price of transporting a barrel of oil on the date it was due to take ownership to justify the purchase, then even a one-month delay would cost it millions of barrels. That’s a lot of money, potentially enough to derail the profitability of the deal.
If the deadline was missed BP would be paying for the systems it used to run the facility, so it needed to switch them off, on time.
And because managing everything that makes up an oil pipeline is not only financially important but safety critical, there is no margin of error.
It was bad asset management that led to the Texas City refinery disaster, which killed 15 people. On the face of it, we were moving an IT system from one business to another. But really, we were having to secure the safe operation of an enormous, complex and potentially dangerous facility.
Bringing the project in on time strengthened Vetasi as a business and taught us a lot about how to make these transitions as quick and as smooth as possible.
Don’t make sweeping changes where they’re not needed
Changing systems for the sake of change takes time, costs money and makes it harder for the users to do their job. If you’re moving to a similar system, if it works and does the job then leave it alone. Simplify where needed but don’t make it so different no-one can use it without weeks of training. That’s how mistakes get made.
Tell everyone about the consequences of delays
It’s easy to assume that everyone involved knows what happens if the deadline is missed, but don’t make assumptions. From the outset everyone who has to make decisions that affect the project, from board level to software engineer, should be aware of the deadline’s immovable nature.
Keep the number of decision makers as low as possible
An easy formula that keeps indecision to a minimum: no more than one decision maker from the business per month of the project.
If you only do one thing from this list, make it getting and using the correct data.
I can’t overestimate the importance of correct data to the success of a project on this scale. Get access to it the moment the project starts. Test it before you use it, because if it’s wrong then nothing will work. And don’t underestimate the time and effort needed to move it.
Share this Blog Post: