none
Actual start in the future? RRS feed

  • Question

  • I know that the concept behind the actual start is the date where you really start an activity. Imagine that i have an activity which starts on day10. The status date is day 12 and the resource assigned reported that he/she will start only on day 17. In your opinion what is the best practice for updating this task?
    Friday, November 11, 2011 4:58 PM

Answers

  •  

    Adalberto,

    I will never insert constraints in this kind of situation. I agree with you. You can solve this issue using constraints but later you'll have a schedule full of constraints. This is not a good practice in terms of Dynamic Scheduling. Fact.

    Mike,

    I don´t think this is for "laughs". The resource didn´t say “will start only on day 17”. The resource is just rescheduling the work and this is the same as estimating a simple duration for an activity in the begging of a project when you have a lack of information, for example. The level of uncertain is very high. When the resource estimate this duration in the begging and there are no lessons learned database so you can use for a quality estimate, is this for laughs, too? I don´t think so. This is why we have Risk Management.

    Adalberto,

    The solution I recommend in this case is to use the “Task Usage” view, and turn on the rows Work, Actual Work, and Baseline Work; then, you just need to fill the right information.

    I model a similar situation

    In following picture I suppose John couldn’t start working on Monday 14 Nov’11, and he "expected" (and this is not a constraint) to start working until Wednesday 23 Nov’11, so, you just need to enter “0” in Actual Work for current week, and enter also “0” for Work in Monday 21 Nov’11 and Tuesday 22 Nov’11; with this, the task was rescheduled until John can start working without using a constraint. I also updated Mary’s Actual Work.


     


    Alexandre Paiva, PMP, MCTS, ITIL Project Manager +55 (21) 8887-3645 alexandre.paiva@gerentedeprojeto.net.br www.gerentedeprojeto.net.br
    Tuesday, November 15, 2011 1:54 PM
  • Volledig akkoord, Wim. Ik zou het niet beter kunnen zeggen.
    Friday, November 18, 2011 7:50 PM
    Moderator

All replies

  • aplacerda,

    The best practice is to actually enter the start date on which the work actually started.  To accomplish what you want in Project 2010 you can enter this two ways.  First you can change the planned start date, which means that you would have to enter the actual start date later (or enter a % complete at some point).  You could also enter the actual start date (day 17) in which project would automatically move the planned start date to that date.

    Hope this has been helpful.


    Gregg D. Richie, PMP, MCTS; Author, Microsoft Project 2010, Microsoft Official Academic Course Series
    Friday, November 11, 2011 6:18 PM
  • Gregg,

    That's the exact way i do. But if you think about it there´s is a paradigm here since you learn that actual start is a date the represents something that really started. Don´t you think so? Thanks a lot for the feedback.

    Saturday, November 12, 2011 1:38 PM
  • Hi,

    I would never enter Actual Start in such a case but a costraint, probably start no earlier than.

    To me indeed, Actual is past history.

    Greetings,

    Saturday, November 12, 2011 7:29 PM
    Moderator
  • aplacerda,

    Jan's approach would be better in this situation.  I was fixated on the actual start information for some reason.


    Gregg D. Richie, PMP, MCTS; Author, Microsoft Project 2010, Microsoft Official Academic Course Series
    Saturday, November 12, 2011 7:35 PM
  • Jan,

    Thinking about constraints, the best practices of project management says that constraints are factors that will limit the project management team’s (budget, resource's calendar, etc). In this case, i really don't know this is a constraint. The resource assigned to this task just rescheduled the scheduled start.of it. He/she can start on day 16 instead of day 17. He/she just estimated the day 17 for start that task.

    I don´t know. It's a simple reschedule in my opinion and not a constraint.

    What do you think about this point, Jan and Gregg?

    Thanks a lot for this rich discussion.


    Saturday, November 12, 2011 11:46 PM
  • If I were you, I would do whatever Jan says to do.

    Why? It saves time.

    In MSP, "constraint" only means one thing only, and that is "date constraint", one of the 8, or more properly one of the last 6, which appear in the drop down list in Task Information, Advanced, and it is used to force the start or finish of a task to occur on or not before or not after, some date.

    Definitely, actual start date should only be used for something which has already occurred, relative to some date, usually the current date or the status date. This way, there is a clear distinction between the past and the future, between what has happened and what is planned to happen.

    For what you describe in your original post, a task calendar or a resource calendar which defines when the resource or task can start might also be an option, an alternative to a date constraint.

     

    Sunday, November 13, 2011 1:54 AM
  • Trevor,

    Thanks a lot for your response. But i'm not convinced yet. This situation doesn´t have a related constraint in MS Project. The resource rescheduled the task because he/she estimated the day 17 to begin the work. The task can starts on day 16 if it's possible. It's different when you say that the resource is unavailable to start before day 17 maybe because he/she is absent, for example. This is a constraint.

    If the best practice is using constraints in these cases, my schedule is gonna be full of constraints. And this is not a good practice because violates the concept of a dynamic scheduling. Don't you thing so?

    Again, i'm just rescheduling a task. the ideia is to change the scheduled start.

    Sorry to insist on this point but this discussion is very very important and i would like to read more about it. Please!

    Thanks a lot, Trevor, Gregg and Jan.

    Sunday, November 13, 2011 2:50 AM
  • apalcerda,

    What you are presenting is a situation which is something I call micro-project management.  I agree that constraints should be used only when necessary to allow the tool to do it's job.  You are using an assumption (based on information that the owner of the task is unsure of at this point) and applying this assumption to the tool.  In this case, based on the information you have (an estimate of the start date) using a start no earlier than constraint is the safest/best way to go.

    In addition to setting the constraint, you should also DOCUMENT why the constraint was set.  Entering this into the notes field of the task will help you remember why you set the constraint, based on information from whom, and if you do a complete recording, the date the constraint was set.  (e.g. SNET constraint of Day 17, set on 11-12-11, based on Joe's estimate.  Reason stated was due to other higher priority projects.)

    If the person doing the task can start earlier, then change the date and remove the constraint.  This is simply part of managing a schedule, resources and work.


    Gregg D. Richie, PMP, MCTS; Author, Microsoft Project 2010, Microsoft Official Academic Course Series
    Sunday, November 13, 2011 3:19 AM
  • Hi Aplacerda,
     
    Surely this is simply achieved by entering the new Start Date as day 17.  This will automatically apply a Start No Earlier Than constraint.
     
    Mike Glen
    Project MVP (97-11)
    See http://tinyurl.com/2xbhc for my free Project Tutorials
    Sunday, November 13, 2011 10:21 AM
    Moderator
  • HI,

    But the resource's statement ("will start only on day 17") DOES constrain your schedule! It even is a nice example of something limiting your possibilities to plan!

    Now when you say that it's just a vague estimate, that maybe he/she will start earlier then maybe you should disregard this completely. So it's all about the meaning or the statement "will start only on day 17" - if that's what is going to happen, it's a constraint by definition. If it's just for laughs, then let's forget about it.

    Greetings,

    Sunday, November 13, 2011 7:01 PM
    Moderator
  • Jan --

    "...If it's just for laughs, then let's forget about it..."  Jan, as always, your advice is sage!  :)


    Dale A. Howard [MVP]
    VP of Educational Services
    msProjectExperts
    http://www.msprojectexperts.com
    http://www.projectserverexperts.com
    "We write the books on Project Server"

    Sunday, November 13, 2011 9:06 PM
    Moderator
  • Jan, Mike, Trevor and Gregg

    Thanks a lot.

    This is the kind of discussion i hope find here. Not only MS Project tips, but also discussions about project management and what the tools should do for keeping the best practices intact. This point i brought to you, experts, generated a lot of questions about what is the best way for updating this task in this kind of situation. It's not so clear for many people who deals with Project Management and Microsoft Project.

    Once again thanks a lot for this rich discussion.

    Sunday, November 13, 2011 9:25 PM
  •  

    Adalberto,

    I will never insert constraints in this kind of situation. I agree with you. You can solve this issue using constraints but later you'll have a schedule full of constraints. This is not a good practice in terms of Dynamic Scheduling. Fact.

    Mike,

    I don´t think this is for "laughs". The resource didn´t say “will start only on day 17”. The resource is just rescheduling the work and this is the same as estimating a simple duration for an activity in the begging of a project when you have a lack of information, for example. The level of uncertain is very high. When the resource estimate this duration in the begging and there are no lessons learned database so you can use for a quality estimate, is this for laughs, too? I don´t think so. This is why we have Risk Management.

    Adalberto,

    The solution I recommend in this case is to use the “Task Usage” view, and turn on the rows Work, Actual Work, and Baseline Work; then, you just need to fill the right information.

    I model a similar situation

    In following picture I suppose John couldn’t start working on Monday 14 Nov’11, and he "expected" (and this is not a constraint) to start working until Wednesday 23 Nov’11, so, you just need to enter “0” in Actual Work for current week, and enter also “0” for Work in Monday 21 Nov’11 and Tuesday 22 Nov’11; with this, the task was rescheduled until John can start working without using a constraint. I also updated Mary’s Actual Work.


     


    Alexandre Paiva, PMP, MCTS, ITIL Project Manager +55 (21) 8887-3645 alexandre.paiva@gerentedeprojeto.net.br www.gerentedeprojeto.net.br
    Tuesday, November 15, 2011 1:54 PM
  • Hi,

    I fail to see why a leading split on a task is more elegant than a SNET constraint which is simpler to introduce than several 0H work days in Task Usage.

    And I fail to see why people are so allergic to constraints. Indeed, when a schedule starts slipping, you will see a schedule with many constrraints (as generated by reschedule remaining work) but there is absolutely no problem with that.

    I'll be the first to tell people not to enter constraints or start dates "because they like that start date" (certaily not MUST constraints)but what planning elements coming from the outside of the project are simply constraints. Constraints only stop the schedule showind dates that are not realistic.

    Greetings,

    Tuesday, November 15, 2011 2:36 PM
    Moderator
  • But the resource saying they think it will start on day 17 IS a constraint. The resources opinion on such things is AT LEAST as valid as your own and likely more valid since it is them that will be doing the work. I see a few outcomes that might occur AFTER the constraint is applied for day 17:

    1. the work really does start on day 17 in which case in the interceding period your schedule for tasks downstream from this was was more accurate. Those resources that were assigned to those tasks knew that there was about 7 days more slack befor the start of their tasks
    2. The task actually starts on the 15th or 16 in which case the application of the actual start makes the constraint null and void since the actual start will take precedence over the constraint AND the schedule was still more acurate than the Day 10 start of your original estimate.

     

    Like most good schedulers Im not a huge fan of constraints either but to completely turn your back on them is just as bad. They should in many (maybe most) cases be avoided but this is one of the exact situations for which the SNET constraint exists. Your resource has informed you that in their best opinion the task will not start until day 17. Therefore, your schedule should not show it as starting  before day 17.


    Brian Kennemer – DeltaBahn Senior Architect
    Blog | Twitter | LinkedIn
    Tuesday, November 15, 2011 3:04 PM
    Moderator
  • I didn't say that!

    Mike

    Tuesday, November 15, 2011 8:34 PM
    Moderator
  • WOW, what a discussion...

    I would say: try to describe the reality in a project plan as pure as possible!! Pure information offers best result when coming to the point of making decisions. Fuzzy data lead to fuzzy conclusions!

    • "Actual work" means performed work in the past! so pushing the task to the future by nailing it on the 17th by entering actual hours on the 17th is not-done for me !!
    • Using constraints (soft or hard), is correct if that describes reallity: I don't want to give the planning engine the freedom to "optimise" my plan into a conflicting situation in respect with my reality. So the SNET is the good option for me in this case.
    • Planned work before the status date?!? Can anyone tell me how to perform work in the past? This is definitely not a good situation: what is worth the remaining work after the status date in this case...

    Hope this adds something to the discussion ;)
    Regards
    Wim

     



    Friday, November 18, 2011 7:40 PM
  • Volledig akkoord, Wim. Ik zou het niet beter kunnen zeggen.
    Friday, November 18, 2011 7:50 PM
    Moderator