none
Task start dates don't seem linked to end dates of predecessor tasks RRS feed

  • Question

  • I've got a set of effort-driven tasks which are each linked to a predecessor.  All the tasks have a "start as soon as possible" constraint.  We are tracking our progress on these tasks by entering "actual work" and "Work remaining".  In the base line start and finish dates, the start of each task is properly linked to the finish date of its predecessor: however the "plain" start of the task seems to have no relation to the "plain" finish of its predecessor (see task 9 ("Spec") in the picture below).  Further, on one of the tasks, we have marked the as being 100% complete, but the start date for the task still is showing as four weeks from now (see task 12 ("Commands")).  Does anyone know what might be causing this behavior?

     


    Dan



    • Edited by DChernin Friday, September 30, 2011 1:03 AM
    Friday, September 30, 2011 12:40 AM

Answers

  • Updating Actual work directly can certainly cause actual work to get pushed into the future. When you enter data directly into a task level field Project DOES NOT put it all into "Today". It pours it into the task like it was a series of daily buckets, X hours per day until the actual work you entered it all distributed.

    Also when you first enter Actual work it will set the actual start to be the scheduled start date. If that is in the future then that is where it will start and then all your actual work you enter will be poured into the future.

    Best practice when doing this is to set the Actual Start date of the task BEFORE you enter any actual work. Then enter the actual work using one of the Usage views (Task Usage or Resource Usage) in the yellow time scaled area on the right of the view whre you can insert the Actual Work field. Then enter actual work like a timesheet. This will give the user much better control of where the actual work gets placed.


    Brian Kennemer – DeltaBahn Senior Architect
    Blog | Twitter | LinkedIn
    • Marked as answer by DChernin Friday, September 30, 2011 6:06 PM
    Friday, September 30, 2011 3:12 PM
    Moderator

All replies

  • DChernin,

    Go to the MVP website at, http://project.mvps.org/faqs.htm#Contents, and take a look at FAQ 50 - Successor's start date is different from it's predecessor's finish date. My guess is you are hitting item 3.

    If the FAQ doesn't answer your question, please let us know.

    John

    Friday, September 30, 2011 2:58 AM
  • Thanks John.  But what would explain the fact the several of these tasks which contain progress in them show a start date which is after today's date?  For example, the "Commands" task in the screenshot is completely finished, but shows a start date of 10/28.  And, further, what explains the crazy finish date in that task: despite the fact that it is complete, it's showing the finish as 11/30, over a month after the supposed start date.  These types of dates make it almost impossible to figure out the true state of the summary task.
    Dan
    Friday, September 30, 2011 4:08 AM
  • Hi,

    The impression I have is that automatic resource leveling is set to On, in such a way that Joe's tasks are postponed where he would be overallocated. As for the commands task, my only guess is that it was reported as 100% done when it was delayed to October (and split by leveling). Using %complete for progress will simply accept the planned dates as such and ignores the current date or the status date. So here's two pieces of advice:

    1. Check that automatic resource leveling is off. If it was on, use clear leveling.

    2. Never use %complete for tracking, enter actual work in task usage or resoruce usage view if the work has been performed outside the planned dates for the task

     

    Greetings,

     

    Friday, September 30, 2011 8:00 AM
    Moderator
  • Thanks Jan.  I've checked the leveling options, and they are set to "Manual".  Also, we are entering our time by specifying Actual Work and Remaining Work for each task.

    One thing I've been wondering about: after team members update their progress, we update the project by selecting "Reschedule uncompleted work to start after", and then specify today's date.  Could that be causing a problem?

    Another thing I just noticed: the "Commands" task is starting on the "Baseline Start" date.  Since the task constraint is set to "As early as possible", is Project deciding that, even though the task is complete, the earliest it can start is the baseline start (which is pretty weird)?


    Dan
    • Edited by DChernin Friday, September 30, 2011 1:05 PM
    Friday, September 30, 2011 12:48 PM
  • Hi,

    You should verify the Actual Work input. The earliest entry of Actual Work determines Actual Start, and hence start. Once an Actual Start ois registered, Project takes that value for Start - period. No more recalculations, forget predecessors etc. Project's logic here is that is will recalculate plans, not reality, and Actual entries are consoidereid immovable history, even when they are in the futuure.

    Do have a look at Task Usage view, showing a second line in the right part of the view : Actual Work. That will clarify a lot. Remember Gantt Chart is nice but it never explains apparent oddities.

    Baseline data do NOT influence the planning nor the actuals.

    Reschedule work may, and mostly will, influence task finish but it only moves REMAINING work, never Actual. As said, Actual data are off limits of the scheduling engine!

    Greetings

     

    Friday, September 30, 2011 1:17 PM
    Moderator
  • Thanks very much, Jan.  I think we're making some headway here: there are a couple of tasks in the project (among them, "Commands") where the first actual work is recorded in the future.  The question is: how is this happening?  We've inserted the "actual work" and "remaining work" columns into the gantt chart view, and the team members are updating their actual work in those columns.  What are the circumstances where this workflow would cause the actual work to be recorded in the future?
    Dan
    Friday, September 30, 2011 2:47 PM
  • Updating Actual work directly can certainly cause actual work to get pushed into the future. When you enter data directly into a task level field Project DOES NOT put it all into "Today". It pours it into the task like it was a series of daily buckets, X hours per day until the actual work you entered it all distributed.

    Also when you first enter Actual work it will set the actual start to be the scheduled start date. If that is in the future then that is where it will start and then all your actual work you enter will be poured into the future.

    Best practice when doing this is to set the Actual Start date of the task BEFORE you enter any actual work. Then enter the actual work using one of the Usage views (Task Usage or Resource Usage) in the yellow time scaled area on the right of the view whre you can insert the Actual Work field. Then enter actual work like a timesheet. This will give the user much better control of where the actual work gets placed.


    Brian Kennemer – DeltaBahn Senior Architect
    Blog | Twitter | LinkedIn
    • Marked as answer by DChernin Friday, September 30, 2011 6:06 PM
    Friday, September 30, 2011 3:12 PM
    Moderator
  • Hi,

    Some extra on Brian's answer.

    If you are going to enter actual work by time unit (in other words, ask the resources not only how much they worked but also when that was done) there is no need to set Actual Start beforehand. Project will automatically set actual start the day of the earliest actual work recorded.

    Conclusion - entering Actual Work without telling Project when it happened is just as unprecise as entering %Complete because in both cases Project will put the actual work starting at the current start date of the task, even when that is in the future.

    As for stretched durations, as I explained, reschedule work -on an unfinished task - will place all remaining work after today and often the task then is split.

    I think that explains all the problems you have seen.

    Friday, September 30, 2011 5:47 PM
    Moderator
  • Thanks very much, Brian and Jan.  I'm going to mark Brian's post as the final answer, though numerous people contributed.  I still don't quite understand why Project thinks it's the "right thing to do" to record "actual work" in the future, but at least I now know how to fix my current problem.


    Dan
    Friday, September 30, 2011 6:07 PM
  • The short answer is that when you just enter actual work Project does not have enough information to know your intent (did you wan it to be applied starting on the scheduled start, applied starting today, etc). The developers had to pick a default action for such an edit so they picked the most basic action: Set the Actual start to equal the scheduled start and apply the entered actual work to the task as scheduled.

    The usage views provide the kind of control you are looking for but they many users (particularly newer users) dont know they exist so they go unused.

    Im glad you are on the right track. :-)


    Brian Kennemer – DeltaBahn Senior Architect
    Blog | Twitter | LinkedIn
    Friday, September 30, 2011 6:13 PM
    Moderator