(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'm struggling to identify the best way to implement a baseline change to my P6 projects once they have begun to be progressed.
The scenario I'm considering is one in which the Baseline Schedule needs to always match the contract. Part-way through execution, with substantial updating having been made to the Current Schedule to reflect actual progress and actual costs, a contract change is negotiated, one which involves substantial change to the schedule logic, durations, and resources. Clearly, one wants to reflect those changes both in the Baseline Schedule and in the Current Schedule.
One way to do so would be to detach the Baseline Schedule from the Current Schedule, make the full set of changes twice--once to the Baseline Schedule and once to the Current Schedule--and then reattach the Baseline Schedule to the Current Schedule. Clearly, this is fraught with the opportunity for error, and seems like a unjustifiable inefficiency. Surely there must be a way to make the changes only once.
Presumably, the second way to go is to make the changes to the Current Schedule, then make a copy of the revised Current Schedule, and attach that copy as a new Baseline Schedule. However, clearly that new Baseline Schedule will contain all the progress updates and actual costs of the Current Schedule from which it was derived. I haven't attempted this approach yet, and thus do not know what the consequences are, beyond the obvious that all variances for work to date are lost.
From my review of various posts, it seems that a third approach would be similar to the second, but that after making a copy of the revised Current Schedule, one removes all progress from the copy, then attaches it as the new Baseline Schedule. However, I would expect that this approach, too, would be fraught with the potential for error because I should think that removing progress would result in changes in the timing of the later portions of the work such that it no longer matches the agreement in the change order.
None of these approaches seems at all close to ideal. And yet, thus far I have been unable to identify another alternative.
Thus, I wished to ask the community if there is a consensus regarding what the best practice is for implementing a revised baseline for a schedule that has already been progressed.
Printer-friendly version
Send to friend
correct now measure your progress against that schedule
correct now measure your progress against that schedule
Thank you, everyone, for your help. Indeed, it appears that the sensible way to go is to accept the loss of variance information to date. In fact, this very day I made time to run an experiment, creating a new baseline from the revised current schedule, and found that nothing immediately-obviously problematic arose.
All these suggestions are essentially the same and eliminate all variance; to me it looks like a 100% consensus.
Still I would not be surprised if some DOD [Department Of Defense] EVM purist insist otherwise. It would be like trying to lace your left shoe by resting the right shoe on a chair and bend to lace your left foot resting on the floor while struggling to keep balance. Doubly insane considering the flaws of EVM.
If you were granted a time extension then make the changes to the Current Schedule, then make a copy of the revised Current Schedule, and attach that copy as a new Baseline Schedule.
This is your new line in the sand which progress will be neasured against.
Baseline Change Management Procedure
However, an S-curve is a result of schedule logic. On the level of activities, projects tend to have many paths, some of them critical, other not. A tiny (if compared to total project duration) schedule variance of an activity can become a cause for substantial rearrangements in the project network, it can change critical path or order of activities, enforce a total reorganization of works. This cannot be captured by either Earned Value or Earned Schedule calculations - potential problems might be masked by compensating positive and negative schedule deviations.
3.5.6.2 Adjusting Variances: A key consideration in implementing an OTB is to determine what to do with the variances against the pre-OTB baseline. There are essentially five basic options. This is a far more detailed effort than these simple descriptions imply, as these adjustments have to be made at the detail level (control account or work package). (See Appendix B for examples.)
1) Eliminate all Variances: …
2) Eliminate the Schedule Variance (SV) Only: … After evaluating the cumulative information in the CPR/IPMR, the two PMs may agree that the cost variance represents meaningful performance measurement information that the CAMs should continue to focus on and that only the SV should be eliminated.
3) Eliminate the Cost Variance (CV) Only: … If, after evaluating the cumulative performance measurement information, the two PMs agree that the schedule variance contains valid performance measurement information, the OTB can be implemented by eliminating only the CV
4) Eliminate Selected Variances: … the two PMs may choose to implement an OTB for only that portion of the contract. In this case, all other variances and performance measurement elements would remain intact. The OTB reporting provisions would only apply to the items selected for OTB. The resulting TAB will be greater than CBB and will vary by which elements are reset.
5) Retain All Variances: … the contractor and customer have agreed to retain all variances.
As said before, atiny (if compared to total project duration) schedule variance of an activity can become a cause for substantial rearrangements in the project network, it can change critical path or order of activities, enforce a total reorganization of works.
Schedule variance can be a change in plans, a change in scope, a change order, an act of god etc. A substantial rearrangement in the project baseline might be needed.
Even a single activity might require substantial and complex rearrangement. Imagine Activity A (footing excavations) is schedule for first six weeks but it rained on week 4, then on week 6 an unforeseen condition stop it until evaluated, at week 12 a completely redesigned foundation was issued, from spread footing to pile foundation.
Changing the baseline for this single activity takes time if to be un-statused to keep all variance. It will have to be scheduled as intermittent, it will require additional activities with different resources when changed from a spread footing to a pile foundation activity(es). It will require re-arrangement of budget amounts.
Un-statused re-baseline that keeps all variance is not as easy as a single click of the mouse.
Such a waste of time is not worth it, all is needed is an updated schedule that meets current contract conditions.
As a construction manager I have seen hundreds of times when substantial rearrangement of activities was necessary.
Eliminate all variance is the option that makes sense on complex schedules.
Construction schedules are usually complex, even the schedule for a local hospital might require thousands of activities. To apply the same poison to all schedules is bad medicine.
I suspect DOD is aware of this and therefore leaves it open the option to eliminate all variance. For some inexplicable reason some schedulers insist on excluding the option that makes sense on complex schedules, eliminate all variance.
Email: PPadmin@planningplanet.com
Replies