A Note on Start-to-Start Dependencies
Introducing a Start-to-Start dependency between schedule tasks does not mean that the tasks can start at the same time.
It means that the successor task can not start until the predecessor task starts.
If you want two tasks to start at the same time, model them as successors of a common task, with a Finish-to-Start relationship. Then when the common task is finished, they will both start simultaneously (assuming that there is no other constraint, such as resources).
It means that the successor task can not start until the predecessor task starts.
If you want two tasks to start at the same time, model them as successors of a common task, with a Finish-to-Start relationship. Then when the common task is finished, they will both start simultaneously (assuming that there is no other constraint, such as resources).
posted by michael at 9:29 PM
2 Comments:
Michael,
Thank-you for your suggestion here. However, I am in a quandry. I train MS Project, and have been using an example of a delayed task to explain the importance of task relationships not just looking right, but being right.
This is a long one, so I hope you will bear with me. I use Powerpoint pictures when I do this in training.
The example is:
I am putting in a pond in the backyard. I have three tasks:
1. Dig hole.
2. Fill with water.
3. Test water quality.
I explain that I must test the quality of the water for my special variety of fish, and need to do this while the water is filling the hole so I can stop the water immediately if there is a problem.
In the first version of my schedule I have two finish-to-start relationships - linking task 1 to 2 and task 1 to 3.
However, I finish digging the hole (with delays) near to the time our water restrictions commence, so I have to delay filling the pond by 6 hours. When I shift task 2, task 3 is 'left behind'.
I suggest that instead the task relationships should be finish-to-start 1 to 2; and start-to-start 2 to 3.
Based on your blog I can see that a problem here is that if there is a delay in task 3 (perhaps the testing kit did not turn up on time), the testing will not take place while the water is put into the pond.
However, if I went with finish-to-start (keeping my first version of my schedule), I still have the problem if task 2 is delayed.
I am wondering whether a milestone (say "M) should be created, with finish-to-start linking tasks 1 to M, M to 2, and M to 3. Or am I overengineering this situation?
...Geoff
Hello Geoff,
I don't think you are over engineering the situation. I do think you need an intermediate task, but not a milestone.
If I understand correctly, you are trying to relate tasks 2 and 3 and want to be able to:
1. Show a delay in task 3 if task 2 is delayed (Can't start filling due to water restrictions).
2. Show a delay in task 2 if task 3 is delayed (The test kit did not arrive on time).
Two tasks cannot be dependent on each other in this way. It results in a circular dependency - a logical impossibility.
A clue to the solution lies in your statement " ... perhaps the testing kit did not turn up on time ..."
What this says is that both tasks are dependent on something else - the testing kit. So, you could model both tasks 2 and 3 with simple Finish-to-Start successors of a common task which is acquisition of the testing kit.
This gives you a more accurate model, and should allow you to provide an example of a delayed task. It doesn't necessarily give you an opportunity to demonstrate a Start-to-Start dependency, but I don't think that was your goal.
Hope this helps.
Thanks for reading and thanks for the question!
Mike
Post a Comment
<< Home