The Oil and Gas Engineering Guide

blog

fr en
Published Sunday 07/11/2010

Is your Project scope under control?

Why it is important to avoid Changes in a Project – but why they cannot be fully avoided

 

Changes to the Project technical baseline must be avoided as much as possible, for two reasons:

 

  • first of all, changing the technical requirements might change the cost from what it was estimated at bid stage,

 

  • secondly, changes always lead to disturbances and re-works, for all parties impacted, far more damaging and difficult to evaluate than the direct costs

 

Numerous changes are implemented during the execution of a Project.

 

- Some are normal part of Project execution, and cannot be avoided. They include design development, incorporation of information from vendors etc.

- Numerous changes, however, can be avoided. These are the requests made by the Client which are actually extras over the Contractual requirements.

 

Managing Changes created by the Client

 

These are two types of such requests:

  • Acknowledged changes, i.e., formal letter from the Client with a request for additional work, implementation of new requirement, etc., asking the Contractor to provide an estimate of the cost/schedule impact, and

  • Non-acknowledged changes that come in the form of comments on deliverables, requirements transmitted "candidly" via letters, records in minutes of meetings, informal communication (oral, emails etc.)

 

Acknowledged changes are a lesser issue as they will lead to compensation (time and money) from the Client through a Contract Change Order.

 

Non-acknowledged changes are the most numerous. They are the most damaging for the Contractor as they are often undetected and incorporated by Contractor at its cost.

 

Industry sources estimate that Contractors lose between 5 and 7% of the Contract value due to this.

 

How to Deal with such changes?

 

First of all, the Contractor must request from the Client to receive an official instruction.

The practical way to do this is to provide the following standard answer to any such request, e.g., that made as a comment on a Contractor deliverable etc.:

 

This comment constitutes an additional requirement to the Contract. (Explain why by referring to the applicable Contract documents). This request will not be considered unless Company issues an official request pursuant to Article X of the Contract "Company initiated change-order" ”.

 

This will eliminate the vast majority of such requests, as the Client will want to avoid the resulting extra costs.

It will initiate, for the remaining ones, the process leading to Contractor compensation.

 

Maintain your position in the case of non-acknowledged changes

 

Should the official request be received from the Client, it could either acknowledge that the request is a change to the Contract or not.

 

If the change is acknowledged, the Contractor will prepare the cost/schedule impact estimate. Discussions will then take place with the Client about such estimate. The challenge for the Contractor would be to promptly agree such estimate with the Client, which will then be recorded in a signed change order. The Contractor wants to avoid proceeding with the change, because of time pressure, without a signed Change Order.

When one knows that on large projects it takes on average one year between the date of receipt of the an acknowledged change request from Company and that of the signed Change Order, one understands that the Contractor is exposed for a long time.

 

In case the request is not acknowledged as a change to the Contract, the Contractor must notify that it constitutes such a change. If the Contractor fails to do so within a specified time period, it will forfeit its right to be compensated for extra cost / time.

The Contractor may either directly submit the cost/time impact estimate or state that it will not consider the request unless the Client acknowledges it as a change. This will depend on the Contractor willingness to implement the change, its impact, and time/effort required to evaluate the latter.

Once the above notification / estimate has been issued, the answer from Company shall be closely tracked.

 

Such answer may be a denial that the request constitutes a change. In such a case, Contractor shall not implement the request.

There is an exception to this when the answer from the Client contains a formal instruction to Contractor to implement the change. Contracts indeed usually give the Client such right to force Contractor to proceed and Contractor the duty to comply.

The Contractor will then record the costs incurred to claim them latter to the Client.

 

Should the answer contain no instruction to proceed, however, or should there be no answer received from the Client, the Contractor shall not implement the request.

Proper tracking by the Contractor of the Client answer and communication to all concerned parties whether or not to implement the request is essential.

 

Conclusion

 

It is critical that Contractors implement a tight system to detect the Client requests that constitute changes to the Contract. Contractors shall indeed only implement the requests that are recognized as changes or the ones they are forced to implement by formal instruction.

 

Failure to implement such a tight system, which is fairly common, results in significant losses for the Contractors.



Comments(3)


Published Monday 01/11/2010

Is your Project schedule under control?

Have you seen many projects completed on schedule? Neither did I. Here are a few ideas that hopefully may help.

 

Let’s first have a look at how a Project schedule is established and the progress measurement is made.

First of all, the scheduler establishes the baseline schedule.

The first step of a Project is to list the activities that must be performed to achieve its end result. Each activity will take a certain time, which must be estimated. The activities must be done in a certain sequence: some are pre-requisite to others. Finally, the project must be completed by a given date.

By working backwards from the required completion date, taking into account the duration and sequence of all the tasks, one finds the dates at which each of them must be completed and started (start date = completion date less duration).

On an EPC job, the scheduler proceeds backwards from the completion date, taking into account the estimated construction durations (work volumes * estimated productivity based on statistics), Required on Site (ROS) dates and lead time of equipment, which gives the required dates for placing the purchase orders, itself setting the dates for the equipment Engineering specifications etc.

The schedule logic links the various activities with the like of "finish to start" or "finish to finish" links.

The end result of an EPC Project is a running plant. Not all parts of the plant will be started at the same time. Utilities (power generation, steam, fuel gas…) will be started first, many months before process facilities, to support their commissioning. This must be reflected in the schedule: activities linked to utilities: construction, procurement and engineering shall be prioritized according to the start-up sequence.

The scheduler will also input more subtle links, such as availability of at least 50% of the pipes and fittings to start piping prefabrication, erection of at least 30% of equipment nozzles to start piping erection etc.

Construction constraints shall also be factored in, for instance that of completion of undergrounds before above ground, in order that the area is backfilled for above ground to proceed unhindered. This in turn will set dates for underground piping engineering studies, take-off and material purchases ahead of that of the rest of the piping.

Note also that dates for equipment site delivery are set by both

  • dates at which they are required by construction, in line with access requirements (large equipment, heavy lifts), support of other construction activities, such as vessels which need to be installed for piping erection to proceed etc.,

  • dates at which vendor drawings are required for engineering progress. More details about this in a coming post…

The schedule links all activities (Engineering, Procurement, Construction, Commissioning), which results in assigning each one a time bar. Such time bar is the planned period for the corresponding activity, with start and a finish dates. It will remain fixed for the duration of the project. If an activity has to be rescheduled, the new time bar will be called "forecast".

Once reviewed and approved by all parties: all contractor’s functions, the client etc., the schedule becomes the baseline schedule. It becomes the time reference against which the Project will be measured.

The baseline schedule is distributed to all disciplines: Engineering, Procurement etc. for them to derive their own, more detailed schedule.

 

The baseline schedule establishes the reference against which delay will be identified. The monthly schedule up-date will show when activities actually did took place and allow the comparison with the planned dates of the baseline. It will therefore evidence delays.

The monthly up-date is done by inquiry towards all project functions of the status of all activities: started? start date? finished? finished date? Actual start and finish dates are shown on the schedule up-date, next to planned dates. Delays can then be anticipated as soon as a planned start date is not achieved, and acknowledged when an activity actual finish date is past the planned one. Activities which are directly linked to the completion date of the plant, without any time gap (float) are called "activities on the critical path". Any delay to these activities will impact the Project completion date.

The Monthly schedule up-date, which allows to identify the activities in delay, is the first of the schedule controls.

The latter does not, however, show the overall picture. It indeed shows far too many activities, all being depicted in the same manner, whatever their significance to the project. Another control is required: an overall progress figure.

The latter is expressed as a percentage, from 0% at the Start of the Project up to 100% at its completion. Each activity of the baseline schedule is weighted respectively to each other, the total of all weights being 100%. The start and finish dates of each activity are been determined on the baseline schedule. Assuming a linear progress of the activity from start to finish, one obtains the planned progress of each activity at any date. Summing up, at a given date, such individual progresses factored by the respective weights over all activities gives the overall Project progress at that date.

Say a Project is made of 2 activities, of the same weight, the first one planned in January, the second one in February. The planned progress mid-February will be 75%.

The curve showing the planned progress over time has an S shape and is usually referred as the "S curve". The S shape comes from the fact that activities are slow to start and to get completed, and that the highest productivity (steepest slope of the progress curve) is usually encountered mid-way.

At regular intervals throughout the execution of the Project, the actual progress of each activity is investigated. The integration over all activities of the actual progress factored by the respective weights gives the actual overall progress. In the example above, let’s imagine that the first activity has started on time but has been completed 2 weeks late. The actual progress of the project mid-February will be 50% against the planned 75%.

Comparing the actual versus planned overall progress allows to identify a Project’s overall delay.

That being said, it may be so that the actual progress is above the planned progress but that a delay is to be expected on the project completion date, as one activity of the critical path is in delay.

A couple of key points for the accurate overall progress to be accurate. First of all the respective weighing of activities must be correct. As activities on a Project are very different in nature, one may wonder on what basis the respective weights are determined.

The common denominator is the monetary value of the item: Engineering, Procurement and Construction etc. For instance, if a Project costs 10m USD in Engineering, 50m USD in Supplies and 40m USD Construction, the respective weights of E, P and C will be 10, 50 and 40%.

The progress of Engineering itself is calculated by breaking it down into sub-activities, assigning each of them a weight based on the applicable commodity, which is engineering manhours in this case. Engineering activities mostly resulting in the production of documents, their status will be monitored by the issue of the latter. Intermediate progress steps are defined, such as "document preparation started" (30%), "document issued internally" (50%), "document intermediate issue" (80%) and "document issued for construction" (100%).

The sub-activities within Procurement are the purchased items. Their weights are their monetary value. Intermediate progress steps are defined, such as inquiry issued, purchase order placed, issue of main sub-orders, raw material delivered at the vendor’s shop, ex-works delivery etc.

The commodity of construction activities is the manhours of construction manpower. The sub-activities within Construction are the various trades: civil works, equipment erection, structure erection, pipe-work pre-fabrication and erection etc. Their respective weights are set on the basis of the required numbers of manhours.

If Civil works are estimated to require 300,000 manhours, Piping 500,000 million, E&I 200,000, the weight of Piping within Construction will be 50%. Applying the above E/P/C split of 10/50/40 gives an overall Piping weight of 50%*40%=20% etc.

It is essential that the manhours estimates of the various trades are accurate, not to underestimate one, leading to a miss representation of the overall construction progress. As estimates of manhours are the product of the work volumes and estimated productivity, it is essential that both be properly assessed. Work volumes change as design progresses, while estimated productivity needs to be checked, as soon as the activity starts, against actual one. It may therefore be necessary to re-set the respective weights at some point of the execution in order to get the true picture of the total work to do and therefore balance to be done.

The measure of the progress of the construction trades is much more difficult than that of Engineering and Procurement due to the very large number of sub-items. Where there are only a few hundreds or so Engineering documents produced and equipment/material types procured, each construction trades involved items by tens of thousands.

The progress must nevertheless be calculated down to that of these individual work items, e.g. steel members erected, piping joints welded, weighted according to required manhours. Intermediate progress steps are defined to give a precise progress figure, by accounting preparatory work. Piping works, for instance, would include the following steps: shop welds, field welds, supports installation, painting etc.

Inflated progress reporting from a contractor is common, particularly as it is linked to payments. In order to avoid this issue, it is essential to both get down to the individual work items and to define clear work steps which are either done (1) or not (0). This binary approach avoids discussion on whether the progress of an on-going activity shall be counted 30%, or 60% etc.

Difficulties will come along, including the up-keep of and up-to-date list of work items. The latter indeed comes from engineering and keeps changing as design progresses. Another issue will be to have sufficient supervising resources to make a thorough monitoring of the completion of work steps of individual work items.

This is nevertheless the only way to ascertain the progress. The spreadsheet shown here was designed and used successfully by a piping supervisor to this end.

There is no alternative to this painstaking work to be in a position to check a contractor’s claimed progress figures… but it is well worth it as it tells you where you really are and how fast you are moving!

Note that not only the overall progress figure of say, Engineering, is available but also the one of a sub-division. This allows, for instance, to identify that, although Engineering as a whole is late, its key disciplines are ahead, and the delay comes from secondary disciplines which will not impact construction activities and the overall schedule etc

To summarize, in order to control the schedule one must implement both controls described above:

  • the progress figure, which allows to monitor actual progress versus planned. It is important to understand the limitation of this control: it merely reflects how much work has been done at a certain date compared to what was foreseen by this date. It does not allow to tell whether the project will be completed on time or not. Indeed, a project requires activities to be carried out in a certain sequence as some activities depend on others. If activities are done out of sequence, actual progress may be more than planned although project completion date can be expected to be delayed.

  • the monthly schedule up-date, which shows whether individual activities are on-time or in delay and, through the logic that links the activities, the impact of individual delays on other activities and the completion date



Comments(8)