There is a limitation in MSP that will prevent you from easy modeling of concurrency because it will not allow two links between activities. A workaround can be to add a milestone in between any of the two links.
I used a 2d lag, but could have been 1.5d to represent 30%, the same calculations you would do to calculate the split. Easy and transparent.
What you should avoid is the use of negative lag, a common workaround used by MSP users as to tackle this limitation.
With Spider Project in addition to time lag we we can model volume lag as a percentage but there is no equivalent for this in MSP. The software will calculate the time required to realize the % volume of work depending on production rates, another parameter lacking in most other software.
The following link shall provide you with some insight. Note that I do not agree with the conclusion because it is missing what happens with resource leveling. Anyway it makes no harm to see what others suggest. Some schedulers do not use/understand how software resource leveling works, therefore I am not surprised the article misses how resource leveling might spread apart the activities.
This approach might result in longer development schedules, because they incorrectly use sequential logic. Not starting downstream activities until the upstream ones are complete inexorably lengthens the path. Instead, we must use the logic of CONCURRENCY to shorten the paths.
There are no perfect models as some pretend, while none is perfect they can be good enough and without doubt better than nothing.
The risks of splitting activities that shall be executed continuously can be far more dangerous than pretending concurrent logic does not exists. This is specially true if your model is to apply resource constraints, it might spread apart the segments of an activity that shall be continuous. In such case use of SS(+lag) in combination to FF(+lag) relationships will make a better model, though never perfect.
Member for
19 years 11 months
Member for19 years11 months
Submitted by Trevor Rabey on Fri, 2016-07-22 13:08
Stage 1 of scaffolding takes as long as it takes to get enough scaffolding up so that people can work on it.
Break the scaffoldong into stages, and use FS0 links only.
Example: if you had 15 bathrooms and the plumber goes in and does his part first and then the tiler comes in behind him, you don't have to do all of the plumbing before starting the tiling, so you would break it down room by room.
Hi Tim, you want your logic to reflect reality so if you don't need to wait until all scaffolding is up to begin, then this isn't the link you want. I would use either a SS relationship with a lag, or better yet, create an activity that is SS with the scaffolding that represents that 30% until they can truly begin, and then link the start of that work from that activity instead.
Member for
21 years 7 monthsThere is a limitation in MSP
There is a limitation in MSP that will prevent you from easy modeling of concurrency because it will not allow two links between activities. A workaround can be to add a milestone in between any of the two links.
I used a 2d lag, but could have been 1.5d to represent 30%, the same calculations you would do to calculate the split. Easy and transparent.
What you should avoid is the use of negative lag, a common workaround used by MSP users as to tackle this limitation.
With Spider Project in addition to time lag we we can model volume lag as a percentage but there is no equivalent for this in MSP. The software will calculate the time required to realize the % volume of work depending on production rates, another parameter lacking in most other software.
The following link shall provide you with some insight. Note that I do not agree with the conclusion because it is missing what happens with resource leveling. Anyway it makes no harm to see what others suggest. Some schedulers do not use/understand how software resource leveling works, therefore I am not surprised the article misses how resource leveling might spread apart the activities.
http://www.gbaprojects.com.au/uploads/files/whitepaper_-_poor_planning_…
Member for
21 years 7 monthsThis approach might result in
This approach might result in longer development schedules, because they incorrectly use sequential logic. Not starting downstream activities until the upstream ones are complete inexorably lengthens the path. Instead, we must use the logic of CONCURRENCY to shorten the paths.
http://www.me.utexas.edu/~jensen/network_02/topic_pages/kanegaronkar/opinions.htm
There are no perfect models as some pretend, while none is perfect they can be good enough and without doubt better than nothing.
The risks of splitting activities that shall be executed continuously can be far more dangerous than pretending concurrent logic does not exists. This is specially true if your model is to apply resource constraints, it might spread apart the segments of an activity that shall be continuous. In such case use of SS(+lag) in combination to FF(+lag) relationships will make a better model, though never perfect.
Member for
19 years 11 monthsStage 1 of scaffolding takes
Stage 1 of scaffolding takes as long as it takes to get enough scaffolding up so that people can work on it.
Break the scaffoldong into stages, and use FS0 links only.
Example: if you had 15 bathrooms and the plumber goes in and does his part first and then the tiler comes in behind him, you don't have to do all of the plumbing before starting the tiling, so you would break it down room by room.
Member for
19 years 10 monthsHi TimothyYou should only use
Hi Timothy
You should only use Finish Start links in your programme.
Split your scaffolding task into as many stages as are necessary and use FS links from each stage to the following trade.
SS lead lags distort the logic because when your programme update data line passess the link date then all logic is lost.
Best regards
Mike Testro
Member for
9 years 4 monthsHi Tim, you want your logic
Hi Tim, you want your logic to reflect reality so if you don't need to wait until all scaffolding is up to begin, then this isn't the link you want. I would use either a SS relationship with a lag, or better yet, create an activity that is SS with the scaffolding that represents that 30% until they can truly begin, and then link the start of that work from that activity instead.