If your Program of Works is inline with the progress at site then you dont need to change the logic and the durations.
I agree with Gary, that it is diffcult to come up with a detailed program of works from the start or within a month unless the project is identical to a previous one. But your high level scope should be identified and it should be futher developed when you have more details.
Revising network logic drafts the clear picture of project in terms of determining critical path and especially in case of doing delay analysis .
Necessary substantiation is enough to resolve this issue
Pro-gramme when developed it stays in ground state due to contingency involved in the project the behavior of the project tends to move in excited state which might leads to increase in duration ,increase in resource strength ,logic revision, shortening the critical path and so on.
The same activities will still be there, so you can still report project status vs baseline.
More than that, you can report PROJECTED progress vs baseline, which in many ways is more useful.
What I do is insist the contractor supplies a change log with each update, detailing what logic, durations, etc they have changed and why.
The original baseline is nothing more than a best guess at project inception. Especially for EPC contracts where the final solution has not yet been designed, it is quite unreasonable to expect the contractor to know accurately how long activities will take, or even in some circumstances, what activities will need to be done.
In fact, I often reccomend the project is rebaselined once design is substantially complete. So long as client accepts the new baseline, and contract dates are still adhered to, all it does is give you a better, more accurate baseline.
Those people who say that making changes to future activities in a schedule should be banned are totally wrong.
It is utterly ridiculous to insist that a schedule should continue to contain incorrect information after it is known to be wrong.
All it does it ensure that the future part of the schedule, which is the MOST IMPORTANT PART, is useless.
Some clients insist that this rule is written into the contract. I imagine they do this because they are worried that if they allow the contractor to make changes to the schedule, the contractor will do so in order to hide delays.
There is no value to the contractor in hiding their delays becuase eventually these delays will become apparant, and they will be found out to not only be in delay, but also to be liars.
It is also impossible for a contractor to actually control the project without having an accurate forecast of remaining works. So if they are not allowed to make required changes, they are forced to have 2 versions of the schedule: 1 they report to the client wiothut changes, the other they use to run the job. This, of course, makes him a liar anyway and makes the schedule reported to the client utterly meaningless.
This is probably the most frequent, and most stupid, mistake clients make with respect to scheduling. I really dont understand why it happens so often.
But if we allow changing the durations,logic etc for the activities which are planned beyond the data date,then the update is not on the baseline schedule,but on a new schedule,in this case how can we report the project status compared to the baseline.
Spider Project is most functional and powerful professional project management software.
The first SP version was launched in 1993 and since then it has been constantly improved. Today is used in 34 countries though most Spider Project customers are in Russia. Spider Project offers numerous unique functional features and is the only PM software that optimizes resource, cost, and material constrained schedules and budgets for projects and portfolios.
The unique features of Spider Project include Quantity Based Scheduling, Conditional Scheduling, Skill Scheduling, Optimal Resource, Cost and Material Leveling, Resource Critical Path Calculation, Cash and Material Flows Calculation and Management, Trend Analysis, Advanced Risk Simulation and Analysis, Calculation of Success Probability Trends, Calculation and Management of required Project Time and Cost Buffers, Application of Corporate Norms, Management of many Parallel Budgets, Multiple WBS and many others.
Spider Project was and is used for management of many large scale programs in Russia, including $51bln construction program for 2014 Winter Olympic Games preparation.
The application areas where Spider Project is successfully used include Aerospace, Banking, Construction, Defense, Energy, Engineering, Infrastructure, Manufacturing, Metallurgy, Mining, Oil & Gas, Railways, Retail, Shipbuilding, Software Development, Telecommunications, Utilities, etc.
P6-Auditor - Display information from Primavera P6 audit tables in a user-friendly format
Unifier-Archiver - Extract and archive important documents and attachments from Primavera Unifier
Unifier-Loader - Load data into and out of Unifier via Excel
PCM-Loader - Import data into Primavera Contract Management with flexible and secure, template-driven Excel spreadsheets
PCM-Archiver - Extract and archive important documents and attachments from Primavera Contract Management
PCM-Unifier Migrator - Automatically transfer live and historical data from Primavera Contract Management to Primavera Unifier with ease
Create Radically Better Construction Schedules with ALICE Technologies
Use the power of AI to create construction schedules that reduce risk while cutting costs and build time. With ALICE, develop the ideal schedule during preconstruction -- or recover projects that are off schedule and over budget.
Dear Kumar,
If your Program of Works is inline with the progress at site then you dont need to change the logic and the durations.
I agree with Gary, that it is diffcult to come up with a detailed program of works from the start or within a month unless the project is identical to a previous one. But your high level scope should be identified and it should be futher developed when you have more details.
With kind regards,
Samer
Hi Kumar
Revising network logic drafts the clear picture of project in terms of determining critical path and especially in case of doing delay analysis .
Necessary substantiation is enough to resolve this issue
Pro-gramme when developed it stays in ground state due to contingency involved in the project the behavior of the project tends to move in excited state which might leads to increase in duration ,increase in resource strength ,logic revision, shortening the critical path and so on.
Pro-gramme cannot be 100% concrete at all times
The same activities will still be there, so you can still report project status vs baseline.
More than that, you can report PROJECTED progress vs baseline, which in many ways is more useful.
What I do is insist the contractor supplies a change log with each update, detailing what logic, durations, etc they have changed and why.
The original baseline is nothing more than a best guess at project inception. Especially for EPC contracts where the final solution has not yet been designed, it is quite unreasonable to expect the contractor to know accurately how long activities will take, or even in some circumstances, what activities will need to be done.
In fact, I often reccomend the project is rebaselined once design is substantially complete. So long as client accepts the new baseline, and contract dates are still adhered to, all it does is give you a better, more accurate baseline.
Those people who say that making changes to future activities in a schedule should be banned are totally wrong.
It is utterly ridiculous to insist that a schedule should continue to contain incorrect information after it is known to be wrong.
All it does it ensure that the future part of the schedule, which is the MOST IMPORTANT PART, is useless.
Some clients insist that this rule is written into the contract. I imagine they do this because they are worried that if they allow the contractor to make changes to the schedule, the contractor will do so in order to hide delays.
There is no value to the contractor in hiding their delays becuase eventually these delays will become apparant, and they will be found out to not only be in delay, but also to be liars.
It is also impossible for a contractor to actually control the project without having an accurate forecast of remaining works. So if they are not allowed to make required changes, they are forced to have 2 versions of the schedule: 1 they report to the client wiothut changes, the other they use to run the job. This, of course, makes him a liar anyway and makes the schedule reported to the client utterly meaningless.
This is probably the most frequent, and most stupid, mistake clients make with respect to scheduling. I really dont understand why it happens so often.
Thanks for your views.
But if we allow changing the durations,logic etc for the activities which are planned beyond the data date,then the update is not on the baseline schedule,but on a new schedule,in this case how can we report the project status compared to the baseline.