Project Management
2.3 Project Life Cycle
2.3.1 Initiation of the Project
In any major projects there is involvement of many project man- agers, as there is an owner, an engineering consultant, and a con- tractor. All of them should 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 Project Management Professional (PMP) guide, but its name is different from one company to another. This document is extremely important for getting a project started in the right direction.
There are many reasons for starting a project. In general, for com- mercial and industrial companies, making money is the reason for doing a project. However, in some cases, there are many other rea- sons for doing projects, such as to follow government regulations and laws, to enhance the health, safety, and environment (HSE) for a company, or 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.
A project charter is defined in Project Management Professional Book of Knowledge (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 is wide-ranging 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, because the number of changes that can be made to the scope after the contract is signed is very limited. 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 ref- erence to other documents the business needs and 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 docu- ment should be simple, precise, and accurate. To put the reference is not recommended because the top senior management does not have time to go deeply 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 questions and inquiries.
This document usually contains the following:
• The name of the project
• The purpose of the project
• The business need for this project
• The rough time schedule is 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 managers. 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 manger 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.
2.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 end 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 func- tions 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 func- tion 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 stake- holders. Take more time in this stage, because, in most projects, the scope baseline takes weeks, or even months, not days, to finish.
Take ideas as needed from the key persons who are sharing in the project, so that they are satisfied with the scope as it is and won't demand changes to it later.
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 sup- plier who will provide this service. You should use any commu- nication and skills necessary to make the scope of work clear to the supplier. An engineering company will provide a list of deliv- erables. 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 it will be read by many people. The SOW is the most important part of the statement of
requirement document (SOR), because most of the conflict in any project is due to a misunderstanding of the scope of work. In some cases, the supplier may provide a small user manual to use for main- tenance 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, or they are afraid that the supplier will be out of busi- ness 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 the order. From this example in the deliverable list, the contractor will deliver the "user manual"
but it is different from the stakeholder's expectation.
This situation is repeated many times in oil and gas projects.
However, if we apply the whole building commissioning system methodology, as presented and discussed deeply in Chapter 8, these problems may not occur. The acceptance criteria, the test pro- cedure, 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.