Hi Amro,
Dan Melamed has just drawn my attention to your post and asked me to add my thoughts. Dan spoke about production in his reply. Here I will talk about Maintenance Turnarounds. I stress that this is just my opinion.
I came to Turnarounds from Capital Projects. When I first started working in them I was surprised at how few of even the basic cost estimating and progress control practices had been carried across into Turnarounds. Since then, the industry has largely adopted things like stage gates for turnarounds; and I've published some papers trying to transfer cost estimating ideas from projects to turnarounds. (Including working with AACE colleagues on RP112R-20 and RP116R-21). Next on my "to do" list (when I can get some time) is transferring progress control ideas over from projects to turnarounds.
With regard to progress tracking on maintenance turnarounds, in my experience many turnaround teams are still practicing simple progress "accounting", in that they merely record what was spent in this shift, and what work was achieved. There is rarely an attempt to compare the "earned versus burned", and then forecast future progress, and then use that forecast to take corrective action. Obviously, this leads to situations where cost or schedule blow-outs don't become visible until it's too late to do much about it.
I have been trying to gently promote the concept of earned value to turnaround teams for quite some time, but with limited success. When I've brought up the topic of using "earned versus burned" with those teams that are not yet using it, the responses I've got have tended to be:
- We're unfamiliar with the technique
- and/or it seems much too complex to implement, especially when we're working on reporting shift by shift, not week by week, as a project might.
Then there's also the issue that some sites outside North America are using Unit Rates or even Lump-Sum and aren't always tracking the data to enable a calculation.
In my opinion, "earned value" could usefully be used on turnarounds, but with the proviso that any controller coming to a turnaround from projects has to recognize the much, much faster pace of field execution on a turnaround when compared to a project. A project may have a construction period of years, whereas a turnaround is usually around a month or a month and a half. Hence there needs to be a much faster process of receiving, plotting, calculating the data and reporting out the results. Data collection and data processing need to be done quickly at the end of each shift.
In terms of whether the contractors can report their hours spent by task, many of them are used to the concept from working on projects, so that shouldn't be difficult, but the timesheet codes need to be set up. In terms of having progress norms for percentage complete of a task, this is informally available at most sites, but would probably need a little "formalization" before the work started, so that everyone is clear when they can, for example, declare a task 50% complete, etc. The formalization would also need to recognize the multitude of small (in project terms) work tasks that make up a turnaround scope, compared to a project. (e.g. refurbish x number of individual valves, as opposed to install Y metres of pipe.)
I hope that helps.
------------------------------
Gordon Lawrence
Den Haag
Netherlands
+31 6 81 80 69 23
gordon_r_lawrence@hotmail.com------------------------------
Original Message:
Sent: 12-27-2021 06:22
From: Amro Ahmed
Subject: Operation and Maintenance Projects Earned Value
Hi All,
Earned value is very effective and powerful for Construction projects, how about operation and maintenance projects?
Is it the most effective methodology for progress reporting for operation and maintenance projects, please share your views
------------------------------
Amro Ahmed PSP
Pmo Leading
Puplic work Authority-DNO&M/Pstech
Wakra
97444659289
------------------------------