How is life managing a macro-project?

When I go to a job interview and someone ask me "have you ever managed big teams at work?", my answer uses to be the same, a bit square minded engineer, I have to recognize: "Define BIG".

The aim of this article is giving an idea about what is a "big" project for the professionals of project management. All the numbers in this article are "rounded" to avoid them to match with confidential data, but at the same time, accurate enough to give you an idea of the "magnitude order" for this "big" projects we are talking about.

Let's imagine an EPC project with the summarized characteristics listed below:

• Scope: 15 process units, 12 auxiliary utility units, 20 buildings, three jetties and some other "little" things. I know it is not very SMART scope, but it is again due to confidentiality.
• Time: 51 months, with six months from starting to issue the procurement "Notice to proceed" and 45 months to reach "mechanical completion".
• Final Price approximate: 3500-4000 Million Euro. Plus minus cents.
• Design Engineering teams: Three Engineering teams working in four different places all over the world with 300 team members each. Around four million engineering hours as a whole.
• Number of engineering documents emitted: 120.000 documents in "head office", vendor documents included. Field engineering documents and "as built" ones not included.
• Procurement teams: 60 buyers.
• Number of "Purchase orders": Around 2000 PO's issued considering equipment and bulk materials.
• Construction teams: 300 people in Field Engineering department. During the maximum work load at site, the estimation of people coming in and out the site in a daily basis was around 20.000 persons including local work force and expatriates.
• Number of IT principal systems: 10. Among others, SAP, documental management system, procurement management system, requirements control system, 3D model, project control systems for planning and costs, advance control system and some others for advance measurement in construction.

This is a "macro-project", and it is because of a bunch of reasons. Just one example: the finance insurance for the execution is, in a lot of cases, warranted by entities partially owned by state governments; of several countries!. Appart of the list of numbers mentioned before.

If I have to remark something that makes me being proud in my professional career, is the opportunity of being part of something this "size", because management theories were coming with me at the beginning; but the learning process inside these kind of projects from the professionals you are working with is amazing, and it comes day after day after day. People with years of experience in these monster projects teach you by "osmosis" an amount of knowledge that is complicate to measure. You are learning even when you think you are not.

Just living the project routine you are internalizing time management systems, communication management, advance measurement systems, cost control management, cash flow management, etc. These knowledge will be part of your "intellectual and professional capital" for the rest of your life.

In addition, I had the luck of being part of the project management office as project engineer in two different roles, and in both of them mi vision of the project was pretty transversal, both in the EP (engineering and procurement) part and in the C (construction) one. Just to put it in context, a "Project engineer" is a resource of the PMO who can perform several roles: Process Unit Manager, Supply Chain Manager, Interfaces Manager, Technical Manager and some other things, in any case, in very transversal positions of the project.

And how is life inside a project this size?

Summarizing, you never get bored!

Just at the very beginning you learn things like following the procedures as well as work instructions "strictly". This makes the difference. I honestly think it is part of the engineering companies, capable to execute these kind of projects, added value. I remember as an anecdote a discussion with a discipline leader about who was responsible of converting a document into pdf. To find the answer in a work instruction took 45 minutes, converting the document into pdf takes 30 seconds in a printer. I did not understand anything. Well, in a project this size thousands of documents are emitted (as you have read before), considering the amount, 30 secs per document makes a "big" amount of hours invoiced to a discipline, or to the document management department. Those 45 minutes saved a sensitive amount of money both to that discipline leader and the project itself.

You learn things like the difference between invoicing a milestone the day before the customer payment day, or the day after. When you have a milestone priced in tens of millions, that means a month of difference for that money to be positive in cash flow terms. And this, when you are the Field engineering manager shows you the real priority of your job. Field engineers main duty is prevent construction to be stopped as a consequence of a design issue. Releasing whatever blocking point that were limiting construction activities, this is it at site! as simple (or complicated) as this!

You learn things like how big are the implications of the heavy lifting planning in the construction development. You learn there are ringer cranes that lift 16.000 tons with an arm longer than 100 meters. This is a 35 levels building height! The counter weight is made with sixteen 40 feet standard shipping containers full of sand. And the crane guys parked their cars under the shadow of "that thing". You learn to plan a lot, because that crane arrives disassembled and it takes a month to be assembled with a rental fee of roughly a million per month. And the first month the crane lifts nothing!

You notice that making 20.000 people to come in and out of the site every day is not an easy logistic manoeuvre. On the other hand, to host those 20.000 people means you have to construct a medium size village considering Spanish standards with prefab houses. You have to provide water piping lines, water, wiring, electricity, you have to make a small hospital, firemen station, heliport, etc. Just this is a project for a lot of companies.

You also notice in the "bad way" that a very small unit of just one million euro can take one year time to be constructed considering you have four to construct the whole refinery. And it is not a big process unit, not even an auxiliary utility unit, it is just a "big" drainage line. But the crude reality is without that drainage finished you can not boot the cooling towers unit, and the same with the waste water treatment unit, and without those two, you can not boot the process units of the refinery. And you change your priorities about what is important, what is urgent, what is "cheap" and what becomes "expensive".

You learn when you are speaking english with 19 different nationalities in the same table, communication management is key. You learn not all of them are understanding what you are trying to explain, much on the contrary, almost none is doing, and due to this you have to acknowledge reception of the message, close the communication loop both verbally and in the minutes of meeting. Misunderstandings are part of the daily work.

You get immersed for the rest of your life in the HSE culture when a lot of meters of a high scaffolding collapses because of the wind and 4 workers are still alive today because they were correctly anchored to a life line correctly implemented. From that time on, you have HSE eyes on everything you do, from refueling your car to any minor "patch" to be done at home.

Let me remark this is just my own experience, probably a lot of project engineers or project managers involved in these kind of projects would add or delete a lot of things, and probably all of us would have motivations to do it. I have just tried to write it down in a friendly way for people with or without experience in the oil&gas sector.

To "start finishing", I have worked in several sectors, with a lot of different types of projects from one million to billions, all of them are unique by definition of project, all of them have difficulties, neither bigger nor smaller than the one mentioned in this article, it is just a scale matter. However, let me finish as I started:

When I go to a job interview and someone ask me "have you ever managed big teams at work?", my answer uses to be the same, a bit square minded engineer, I have to recognize "again":

"Define BIG".

Thanks for reading.

Marco Arranz.