(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 have a (new) PMO issuing a Good Scheduler Practices instruction prohibiting the use of any form of explicit delay allowance or time buffer in our project schedules on the basis that it only extends the project duration and / or confuseres the crical path.
Also, no use of any Start as Late as Possible activity logic.
Am in the electricity distribution industry and projects usually take 4 - 5 years with critical path running through network planning, site aquisition, building design, construction, electrical (power distribution) fitout, and commissioning. Other activity streams include (power systems) electrcial & mechanical design, equipment procurment, transmission mains design & construction, low voltage power distribution (to end users)
Most work is carried out in-house - exceptions are building design & construction. Work load has doubled over past two years and has major labour resource constraints.
Have around 200 projects in play at any given time.
What are your thoughts on use of time contingencies
- included in every activity
- as delay or buffer etc in streams of activities / milestones
- at end of minor or major phase
- at project end
Andrew
Printer-friendly version
Send to friend
Everyone knows that under resource constraining the critical path changes in unsuspecting ways, therefore the near critical paths.
Everyone knows the unsuspecting happens, that unexpected delays and even the consumption of float by others will change near critical paths and in occasions critical paths.
Buffers are positioned to protect original critical path and original near critical paths. But critical path and near critical path changes as the job progress. The only buffer that might maintain its validity will be a single buffer at the end of the job (milestones) if you can adjust its value . This is equivalent to targeting for early finish in the hope of finishing on time with an automatic and valid adjustment in buffer value. I guess we all understand buffers are not static either.
I don't want to be targeting for the protection of float in the wrong paths. Do you?
Stop using intermediate buffers as if garlands to a Christmas tree, wrong garlands might get your tree on fire.
Stop fooling people and yourself, it might backfire.
Do not underestimate people at the jobsite, they know their job better.
I believe either Mike Testro or Gary or both in other postings have suggested to target for early finish, to set a fixed milestone and with a Hammock between projected finish and contractual finish milestone you will get your final buffer adjusted. To me this makes sense if you do not want to get into probabilistic modeling and the added benefits of its use because your software does not help much with probabilistic modeling.
I still find it to be a supperior approach to management to use an optimistic scedule to manage actual operations and the use of a most probable schedule to project into what is the most probable future. Life is not a deterministic event, at least not before you die.
"Finally, any client delays which affect the optimistic but not most likely completion date may go uncompensated."
I guess which is to be used for delay analysis depends on the contractual "ownership" of float. Unfortunately there is too much emphasis on using CPM as a claim tool rather than a management tool, more frequent than not these two are in conflict.
Regards,
Rafael
Just a note of caution regarding maintaining both an optimistic working schedule and an most probable reporting schedule:
Without the functionality Spider gives you to update both simultaneously, this approach doubles the planning workload and introduces a lot of oportunities for double-handling errors.
Also, if your projects require client deliverables at key points, you have the possibility of client and project team planning on different dates for when these deliverables are required
Finally, any client delays which affect the optimistic but not most likely completion date may go uncompensated.
Cheers,
G
Thanks Rafael,
Sorry have been away or would have replied earlier. Activities becoming "critical" is reason PMO does not like this method, but as I have the Buffer in palce, I have good visability.
Thanks
Andrew,
Be careful with the use of late dates for procurement, late dates are computed using a backward pass computation so late date will make successors become critical. Using available free float is another thing.
I also believe, though not sure, ALAP "As Las Late As Possible" does not work equal on different software, maybe some implement the ALAP to consume all float while others implement it as to consume only available free float.
Perhaps providing functionality to implement both might be useful.
Regards,
Rafael
Vladimir, Mike, Nader & Rafael,
Thank you for your advice.
We are only using MSProject and not even an enterprise version so need to juggle some versitility - PowerProject, P6 etc - have not had any experience with Spider!
I am keen on CCM but I can't get that to fly at all.
I think the combo of end & major milestone buffers, but also with the optimistic and target models might be a PMO acceptable solution!
Late starts used only for procurement & some design elements, as you noted Mike.
Thanks all, will keep you posted.
Andrew
I believe buffers shall not be modeled on the schedule you use for actual management, you shall use an optimistic schedule for management.
We usually present to the Owner the most probable schedule in accordance to his requirement not to explicitly show buffer activities and use the optimistic schedule for actual management of our jobs. We target to early (optimistic) dates in the hope will attain target (most probable) dates.
I believe the basic procedure of implementing buffer modeling can be done within any software, the application of mathematically correct statistical functionality is another thing.
Because we use Spider Project by adding a third model, a pessimistic model, we can get very useful statistical metrics without the need for Monte Carlo. By merely updating one of the models the other two are automatically updated at the click of the mouse. It is well known by older schedulers that the initial PERT model was wrong, the methodology by Spider might seem similar but it is not. Original PERT methodology used a single model with a single critical path. Spider approach can accommodate for different critical paths as it uses 3 models.
Use critical chain method...
Hi Andrew
Vladimir is right - it is good planning practice to allow a time risk buffer at the end of a programme to allow for Contractor's potential problems.
Point your PMO towards the NEC group of contracts where this is a contractual requirement.
Also the Society of Construction Law Protocol 2002 where use of a time risk buffer is said to be "prudent planning practice".
PowerProject is the only software that I know of where a task can be converted into a buffer task and your PMO is right to some extent in that a PowerProject buffer will always show critical even if it is not on the critical path.
Insofar as the last task on a programme is always critical this is not usually a problem.
I agree with not using ALAP constraints since it does distort the available free float and gives a misleading concept of potential start dates.
I only use ALAP for lead in procurement or design tasks
Best regards
Mike Testro
You shall create a buffer at the project end and buffers preceding major milestones.
Email: PPadmin@planningplanet.com
Replies