Actual Start Date Populates Upon Entering a 0 in the Timescale section RRS feed

  • Question

  • Hello,

    I inadvertently posted a similar question under Project Server posts.  Posting a streamlined version of the question under Project Standard and Professional.  We are using MS Project Professional 2013 and have the latest update June 6, 2017 KB3191941 32 bit, applied.

    A task has multiple assignments and are being updated at the assignment level, not the task level.

    One assignment did not start as of the Status Date but should have.  We enter a 0 in the timescale for that month reporting period.  MS Project populates the assignment Actual Start date and the task Actual Start date to the planned Start date, even though no work was done (entered a 0).  This is not what we would expect to see.

    With multiple assignments, some of which have started, this is an issue as a later Actual Start date for another assignment will not overwrite the Actual Start date for the task.  Further, once the unstarted assignment is started and an observed Actual Start date is entered for the assignment that differs from the earlier populated date, the task Actual Start date remains, and is inaccurate.

    Hope someone can help out with this.  Let me know if there is some reason MS Project would set the Actual Start date when 0 is entered in the Timescale as described above.  Thanks!!

    Thursday, July 6, 2017 7:12 PM

All replies

  • Monika,

    If there is zero work entered for a particular assignment in a given period, Project should NOT show a date in that assignments Actual Start field. As an example, try the simple file shown below. The first screen shot (Task Usage view) shows a planned start of 7/3/17 for both resources.

    The next screen shot shows what happens when a zero is entered into the Actual Work timescaled field for July for resource Joe. Note, the assignment row for Joe still shows "NA" for the Actual Start but the scheduled start is now moved to start 8/1/17.

    If you replicate this test, do you get what I show or do you get something different?


    Thursday, July 6, 2017 8:14 PM
  • Thank you, John, for the confirmation that the behavior should be as you indicated.  We agree but we are not seeing that behavior.  We are seeing that entering that 0 in July would populate the Actual Start date for Joe (and the task level too) at 7/6/17, the planned Start date.

    What version of MS Project 2013 do you have installed?  Our current version is 15.0.4937.1000. 

    FYI - last week a few of us had one version and others had a different version, one version it worked as you described and the other worked as I describe.  We are all on the version noted above now and the behavior for all of our team is as I describe, and unexpected.

    Thanks!  Monika

    Friday, July 7, 2017 1:55 PM
  • Monika,

    Thanks for trying the test file and the added information. For your reference I do not have Project 2013, I only have Project 2010 so unfortunately I can not do further testing. However, I can contact someone who has Project 2013 and Project 2016. If we can replicate or confirm the issue, it can be brought to Microsoft's attention. That process may take a few days particularly since this is a Friday. I'll update you when I find out more.

    Meanwhile, if you know which update was working, you could uninstall updates back to that version, or if that isn't feasible, recognize the issue in those instances when it occurs and manually overwrite the Assignment Actual Start field as necessary.

    For reference, there have been other instances where a cumulative update either caused a new problem or undid a previously fixed problem. It is the unfortunately reality of software changes.


    Friday, July 7, 2017 2:30 PM
  • Again, John, many thanks for taking the time to help.  Unfortunately, we are working in an environment where we have little to no control over which updates get installed and when.  So, it won't be feasible for us to work with IT to roll back to a version when it worked.

    It would be fantastic if we could have someone else replicate our issue and bring it to Microsoft's attention.  We are at a loss at how to do that.  My version number was provided.  I tried to insert a picture of what happens with a similar scenario to what you used - different results, but cannot get the image to submit after inserting, says it has to verify me?

    Thanks again, Monika


    Friday, July 7, 2017 6:06 PM
  • Monika,

    I've contacted a couple of my compadres to get confirmation. I'll let you know when I hear back.


    Friday, July 7, 2017 10:47 PM
  • Thank you, John.  I am very curious.
    Monday, July 10, 2017 6:31 PM
  • Monika,

    I heard back from both people and they confirm the behavior you see. Whether it is a bug that was introduced with a recent update for Project 2013 is yet to be determined. I need to run that past a contact at Microsoft.

    However, here is a workaround that may resolve the issue. Let's say you have a task with two resources assigned as shown below. Assuming you operate on a calendar month, (Project doesn't do accounting months), set the Status Date to 8/1/17, or since the status date is by default as of start of day on the status date you can manually enter the status date with a time which I have done (e.g. 7/31/17 5:00PM). The time won't show up when you look at the status date, but it is there.

    Now assume Bill worked full time in July so 128h is entered into the Actual Work field (not timescaled). Tim had no work in July so his entry is zero hours. The project is updated (Project > Status group > Update Project) as show below.

    The end result is as follows. Tim's work is shifted along with the new scheduled start date for his part of the task and there should be no date in the Actual Start field for Tim.

    Hopefully this helps.


    Thursday, July 13, 2017 4:11 PM
  • Hi John.  Thanks for checking.  Your workaround is exactly what we are doing right now.  We make sure we have statused all assignments that have started first then use Update Project to move any assignments that did not yet start that should have forward to the status date.

    I also thank you for sharing the info with your Microsoft contact.  My original post described how some of our team was on one version and some on another version.  Some of us had this unexpected result and others didn't.  Until they pushed the updates from June to all of us, now we all get the unexpected result.

    Thanks again!  Monika

    Tuesday, July 18, 2017 2:34 PM
  • Monika,

    I got a response back from the Microsoft contact and he confirms that indeed a change was made in the May 2016 cumulative update. The thinking is that a task can be considered started even though no work has been accomplished. I don't necessarily agree with that thinking but consider this scenario.

    Tim and Bill are assigned to work a three month task together. Bill is able to start effort on the task immediately but Tim is still working another task and only has time to briefly take a look at the scope of the task late in the month. Bill charges effort on the task but Tim's effort (brief look) is insignificant so no effort is charged. Did they both "start"? Some would say "yes" while others might say "no" but the bottom line is that the Project developers say "yes" and so the change was made.

    I suggest you continue with your workaround.

    I hope I answered your question even though it may not be the answer you wanted.


    Thursday, July 20, 2017 3:07 PM
  • Thanks, John.  That is an interesting viewpoint of when a task starts.  I can see how some would agree and others would disagree, given the scenario.  We will continue to do what we are doing to work around it, but it's good to know that it is known and intentional.

    Very much appreciate that you were able to get that checked with Microsoft.  Best, Monika

    Monday, July 24, 2017 12:44 PM
  • Monika,

    You're welcome and thanks for the feedback. Please consider marking my latest response as the answer.


    Monday, July 24, 2017 2:18 PM