none
Why Does a Task Split When Percent Complete is Changed Back to Zero? RRS feed

  • Question

  • We have Project Pro v2010 SP2

    We have tasks that need to change from a non-zero percent complete (%complete) back to zero. Whenever we do this the task splits with the resumption of the task beginning on where the progress bar had previously ended.

    The box for "Split In Progress Tasks" is unchecked.

    This is really screwing us up.

    What are we missing?

    Chris

    Tuesday, February 2, 2016 3:37 PM

All replies

  • The first thing that comes to mind is your calcuation options. check your options under File >> Options >> Advanced.

    Check to see what is checked under the Calculation Options. These setting affect the update process, along with the status date.

    More information here: https://support.office.com/en-ie/article/Options-dialog-box-Calculation-tab-2e343858-7ba1-4274-95e1-9ec78c4954c7


    Cheers,

    Prasanna Adavi, Project MVP

    Blog:   Podcast:    Twitter:    LinkedIn:   

    Tuesday, February 2, 2016 4:28 PM
    Moderator
  • Hi Prasanna -

    This is becoming more puzzling by the moment.  The noted behavior occurs for files on one Server, but not for files on another Server.  Switch settings for the files on the two different Servers are identical.

    For the file that is seeing the behavior, if you cycle the %complete from 100% to 0% the task start graphically moves to the previous finish (in reality, the task is split).  If I change the task back to 100% and then cycle it back to 0% it moves again to the right.  Very disturbing.

    We are not resource loading.

    Chris

    Tuesday, February 2, 2016 5:09 PM
  • Other observables:

    This behavior seems to be limited to my v2010 instance on my one desktop.  No matter what Project Server I access with this v2010 instance, or whether I open a file from an H:/ drive, I still see the behavior. 

    If I switch to my v2013 instance on this same desktop I don't see the behavior.

    I have a laptop in my car with v2010 and v2013... I will try seeing if I can get the behavior to replicate from that machine later today.

    Chris

    Tuesday, February 2, 2016 5:36 PM
  • On the laptop, I see the behavior in v2010 but not v2013.

    My conclusion is that there must be some missing CU on my desktop and laptop that is resident on my v2010 Customer-supplied machine.

    Chris

    Tuesday, February 2, 2016 8:00 PM
  • The behavior only affects auto-scheduled tasks and it is affecting 2 of 3 MS Project v2010 networks tested thus far.  If a task is given a non-zero percent complete and then is cycled back to zero percent complete, it will be split.  The task will have the same duration after the split and the resumption of the task seems to be always occurring on the prior finish date.  Removing a split is a real pain.

    One work-around is to first declare the task as having manual task mode before cycling the %complete back to zero.  From there you can then take the task back to auto-schedule.

    Tuesday, February 2, 2016 10:44 PM
  • This is what we know.  The bug is only affecting our users that have applied the CU from December 2015.  This is Project 2010 14.0.7164.5000 SP2 MSO 14.0.7165.5000.

    ATTENTION MICROSOFT MODERATOR.  YOUR LATEST RELEASE HAS A BUG!

    The following graphic shows what you can see and under what conditions.

    Wednesday, February 3, 2016 2:32 PM
  • Before I completely blame the bug on the last CU, I will say that we started to notice that something was wrong late in December. 

    Users that are NOT seeing this bug have the following configurations:

    MS Project 2010 (14.0.7011.1000) SP2 MSO (14.0.7015.1000)

    MS Project 2010 (14.0.7113.5000) SP2 MSO (14.0.7015.1000)

    MS Project 2013 (15.0.4787.1000) MSO (15.0.4787.1002)

    The work-around that we are currently using is that if we need to drive a %complete from 100 to 0, then do it in manual task mode.

    Wednesday, February 3, 2016 3:16 PM