15

I want to show an ongoing "support" task in MS Project, where the start date is driven by one milestone (test environment available), and the end date is set by another milestone (testing complete). I do not want to enter a duration or an amount of effort into the plan, as these will vary according to whether my dates vary as the plan evolves. Instead, I would like to have these figures calculated within the system and recalculated automatically if the plan moves.

I feel as though I am missing something obvious, but can't work out what it is. Is this possible, and if so, how do I do it? It's not quite the same problem as in < Calculated duration in MS project task? >, but it does seem fairly similar.

Community
  • 1
Iain9688
  • 6,858
  • 4
  • 23
  • 50

2 Answers2

13

What you need is a hammock task. A Hammock task is a task that depends on other tasks for both the start and finish dates. Like a hammock, the length of the task depends on the space between the two other tasks.

Roughly speaking, create a task, then link the start of the hammock task to the first task, and the finish of the hammock task to the second task. If either the first task or the second task changes schedule, the hammock will flex to accomodate the change.

The referenced link contains step by step directions.

MCW
  • 8,718
  • 2
  • 28
  • 48
  • Thank you Mark - it very well could be. "Hammock task" is not a term I had not previously come across, and I certainly would not have discovered this solution by myself. I will try this and let you know if it does what I want. – Iain9688 May 08 '13 at 18:00
  • 1
    Hi Mark, do you mind expanding this post a bit by bringing information about "hammock tasks" into the body of your post or perhaps explaining how it would apply in this situation? lain isn't the only one new to the term, and I suspect there are others. :) Additionally, if the link in your post were to break, a fuller explanation would be more helpful to future visitors who have the same problem. Hope this helps! – jmort253 May 09 '13 at 07:02
  • Answer accepted - this is indeed exactly what I was looking for. David Espina makes a valid point about variances and, by implication, about tasks moving freely without being under my direct control, but in this case there are good reasons for wanting to do this, and the hammock task solution is the easiest way I have seen to achieve what I need. – Iain9688 May 12 '13 at 13:49
3

You need to enter planning values for work packages, no matter the type. Your goal is NOT to be variance free. You will always accrue variances so you should not feel compelled to be so accurate with support package planning.

Choose your duration and load your support resources accordingly, based on the level of risk you wish to assume. If you are measuring using EV, use the apportioned method to capture performance. That will assist you in terms of analyzing how hot or cold you are running and if you are at risk of over- or under-running your budget for that package.

David Espina
  • 37,143
  • 4
  • 34
  • 91
  • That's a fair comment, David, but in this case all that is needed is to have the support work as a "memo" activity that indicates that a certain resource is required to be available - and not to measure the costs etc. It may sound like an odd thing to do, but there is a good reason for it, and my project doesn't need to account for the cost or measure the performance. It just has to show that there is such an activity ongoing. Call it political - and that's all I can say about it without getting myself into deep water. – Iain9688 May 08 '13 at 20:37
  • Understand. The good news is your start date for the testing package will move back and forth based on the logic you build to the predecessor task/milestone. So, as you produce variances in the predecessor task, the successor task will move and give you insight to when you will need the resource(s). However, I know of no way of having the tool update durations and effort automatically. – David Espina May 08 '13 at 20:48
  • Wish I could help more. Good luck! – David Espina May 08 '13 at 20:48