Actually, Evgeny, we were talking about exactly the same thing. But here is the difference (which, in my experience, is often the case when two people disagree): one of us was correct and one of us was wrong. And in this case you were correct and I was just wrong. (Idiot that I am, I had neglected to notice that you had made the Oil Machinery activity a summary, which was of course precisely your point!)

Your way not only works, it even works without filtering out the LOE or milestones when using the Sumatra Project Optimizer add-on to compute critical path drag! I don't know WHY it works -- I thought the total slack of the LOEs would throw it off. But it doesn't, and I have learned something. I both apologize and thank you, Evgeny.

Fraternally in project management,

Steve the Bajan

Hi, Evgeny. Your method might work for an LOE driven by the whole project, like "Project Management", but with other potential LOEs, there is one drawback to doing it the way you suggest: If the activity(ies) driving the LOE get longer, your method works fine as your LOE will expand due to the FF. But if the driving activity(ies) get compressed from the original estimate, the FF will not pull in the end of the LOE.

The result could be a situation where we plan to Oil the Machinery (LOE) once per week during Manufacturing, and we plan to manufacture (driving) for 12W. However, we then decide to engage a second shift, causing Manufacturing to shrink to, say, 6 weeks. Now unless we manually change it, the LOE Oil the Machinery winds up still taking 12W and on our critical path with up to 6 weeks of drag while our project duration remains unchanged.

With the method that Emily recommends, if you shorten the duration of the driving activity, the duration of the LOE will automatically be compressed.

Fraternally in project management,

Steve the Bajan

Emily,

good article, but I find, that using Copy and Pasting links feature of MS Project makes it difficult to understand the schedule, as tracing the links in MSP is not so easy.

I normally use another method to create  hammock task: I create a summary task, which is pulled across 2 milestones. As an example for a task “Project Management” I would do the following:

• Milestone1:  Start Of Project Management. This milestone would have Start to Start dependency to so say “Start of the project” task
• Milestone2: Finish Of Project Management. This milestone would have Finish to Finish dependency to a end of the project.
• Summary task: Project Management, which would be pulled on the top of these 2 milestones.

If I assign resource (Project Manager) to this Summary task, I will capture costs to project manage the project.

This method obviously has also disadvantage: you create 2 tasks (2 milestones and 1 summary) instead of 3. 

Regards.

Evgeny  

Emily, good stuff! I am sure that will help lots of people, as it's not intuitive. In the past, I have had to take time to walk my grad students through it. From now on, I'll just point them to your site. Thank you.

A couple more points, though. It is crucial when doing schedule analysis, either up front or during the project when you are looking ways to recover from slippage, to filter out all LOE activities. This can be done by putting the letter "L" in a text field for each LOE activity and then having the software filter on it. (I also recommend giving LOE activities a name that starts with the letters "LOE" so you can easily see any LOEs that do not have an L in the text field and thus slip by!)

The reason it's important to filter out LOEs for critical path analysis is that both the LOEs and their "driving" activities will have identical total slack (0 or negative if on the CP). This will make them seem like parallel activities, and their slacks or lack thereof will "sabotage" the key calculation for scheduling compression, critical path drag.

Fraternally in project management,

Steve the Bajan