(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.
I always put in my report how many days the project (RC Works) is ahead or behind. Me and the client agreed to determine that by comparing the planned planned concrete quantity usage against actual concrete quantity usage. We have been doing that for a couple of months now.
But now the client requested that we change the way we determine it. He wants me to compare the contract completion date and the forecast completion date. Ofcourse I will get that from the baseline programme updates, which is update every week.
The problem is, if I'm making a straight-forward update, no re-sequencing, no change in predecessors/sucessors, etc., it will be very easy to say if we are ahead or behind by comparing the completion key date to the forecast.
But everytime I update, there is always re-sequencing works, change in site works execution, reduce in float time, etc. Because of that I can always maintain the completion key date same as forecast completion (we are still in the early stage so it is easy to do that for now).
So eventhough we are behind by a week or two in physical works (concrete quantity usage), i can still show in the programme that we can still meet the completion key date so there will be no delay at all.
How to explain that to the client.
Printer-friendly version
Send to friend
RE: In such case your curve will look marvelous but your job will be in delay ...
A complete S Curve Set shall consist of:
If the project is projected to finish on time or not will be visually visible, no way it can be overlooked. If you want to show all contractual milestones you can generate the S Curve set for each path, this shall be at a single click of the mouse by simply selecting the appropriate phase that makes the path to each contractual milestone if your software is capable of handling multiple WBS dictionaries, if not there might be an alternate way provided within your software. It is not always the end of job the only contractual milestone, all do matter. The same goes with relevant phases such as concrete works.
If you are comparing progress against a single Early S Curve you will always be behind, If you are comparing against Baseline Early and Late you are showing half the picture, that you are in between early and late Baseline is no assurance you are on schedule, it is the projected S Curve that will tell, if you are not showing projected S Curves essentially you are telling nothing.
Top management usually prefer graphic reports that are easy to understand and remember. A listing of activities is good for when they want to see the details after looking at the S Curves and finding out a job is not on schedule.
What reports to use will depend on the target audience. For a PM the S curves will not be enough, for a client anything more than the S Curves might be too much if the project is on time as a fact disclosed with a full set of S Curves.
Ronn,
As suggested by others, a commodity S-curve for concrete may help in persuading the client that works are progressing as per the programme (if this is the case).. However stepping into the client's shoes I would also ask for thorough critical path programme updates primarily because you can pour vast amounts of concrete in 'convenient' areas which are not critical and for one reason or another have critical areas without due attention.. In such a case your curve would look marvelous but your job will be in delay..
Hope it helps,
Alex
RE:How to explain that to the client.
I suggest the use of the "Banana Curves" for Concrete Volume in addition to any other such as Payment Amount as per project breakdown, your costs keep them confidential.
If you compare Contract Baseline curve with actual schedule S curves (early and late make a banana) and your actual projection is earlier than the baseline it will show you are ahead.
If the client understands S Curves even when they will not show the details he will know they are the result of the details and will understand it saving you having to explain it on every update.
Be aware under the presence of negative float the S Curves do not make sense even if they have not yet reached the point where late curve meets early curve and switches to be on top of the early curve. A twisted banana got to hurt.
Good luck.
Ronn,
I would report:
1) Number of days actual delay up to reporting date
2) Number of days forecast delay to project completion
3) Any changes made to the planning of future works since the last report (additional resources, changes to sequence, etc)
Cheers,
G
Hi Mike,
The baseline programme is resource loaded with concrete quantity. The programme is divided into floors then portions. Each activity represent a portion and the concrete will be casted on the last day of the activity. So for each week we will know how many portions were completed.
But we will not used concrete usage to know if we are ahead or behind the programme anymore.
My client wants to use the ctitical path in the updated programme to determine that. But as I said, when I update the programme, I make it sure to show that we are still on time by re-sequencing activities (of course discussed with my PM) and reducing the float in some activities. So is it ok to say that we are not behind even though the concrete usage curve says that we are behind.
Hi Ronn
You should set up the concrete usage as a resource and input each volume to the relevant task.
I suspect however that you have multi trade task bars - Rebar - Form - Concrete - Strike all in one bar.
Then you are relying on some sort of theoretical weighting to apply progress.
Your comarison of estimated total concrete compared with poured concrete relies on:
1. Accuracy of estimate
2. Wastage factor
It does not take into account programme float.
To summarise when comaring progress with actual concrete usage you are not comparing Like for Like unless you can resource the programme.
Best regards
Mike Testro
Email: PPadmin@planningplanet.com
Replies