Is it common practice to have a internal control schedule for a project?
- Created
- 9
- 6
I did several projects before, we have a master schedule for the project to control the execution. The schedule is also the one we submitted to the client. So we only maintain one schedule.
Now, I 'm in a new company. here we have three schedules for each project. The first one is the internal control schedule which keep some time contengency against the contract, developed by the headquarer of the company. This control schedule only contains some major activities, it does not cover the entire scope of the contract, and is not logic driven.
The second one is the execution schedule developed by the project organization based on the control schedule.
The third one is the schedule submitted to the client,which do not have any time contengency.
So the project organization need to maitain three schedules, a lot of duplicate work.
Is this kind of schedule management common? any advise?
9 replies
Oldest first- 0Kannan CP ·
Hi Zhang,Sometimes, other
Hi Zhang,
Sometimes, other than the schedule submitted to Client, an internal schedule will be developed by the Contractors. It is tracking schedule, ghost schedule etc. Main pupose of internal schedule is to execute the works in the best possible ways incorporating all potential risk factors-both threats & oppurtunities. Also will be helpful to control the activities of sub-contractors using this internal schedule. Contractor will try to finish all the works ahead of schedule submitted to client, by closely monitoring the internal schedule with all best efforts.
BR
Kannan
- 0Vladimir Liberzon ·
Hi Zhang,it is usual and
Hi Zhang,
it is usual and recommeneded practice for Spider Project users to create and to maintain three project schedules:
1) Contract schedule that may be considered as pessimistic. This schedule includes required contingency reserves and cost estimates are contractual.
2) Project Control (expected) schedule based on expected estimates of activity durations, costs (expenses) and resource availability.
3) Optimistic schedule that is based on aggressive estimates of project parameters.
Optimistic schedule is used for project workforce management.
In Spider Project these three schedules can be linked so that when you enter actual information in any of them all three will be updated automatically. So the need to duplicate work does not exist.
Besides, Spider Project calculates probabilities to meet target parameters with any update that is very helpful for project management.
- 0Rafael Davila ·
My approach is to keep two
My approach is to keep two versions:
1) The Contract schedule that more often than not cannot be used for management at the site as the Contract Schedule is frequently lagging revised logic and activities necessary to manage the project. In most of our jobs the client never approve revisions to the contract schedule on time for it to be useful for site management while the project finishes with no court claim.
2) An Optimistic schedule that is based on aggressive estimates of project parameters we use for project management. It will include those activities not yet in contract schedule but that are required to manage the schedule no matter if approved or not. It will not include allowance for rain days as it is not a good idea to plan short term activities assuming it will rain before it happens. It will not include contingencies as it is not a good idea to include them within this schedule because of Student Syndrome and Parkinson's Law. The Student Syndrome is tolerable for a few, non-critical tasks. But when the number of critical tasks affected increases, then whole schedule will be at risk. Parkinson's Law is the adage that "work expands so as to fill the time available for its completion".
It is necessary to target for some early completion in order to increase the probabilities of meeting contractual requirements, otherwise you will be targeting for failure. The period between planned completion and completion date or Terminal Float is owned by the contractor under the contract and is mandated in some European contract models such as the NEC to the point if there is no terminal float shown the schedule might be rejected.
USA practice is the opposite, terminal float is usually prohibited and interpreted as a reduction in contract time; therefore we have no other option than to make use of Ghost Schedules if we want to increase the probabilities of meeting contract dates. This schedule does not needs to be shown to the client [1]. This schedule will include contract schedule activities plus a few additional not yet included, in this way we keep actuals of these activities that while not in the contract schedule are actually happening. We use this version as the basis for updating the Contract Schedule as it will include all activities within both versions and synchronize updating using Spider Project capabilities for doing so.
[1] Ghost Schedule- In a significant case concerning Ghost Schedules and their use, Jackson Construction, Inc. v. United States.7 the U.S. Court of Federal Claims stated that a contractor is under no obligation to advice owners of its planned early completion [Ghost Schedule].
- 0Stephen Devaux ·
A copy of Rafael Davila's
A copy of Rafael Davila's reply should be framed and hung in every project office, and taught in every planning AND contracts course!
Personally, I learned the term Ghost Schedule! And I love it!
As a West Indian, I'd also like to nominate a new term: Zombie Schedule. It's one that is so outdated as to be dead -- yet some on the project are still trying to use it! This is very common with US aerospace/DoD contractors.
Fraternally in project management,
Steve the Bajan
Log in or join to reply
ProjectControls.com is free to join. Members can post questions, reply, vote and follow discussions.
Existing members: your original username and password still work. Forgot password?