none
Actual work value does not change when actual finish date is updated to a prior week RRS feed

  • Question

  • Hello,

    We use Project 2013 with Windows 7

    Is there a way to show that actual work has changed in gantt view if a mistake is made and someone puts in the actual finish date of the prior week.

    Real example........

    Task1 has 20 hours of work.

    Joe Smith entered 6 actual hours in Task 1 week 1 ending 7/12, 6 actual hours in week 2 ending 7/19, 6 actual hours in week ending 7/26/2019 Task actual date shows 18 hours and remaining work has 2 hours. The task has been completed 7/26 as informed by Joe. When remaining work is entered as 0 the task is automatically closed 7/26. Someone makes a mistake and enters 7/19/2019 in Actual Finish after it auto closes. In Gantt view actual hours still has 18 hours but if you go to Task Usage view the 6 hours have been removed. Assignments add up to 12 hours and the Actual work task value shows 18.

    Why doesn't the Actual work field change to 12 hours? Is it because the task was already closed at 100%?

    Is there any way to recognize this other than making the update to Actual Finish date in Task Usage view and then watch the assignment values?

    Thanks

    Sunday, July 28, 2019 4:29 PM

Answers

  • Hotmail1,

    I simulated your scenario with an auto-scheduled fixed work task. Prior to the user entry error in the actual finish date, this what the Task Usage view shows.

    After I execute the mistake on the actual finish, this is what it shows.

    The task was completed on 7/26/19 with a total work content of 18 hours. By changing the actual finish date to a week earlier, the only way for Project to resolve the 18 hours work is to adjust the actual work for the first two weeks to 9 hours each. You say the assignments add up to 12 hours but at no point is the assignment shown as 12 hours, and why would it be, an error was made and Project resolved the error based on the data provided.

    At that point, recognize the error in the actual finish entry, correct it, and the actual work content will go back to what it really was, 6 hours each weeks for three weeks.

    Hope this helps.

    John


    • Edited by John - Project Sunday, July 28, 2019 9:38 PM wording
    • Marked as answer by Hotmail1 Tuesday, August 6, 2019 1:23 PM
    Sunday, July 28, 2019 9:37 PM
  • Hotmail1,

    Simple answer, I don't know. Using this scenario, Project presents conflicting data. This is what I get initially.

    Now when the task Actual Finish field is changed to 7/19/19, Joe's assignment actual finish date is changed to 7/19/19 and his 5h of actual work in the timescaled data (right side) is inexplicably deleted even though the Actual Finish field (left side) still shows 17h (i.e. conflicting data).

    However, when the task Actual Finish field is again updated to 7/19/19, both assignment actual finishes show as 7/19/19. Although Joe "lost" 5h of actual work in the first update of actual finish, in this update Jim's 1h of actual work in week 3 is moved back to week 2.

    Strange scenario. If the task was indeed finished on 7/26/19, as "informed by Joe" per your original post, then why was the Actual Finish field changed to 7/19/19? I don't think you should expect Project to resolve every type of human entry error.

    I do not know how Project 2016 or even 2019 would respond to this scenario. Perhaps someone else will jump in with their synopsis.

    John


    • Edited by John - Project Tuesday, July 30, 2019 10:39 PM wording
    • Marked as answer by Hotmail1 Tuesday, August 6, 2019 1:23 PM
    Tuesday, July 30, 2019 10:36 PM
  • Hotmail1,

    You're welcome and thanks for the feedback.

    John

    • Marked as answer by Hotmail1 Tuesday, August 6, 2019 1:22 PM
    Wednesday, July 31, 2019 3:01 PM

All replies

  • Hotmail1,

    I simulated your scenario with an auto-scheduled fixed work task. Prior to the user entry error in the actual finish date, this what the Task Usage view shows.

    After I execute the mistake on the actual finish, this is what it shows.

    The task was completed on 7/26/19 with a total work content of 18 hours. By changing the actual finish date to a week earlier, the only way for Project to resolve the 18 hours work is to adjust the actual work for the first two weeks to 9 hours each. You say the assignments add up to 12 hours but at no point is the assignment shown as 12 hours, and why would it be, an error was made and Project resolved the error based on the data provided.

    At that point, recognize the error in the actual finish entry, correct it, and the actual work content will go back to what it really was, 6 hours each weeks for three weeks.

    Hope this helps.

    John


    • Edited by John - Project Sunday, July 28, 2019 9:38 PM wording
    • Marked as answer by Hotmail1 Tuesday, August 6, 2019 1:23 PM
    Sunday, July 28, 2019 9:37 PM
  • John,

    Thanks

    Sorry. Its 18 hours but it has 2 resources not 1

    Set Joe to 6 hours, 6 hours and then 5 hours in the last week 

    Add another resource Jim that has 0 hours, 0 hours and then 1 hour in the last week 

    2 hours in remaining work. Now place 0 hours in remaining work and it closes. 

    Now when it closes at 100% change the TASK Actual Finish date to the prior week not the assignment finish date. The Task actual finish date was updated and it did not re-distribute the actuals hours it deleted that week where 5 hours and 1 hour were.

    Why is that?

    Monday, July 29, 2019 1:09 AM
  • Hotmail1,

    Simple answer, I don't know. Using this scenario, Project presents conflicting data. This is what I get initially.

    Now when the task Actual Finish field is changed to 7/19/19, Joe's assignment actual finish date is changed to 7/19/19 and his 5h of actual work in the timescaled data (right side) is inexplicably deleted even though the Actual Finish field (left side) still shows 17h (i.e. conflicting data).

    However, when the task Actual Finish field is again updated to 7/19/19, both assignment actual finishes show as 7/19/19. Although Joe "lost" 5h of actual work in the first update of actual finish, in this update Jim's 1h of actual work in week 3 is moved back to week 2.

    Strange scenario. If the task was indeed finished on 7/26/19, as "informed by Joe" per your original post, then why was the Actual Finish field changed to 7/19/19? I don't think you should expect Project to resolve every type of human entry error.

    I do not know how Project 2016 or even 2019 would respond to this scenario. Perhaps someone else will jump in with their synopsis.

    John


    • Edited by John - Project Tuesday, July 30, 2019 10:39 PM wording
    • Marked as answer by Hotmail1 Tuesday, August 6, 2019 1:23 PM
    Tuesday, July 30, 2019 10:36 PM
  • Thanks John

    When the person made the error, one of the reviews that was in place when making updates like this was to always check the task actual work field to see if it changed. We now know that we can't trust that in all cases.

    The task isn't always closed from the Task Usage view.

    Of course, the process is not to re-close a task anyway to a prior date but its also not to good when the task actual work field has one value and the timephased data area another.

    We were initially thinking that it may be an option setting that needed to be set differently so if the timephased area was deleted the overall task actual work field would be as well but it doesn't look like it.

    Anyway, there is no valid or logical reason for a person to make that error but it happened and with a strange result.

     

    Wednesday, July 31, 2019 1:35 PM
  • Hotmail1,

    You're welcome and thanks for the feedback.

    John

    • Marked as answer by Hotmail1 Tuesday, August 6, 2019 1:22 PM
    Wednesday, July 31, 2019 3:01 PM