Tips on using this forum..
(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?
(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.
Methods of Monitoring progress
What is the best method of monitoring progress ?
I use three methods
1) Static progress - where you update the bars with % complete only and draw a line from the progress date to indicate position on programme.
2) Critical path - where I update the actual starts etc as well as % complete. I also baseline the project to give a comparison.
3) Planned versus actual "S" curves
I use MSP for the first two and export the data to Excel for the last one
Andrew
I beleive that Edgar was the first to comment and S-Curves and EVM are stil relevant.
not sure what you want to use ?
Dear All,
Better Progress Measurement concept is given in a simple and clear manner in the following YouTube Link, which may be of your interest.
Regards,
R. Jagadeesan
you can and should do all 3 in primavera p6
Dear All,
Please refer videos of this channel for better Monitoring of Progress:
https://www.youtube.com/channel/UCJ1QCqXRumD34CFwYPb1dmw
Regards,
R. Jagadeesan
Ive best progress monitoring form. from my master at Talisman rite now...
At this moment, everybody outside there using his format......
this is my email...aizamcapri@gmail.com
I work for a client organisation, we generally award Lump Sum contracts, have schedule of milestones listing CONTROL ( No LD) KEY (LD but refundable once MAJOR milestone is achieved) and MAJOR milestones ( LD non refundable)
The Contractor submits his monthly invoice based on BQ with total amount payable, this gets verified by QS & Site PMC.
I check if KEY or MAJOR milestones are late or not for the month if late then LD amount is deducted from monthly invoice.
This system is cumbersome in that EOT must be upto date ( generally its not!!)and revised milestone dates included in milestone schedule. Unfortunately, the organisation and its procedures cannot be changed.
Just thought I participate showing my frustration!!
Rgds
Dyes
for some other projects our company did in Hong Kong, we let contractors define milestones & % payment during tender.
well consider the future value at the completion date for the contract. that means contractors who ask less payment at the beginning have advantage to win (actually the payment do not have strong link to the quantity of work for each milestone, milestone is just a check point whether to pay or not.
Im not sure its a good approach,just for your reference
The idea - not to measure volumes because the volumes that are represented by each milestone were defined in design. If the quality is accepted and the object is approved then the cost of approved works is known.
Regards,
Vladimir
Great. I agree. Who determines payment milestones, the contractor or the owner?
I think they should be proposed by the contractor and approved by the owner, based on specific criteria established by the owner before-hand. Which criteria would you use?
I support your approach. This way you motivate the contractors to achieving the results - not just reporting volumes and, besides, the works are not divided into more or less profitable. Both the client and the contractor have the same goals and many potential issues are avoided. We use the same approach and it works perfectly.
Best Regards,
Vladimir
One of the benefits of the milestone payment system is to avoid actual quantity caculation, the payment is based on visual achievement(milestone).
I think we can select some importane milestones as incentive/LD milestones for reward/punishment. If we load cost/resource and use earned value for schedule index, then we will lost the benefit mentioned above.
For the project I did, the total duration is around 4 years,
and we have payment milestone every 2-3 months, So we still have strong control to the project. we do not have punishment, contractor will not get the payment if the milestone is not achieved, no matter how many actual works have been done.
Please allow me another question..Is there any software designed for commercial or political exercise?
thanks
Do you think it would be practical to add an schedule performance index factor to milestone payments, to reward adherence to the work plan or "punish" deviations from it?
In which stage of the Project you consider things (in general) reasonable, equitable & fair? Can a level 1 program covers the statement? And whats the difference between a commercial exercise & a cost control exercise?
Thank you.
Ive also used milestone payment system for a lumpsum project.
I prepare the baseline schedule, then load cost together with commercial guys,then calculate percentage payment for each month. then prepare a milestone (most of them are on critical path) list link to percentage payment.
We put all these in the contarct. As the contractor achieved a milestone we pay the relative percentage.
during construction we never calculate actual work quantity,never argue with contractor of actual quantity, it saved a lot of time and resource.
I know the payment was not accurate, but it works well. It provie a strong control of progress, also the safety of the payment.
The Simple Answer is "NO", if you can avoid it.
There is no involvement of accounting whatsoever unless we have a case of claim for "pre-tested and standard supply only” items in the project, in which case some accounting records may be necessary to justify the "earned" value.
In most construction projects, the payment on attainment of milestones for which some predetermined "earned value" have been set(as in the various stages put forward in Norzuls post), should simply be triggered by the issuance of certain document/s like certificate of completion, or closing out of the final NCR/s or approval/passing of the final item in the ITP’s etc to signify their stage completion.
Or if interim partial payment is desired, by the measurements of a single “salient” measurement parameter like pipe lengths or cable lengths, as long as they are agreed in each case beforehand. These can be done by Site Engineers or Site Supervisors.
All these are measures designed to remove the subjectivity associated in other methods of determination of progress payment, although to call them EVMS is not strictly correct. This is really more a "commercial" exercise rather than a cost control exercise.
Nontheless, so long as they are considered reasonably equitable and fair without both having to “bust the guts” to agree on measurement(accounting ??) of the minutest of details, the purpose of the exercise has been served.
Thats what matters.
Are you saying that it is necessary to integrate planning with accounting in order to get the best or accurate results in taking actual percent progress?
That way both the contractors and the owners interests are served, since in order to get paid on time, the contractor will focus on what should be done to keep the schedule on track.
I would suggest a milestone payment combined with a reduction factor based on a schedule performance index: The contractor will be paid when the milestone is achieved, but the amount will be reduced if percent complete is below scheduled.
There is no absolute right or wrong in your proposal, after all it is just simplification of the payment and measurement for the convenience of all parties involved.
If all parties can live with it, it must be alright.
After all this is strictly not any Earned Value Management(which is a cost control and project control process), but some semblance of "earned value" presumedly calculated to trigger off payment/s on progress upon reaching certain targets agreed.
Agreed Weightage (based on estimated value of the proposal)
1) TOTAL PROJECT (EPCC) : 100%
2) Engineering : 10%
3) Procurement : 30%
4) Construction : 40%
5) Pre-Commissioning : 10%
6) Commissioning/Performance Test : 10%
For construction, it will be further breakdown into piping, mechanical, civil, instrument, and electrical. The weightage for each discipline will be based on estimated construction manhours.
Piping progress will be further breakdown into several system. Each systems (for example steam piping) progress is based on achievement of the milestone i.e.
1) Pre-fab (25%) - based on actual dia-inch vs total plan
2) Erection (10%)- based on actual meter length vs total plan
3) Welding (25%) - based on actual dia-inch
4) Supports (10%) - based on numbers
5) Painting (5%) - basedon length
6) Valves installation (10%) - based on numbers
7) NDT (5%) - based on numbers
8) Pressure test (10%) - based on pressure test package
The above will be mutually agreed between client and contractor.
thanks
norzul
I thought the best measurement of actual "value" spent on any project should be those invoiced amounts from internal as well as external suppliers inluding those prelim items direct costs.
So far as measurement of the earned value, it has been argued that it should be on the "perceived" level of designed performance achieved(the most simplistic being 0% all the way until the machine is tested and operational i.e. 100%) which despite being representative of the "value" actually in the Clients possession when paid, may not be practical for Contractors cashflow position in most cases. In practices we have found all kinds of rules of intermediate assessment which have more practicallity than accuracy.
The measurement by % of physical progress is what have been encountered most in my experience if we do not wish to be compounded by "subjective" value judgement. These earned value measurements can still be as complex and tedious as any physcial BQ-type quantities measurement limited only by your desire for precision and resemblance to the physical reality.
Of the many quantities measurement, manhours is most popular being able to cut across different discipline and trades/construction elements as in the case of complex equipments or composite construction with varying degree of pre and post assembly before and after delivery.
If you so chose to have man-hours as the parameter of such measurement(as in the case you cited), you can start by determining beforehand the conversion ratio of each such machine-hour into equivalent manhours, in order to have the standard manhours as the common denominators. The value per machine hours divided by the average value of the manhour should normally be adequate representation of the contribution of each plant in terms of the value "forecast" and "earned".
Your baseline could then be calculated from the forecast manhours added to the equivalenet manhours converted from each forecast machine hours. The measurement of the progress of the "earned value" from man and plant records would then be possible, but I thought wouldnt it be accurate to call these "actual hours" rather than "earned hours" ?
For example, some activities demand very little man-hours and high cost equipment. If earned value is measured in man-hours, this activity´s contribution to percent complete and therefore to payment will be smaller than it would be if the cost of the equipment determined its progress.
You are right. That’s why one should always look at both indicators side by side: percent complete and end date forecast.
A low percent complete does not necesarily mean a delay at completion, as long as critical activities are ok. and viceversa: even when percent complete is high, you can get a delay, if work is not focused on critical path activities.
If not considering critical path, S-curve or other report may give a wrong picture.
e.g. you did a lot on non-critical acitvity, but delay on critical path. the s-curve may show you actual is bigger then planed ( you are ahead of schedule) but actually the project is delayed
Appreciate if you could e-mail me the sample of your report for reference. It most probably useful for me.
Shahrol Sabaruddin
Hi. Each week’s update produces a projection of the project’s finish date. I plot it against time (weeks).
Same thing is done with other indicators: percent complete, productivity, concrete and steel waste, man-hours, etc.
The idea is to have different plots in the weekly report, which let management see not only the "picture" - what happened last week, but the whole "movie": what the performance has been all along the project, so they can easily spot trends and correlate the behavior of different performance indicators.
But there is one more thing to control - evolution of contingency reserves. This evolution can be estimated using risk simulation and is harder to implement but most powerful.
What do you mean by Finish Date Evolution Graph
What is its significance ?
Makes me realize I’m on the right track with what I’m doing. My weekly report are two pages long, containing:
Executive summary:
-work finished last week.
-work started last week.
-finish date and percent complete status, delay causes and trends.
-critical path changes and trend.
-corrective actions: results last week; suggested next week.
-prospection: work to start next week; one month lookahead.
Full color Graphs:
Percent complete S curve: scheduled vs (actual+to finish).
Summary bar chart.
Finish date evolution.
Schedule performance index.
That report goes to managment meetings. For field managers, I append a 3 to 4 page detailed printout (built using filters and layouts).
Here what you say about our contract people and indeed what the contract says about what the progress report should contain.
I feel internal and external progress reports require different approaches.
Internally we want the key factors exposed to the project team. This may or may not be what we want to tell the client.
Often the contractor never makes an internal report because he is too busy satisfying the clients requirements. This in my opinion is flawed logic.
As to the clients report, sometimes lack of conclusions or bending reality can be helpfull later on when the "I told you so" scenarios pan out. Remember though that the client has structured his reporting criteria in his favour, ie it tells him what he wants to know not neccassirily what the contractor wants to know.
As to contract matters in the progress report I would express some caution, often the report becomes a place where claims notification and analysis is played out. I feel this is both contractually and practically the wrong place for this. However if the contract requires submission and approval status, Requests for info, Varitions etc to be logged in the progress report so be it. It should not deviate from the conclusion that "if we carry on the way we are going we will finish early/late"
In conclusion I would suggest that the contractor produces two reports one for internal action one for external. If its a contractual project get the commercial guys to review what you are saying and make sure you lead the PM through the report before its submitted otherwise it will most probably bite your bum in the future.
Clive
I fully agree with what you said. But sometimes, especially when reporting to clients, contractors planners and execution people are not the only ones dictating what should be reported and what shouldnt be reported. Contracts people sometimes are very demanding in this case. They would want to include some "cya" reports which may not be interesting/relevant to read/discuss now but could be very useful contractually in the future. Another reason for this is, to comply with what the contract is saying.
Just my thoughts on the topic.
Cheers,
Se
Fully agree with yu....thats what happening to us now. Many reports but whether effective or not..
norzul
Many many progress reports I read are enormously thick containing pages and pages of print out. Often these are filed and nobody reads them. If this is happening to you ask yourself why.
When reporting on progress we must firstly assess what are the project drivers. On a non restrained programme which is logically linked these will usually be the activities lying on the critical path. These activities when reporting progress must be the ones that are critically analysed as delays here will delay the planned completion date.
I would therefore suggest that when reporting progress these are stripped out of the programme and discussed.
ie "activity 7 is in delay by 7 days caused by X. This in turn will have a delaying affect on A B and C. If the delays to X are not corrected the following are the likely consequences. In turn the following actions could be taken to resolve this anticipated delay."
The above paragraph is a succinct conclusion of progress and can be readily understood by the reader.
Equally I favour trend analysis on S curves for key activities, say frame construction. How much concrete should we have poured, what have we poured, what happens if we carry on the way we are. Again the people reading this information can readily asses where the problem lays and what must be done.
Equally trend analysis can be undertaken for key subcontractors or procurement activities to assess how the subcontractor is performing. Trend anmalysis provides, if used correctly an early warning system, and that to me is the most important aspect of the progress report. If we can advise on potential delays before they become a delay we are doing our job.
However any report is only as good as the data collected. I try and go to the lowest denominator for data collection (ie Foreman/site engineers). This provides real time data collection and takes the grunt work out of progress reporting. It also, if set up correctly enables the foreman to see how he is doing. If he has " bought into" the programme and has had an input into its creation he wont want to fall behind and will provide, all be it biased information as to why delays are occuring.
So in simple terms progress reports should be:
Based on grass roots data collection.
Be easy to read
Provide analysis as to where the project is headed
Provide a commentary as to the reasons for the delay
Provide a commentary as to possible recovery measures
Provide a succinct conclusion.
The use of graphics should be amplified and I agree with Charlie Jazz it up with colour and go easy on the print outs if you must, put them in an apprndix.
Just a thought.
Clive
This time I agree with you. We need inguinity in the way we monitor our schedules/project. In this way our deliverables will not be boring to our project managers.
On way of doing this is to assign a lot of colours to our reports. Attractive colours that will capture the imagination of the project team.
In addition there are software available in the market that will add three to four dimensional approach to project planning. This software will show in addition to dates the physical aspect of the project where the dates has relevance.
Cheers,
charlie
I always use General Arrangement Drawing to plot the actual works performed and I evaluate directly the progress based on such plot drawing. Our Management also interested if we show not only s-curve or barchart but the figure of such physical progress.
Currently there is some 3D Plant View product to show progress physically but its too late because of late in design.
Thks
contingency reserves include cost and resources, not only time. Besides they shall be calculated and controled.
There is an interesting result of adding contingency reserves to the planned schedule - baseline schedule does not exist and Earned Value Analysis is not applicable.
Vladimir
I’ve lately included in my construction schedules activities related to acquisitions (at the beggining) and delivery (at the end), which act as buffers in the sense that on update, I check whether they become critical and if so, adjust their duration and make a warning in my weekly report to let the job manager know that available time for a certain negotiation or delivery has shrunk as a result of some particular activity or chain being delayed.
I know that`s not exactly what the critical chain people intended when they proposed buffers, but I think it works.
Ernesto Puyana
Earned value analysis does not work properly because baseline schedule does not include buffers. S-curves do not include buffers too.
Regards,
Vladimir
In my case, I perform no as staff, but an outside consultant in charge of schedule development (with staff input) and weekly monitoring and control of schedule. So I dont get involved with cost control.
I know earned value could be tracked by hours not necesarily by dollars (pesos in my case), but Ive found that generating S curves from percent complete calculated by Suretrak from activity durations (see Paul Harris) is quite adequate and much simpler to manage. Specially when we`re talking about 1000 to 4000 activity schedules.
If anybody wants to check my report format, Ill gladly mail it.
With regards why "Earned Value" was not mentioned I believe is because we still like to keep finances seperate to programme and possibly not reveal actual costs to others outside the senior project team.
This is my experience anyway.
Then what is the best method of monitoring progress, regardless of the size of the project?
And Why nobody mentioned EVA report?
In S currves we have only "Plan" and "Fact"
How about Earned Value?
I perform a weekly job visit to update start and finish dates as well as percent complete and remaining duration, activity by activity. upload that information to the Suretrak schedule, compute and produce several reports, using layouts and filters, which I export to a spreadsheet (Lotus, by the way, that produces much better graphics that excel).
This report includes an S curve, a summarized gantt chart and a detailed analisys of activities started, finished, pending, critical path and prospective analisys.
Might sound like a lot of work, but a well designed format makes it pretty straight forward.
S curves normal reflect the "planned" v "actual", for this to be accurate they need in incorporate agreed EOTs. Otherwise you are monitoring a current programme/method of work against one that has been revised many times.
Baseline and asbuilt programmes also work hand in hand with the S Curve progress reporting. And it would be advisable to combine these together in a 3/4 page progress document normal produced in Excel.
Hope this helps.
David
Replies