Thanks for the ideas. I have never used the “Paste Special” feature to create a hammock task, but that is an interesting technique. I always get a little nervous about setting either the start or finish date directly in MS Project. Usually that winds up creating a date-constraint, which I do not usually want. I will have to experiment with the “paste special” command to see the full implications of this.

You are correct that the network diagram does not set tasks to start as late as possible or as soon as possible. Another possible method to get finish dates to line up is to set the task type from “as soon as possible” (the typical type) to the “as late as possible” value. Sometimes that can be a good way to move a task as late as possible, without chaning the network diagram.

For any readers who have not heard of a “hammock” task, it is a feature seen in Primavera and some other scheduling programs. A hammock task is a task that will start at the same time as one task, and finish at the end of a phase or right before the start of another task. Often this is used for level-of-effort work, like status reports or weekly meetings. You want the duration of these tasks to grow and shrink depending on the length of the project or phase. Because they span the whole phase, no matter how long or short it is, they are called a “hammock”.

I have heard scheduling experts say that a hammock task is impossible in MS Project. Some people say that this feature is something important, and software like Primavera is better because it allows hammocks. This “paste special, link” technique may be a way to create that function in MS Project.

The purpose of building the network is primarily to find out how soon Tasks can start and finish, not to set them to finish as late as the finish of some other Task.

If the goal is to ensure that the finish date of Task B is always the same as the finish date of Task A, a Hammock is possible and it can be done in MSP, easy.

Copy the finish date cell of Task A and Paste Special, Link in the finish date cell of Task B.

One way to achieve this effect is to create a milestone “C”, and make both A and B finish-to-start predecessors of milestone “C”. Select an appropriate description for the milestone, so that you know that you want to ensure that you do not mark “A” as complete until “B” is completely done. Also, any tasks that need to follow task “A” in your network diagram can be given a predecessor of milestone “C”. If you change the information about task “B”, then the milestone will automatically be adjusted to be the later of the two finish dates for tasks A and B.

Another way to achieve this is to use finish-to-finish relationships. Sometimes these are perfect for your schedule, but often they cause unexpected, unpleasant results. Make A a predecessor to B with a finish-to-finish relationship, and that will ensure that task B cannot complete before task A completes. Make B a predecessor to task A with a finish-to-finish relationship, and that will ensure that A cannot complete until B completes. Neither of these relationships is exactly “finish B no later than A”, but they are one method to approximate what you are looking for.

If the finish date of the finish-to-finish successor falls too early, the successor tasks’ start and finish dates will be shifted up so that the finish date matches the predecessor. If the finish date of the successor falls on or later than the finish date of the successor, the relationship has no effect on the schedule.

What throws people off about finish-to-finish relationships is that they not only change the finish date of the successor task, but the start date as well. If you extend the duration of the successor, the START date might change instead of the finish date. Some scheduling tools have a concept of “hammock” tasks where you can fix the start date using a finish-to-start relationship and let the end date move according to a finish-to-finish relationship. MS Project does not have this capability, and you would need to play with the duration, work, and units with every schedule update if you want to simulate a hammock task.

Building a solid network diagram using finish-to-finish relationships is not simple. In a typical network diagram, you want to avoid “open ends” or tasks with no predecessor and no successor. Everything should eventually tie to a start milestone and a finish milestone. Figuring out if you have open-ends when you start using finish-to-finish, start-to-start, and finish-to-start dependencies can be difficult, and it often confuses newcomers to the tool. I much prefer to use milestones and finish-to-start relationships instead of the other types of dependencies.

Explaining this in depth is a topic for a new article, not a quick comment reply. Basically the issue to watch out for with finish-to-finish is that the successor’s finish date is constrained, but not its start date. If you create a task and its only predecessor is a finish-to-finish dependency, you have an open end. The start date of this task could extend before it is logical to start the work. You must add another dependency in order to somehow control the start date as well, and tie it off to the start-date milestone. Usually you do that with another predecessor with a start-to-finish type. If this paragraph does not make sense to you, I VERY strongly recommend using the milestone method. If this paragraph does make sense to you, you might want to use a finish-to-finish relationship to accomplish your goals, but do it carefully and sparingly. I almost never use them, and when I do I watch those tasks very carefully for unintended effects when I update the schedule.