Project Management in the Oil and Gas Industry


Download 1.92 Mb.
Pdf ko'rish
bet10/176
Sana20.10.2023
Hajmi1.92 Mb.
#1713235
1   ...   6   7   8   9   10   11   12   13   ...   176
Bog'liq
2.Project management in the oil and gas industry 2016

Figure 1.1 Project life cycle.


How to Manage Oil and Gas Projects 7
project. Figure 1.2 shows the change in the number of personnel in the 
project.
From the above figure, it is noted that the project manager should have 
the necessary skills to deal with the changes that occur during the life cycle 
of the project.
1.3.1 Initiation of the Project
In any major projects there is an involvement of many project managers as 
there is an owner, an engineering consultant, and a contractor. They should 
all go through the same steps that we will discuss, but each person does it 
based on his or her goals, target, and company system.
In general, any project starts from a creation of a formal document 
called the project charter. The project charter is described in the PMP 
guide, but its name is different from one company to another. This doc-
ument is extremely important for getting a project started in the right 
direction.
There are many reasons for starting a project. In general, for commer-
cial and industrial companies, making money is the reason for doing a 
project. However, in some cases, there are many other reasons for doing 
projects, such as to follow government regulations and laws, to enhance 
the health, safety, and environment (HSE) for a company, or, more spe-
cifically, to help with oil disposal and the instant cleaning of the Gulf 
of Mexico due to the oil spill that happened in 2010. In some industrial 
and commercial companies, the projects stay current with developing 
technology.
First
stage
Middle 
stage
Final
stage
Crew size
Time
Figure 1.2 Change of crew size during project life time.



Project Management in the Oil and Gas Industry
A project charter is defined in PMPBOK and is expanded in the third 
edition due to the importance of this paper. It also recommends that the 
contract with the customer will be completed before the approval of the 
project charter.
Noting that, the definition of the customer has a wide range as everyone, 
including the project managers, are a supplier and customer at the same 
time.
When the contract is signed by the customer, the scope of work and 
deliverables should be clear, as the change will be very limited after the con-
tract is signed. Therefore, there will be enough information to be included 
in the project charter.
The definition of the project charter in PMPBOK is a document that 
formally authorizes a project and includes directly, or by reference, other 
documents as the business needs the product descriptions.
This document is usually made by the senior project manager, as 
the project manager will not be defined in this stage, so the document 
should be simple, precise, and accurate. Putting the reference is not rec-
ommended because top senior management does not have time to go 
into depth in the document. Also, I agree with Newell (2005) that this 
document should be small. If it is a big document you will face many 
inquiries.
This document is usually contains the following:
• The name of the project
• The purpose of the project
• The business need for the project
• The rough time schedule as defined by the project time 
period
• The budget of the project
• The profit from the project using the payout method
(discussed further in Chapter 3)
• The project manager in any situation
After signing this document, the project manager will be selected 
through a discussion between the project sponsor and the senior manag-
ers. In the case of a small project, the project manager has been defined, so 
there is no need to include his name. In addition, the project manager will 
prepare this document under the supervision of the project sponsor.
It is better that the project manager prepare this document, as he or she 
will be the most involved in the project and will closely understand the 
target and goals for the senior manager.


How to Manage Oil and Gas Projects 9
1.3.1.1 Getting to the Scope Baseline
As previously discussed, everyone in the project is a customer and a 
supplier at the same time, including the owner who is a supplier to the 
operation department in his company or any other user.
The key topic in any contract between two parties is to define the scope. 
As defined by PMPBOK, the term scope may refer to the following:
• Product scope, which includes the features and functions 
that characterize a product or service
• Project scope, which is the work that must be done to deliver 
a product with the specified features and function to the 
end user
The product, which will be delivered through the project, should satisfy 
both the customer and the stakeholder.
The scope should be prepared after clearly defining all the stakeholders. 
Take more time in this stage, as at the end you should define the scope 
baseline in any way that will not finish in days, but in weeks and months. 
Feel free to take any idea into consideration, especially from the key per-
sons sharing in the project. The last thing you need is, after finishing the 
scope of work, someone saying “we need to add some scope” or “we need 
a little change”.
So, after many meetings, reduce the unnecessary items from the scope 
or define part of the scope to the supplier so that the scope baseline is 
documented and approved by the concerned stakeholder.
After you define the scope of work, be sure it is clear to the supplier who 
will provide this service. You should use any communication and skills 
necessary to make the scope of work clear to the supplier. An engineering 
company will provide a list of deliverables. After you send the company 
the scope, be sure that the deliverables match with your requirements and 
that everyone has read any statement based on his or her background and 
previous experience.
It is better to return to similar projects and look at the work break 
down structure (WBS) and then review if you are missing anything from 
the deliverables list. In major projects, every discipline should review the 
deliverables list received.
This document needs to be clear because many people will read it. The 
SOW is the major main part on the statement of requirement document 
(SOR) as most of the conflict in any project is due to misunderstanding 
the scope of work. In some cases, the supplier may provide a small user 


10 
Project Management in the Oil and Gas Industry
manual to use for maintenance service. On the other hand, the operation 
and maintenance engineers may be waiting to receive a comprehensive 
user guide as they have a full responsibility to do the maintenance in house 
and avoid using the supplier in minor maintenance situations based on 
their policy. In some cases, they are afraid that the supplier will be out of 
business or has merged with another company, which traditionally hap-
pens. After receiving this manual, you may be in crisis because the supplier 
is doing what you are requesting, but the end user is not satisfied. In this 
case, you will change order. From this example in the deliverable list, the 
contractor will deliver a “user manual”, but it is different from the perspec-
tive to the stakeholder expectation.
This situation is repeated many times in oil and gas projects. However, if 
we apply the whole building commissioning system methodology, as pre-
sented and discussed deeply in Chapter 8, these problems may not occur.
The acceptance criteria, the test procedure, and criteria should be 
defined in the scope of work. So try all of the deliverables that are tangible 
and measurable items that can be easily understood.

Download 1.92 Mb.

Do'stlaringiz bilan baham:
1   ...   6   7   8   9   10   11   12   13   ...   176




Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©fayllar.org 2024
ma'muriyatiga murojaat qiling