none
Project Server inserts 0h actuals into split tasks and moves stop dates RRS feed

  • Question

  • Hello,

    I work for a large UK based technology company and we use Project Server 2010 for our enterprise projects internally. We have been using it for 5+ years now and have only recently come across an issue which is:

    Project managers schedule a number of sequentially linked tasks with a finish-to-start relationship. The same enterprise resource is allocated on all tasks. Say each task is 2 weeks' worth of work and the resource is allocated 100% so the duration of each task is 2 weeks/10 days.

    Actual work can only be entered via timesheets. The resource inserts manually into the timesheet for week 1 the task scheduled for week 3, and enters 8h of actuals on Monday only. This time is submitted, which goes to the status manager for approval (this is typically the same project manager who scheduled the tasks in the plan). This shows up in the approval center as 8h on Monday highlighted in red and 0h in black for the following 4 days and the following week ie. the total duration of the task. 

    Project manager approves this time, and opens the project schedule in MS Project 2010. We can now see the 8h in the Task Usage view on Monday. Project manager saves and checks in the plan. The next time the project manager opens the plan, they can see the 8h of actuals in the Task Usage view, plus 0h of actual work in every day for 2 weeks! Project has moved the task Stop date to the last day of that 2 week duration, NOT to the last day the resource submitted actual work! Resume dates have also moved by 2 weeks, which has the effect of moving the scheduled finish dates out and therefore the whole project timeline.

    Our user community insist they have been working this way for over 3 years, and that this issue was NOT present on Sunday 17th Jan. On Tuesday 19th Jan this was reported to us as a critical issue. I have spent weeks trying to properly understand what is happening and doing root cause analysis. I can only think something has changed... but then we operate an established ITIL change management process and there have been no changes on our Application Servers or any of the WFE's, or in SQL. The final thing to establish is whether our end-user computing team have rolled out a group policy or other change to the operating system.

    Does anyone know if there is a bug documented in Project Server 2010 that could cause this behaviour?

    Thanks in advance.

    Wednesday, January 27, 2016 2:27 PM

Answers

  • Hello all,

    We think we know what has caused this. Our end-user computing team rolled out KB3114419 at around the right time-frame. When we remove this patch the issue disappears. When we reinstall it the issue is back.

    Laura

    • Marked as answer by Laura_ink Friday, January 29, 2016 3:31 PM
    Friday, January 29, 2016 3:31 PM

All replies

  • Hello all,

    We think we know what has caused this. Our end-user computing team rolled out KB3114419 at around the right time-frame. When we remove this patch the issue disappears. When we reinstall it the issue is back.

    Laura

    • Marked as answer by Laura_ink Friday, January 29, 2016 3:31 PM
    Friday, January 29, 2016 3:31 PM
  • Hi Laura,

    We are having a similar issue with project server entering 0h actuals and not having the ability to change the stop/resume dates or actual finishes.  This situation presented itself after we installed the Feb 9 hotfix KB3114568.  I rolled back to the Nov 2015 hotfix level on my client, but don't have control of the project server infrastructure patches.  Did you roll back the server updates as well or only the client patch?

    Thanks

    Mike 

    Friday, March 4, 2016 2:26 PM
  • Hi Laura, Mike,<o:p></o:p>

    We are also facing the same issue. <o:p></o:p>

    We first discovered it in February and at that time we did not have KB3114419 installed
    but well
    KB3114568.
    We later on did more testing and it looked like the problem was gone. Now we
    are facing the issue again and none of
    KB3114419 or KB3114568 is installed. Sev A incident
    opened at Microsoft as it impacts all our projects, preventing correct replanning.
    <o:p></o:p>


    Monday, April 25, 2016 8:55 AM