My organization has been working with Microsoft support on these issues for many months now and we’ve provided, and continue to provide sample schedules exhibiting the symptoms noted in this thread. We’ve also met with representatives from the MS Project team to discuss these, and other issues. During this meeting, MS indicated that the protected actuals mode means actual work should only appear on tasks if entered via timesheet and that the tool should not “create” actual work (my paraphrasing). I mention that because 1) it’s good to know that their interpretation of the protected actuals option and ours align and 2) they recognize that when the option is selected, the tool should not magically create actuals.
The good news is that we are seeing progress. It appears some of the root causes have been corrected and the quantity of schedules we need to manually fix with protected actuals mode turned off has been reducing. For example, Project no longer zero fills actual work to the Resume date past the current timesheet period for split tasks. This was one of our major problem sources.
I’m also curious to hear about the results of Jeremy’s June CU upgrade. My suspicion, based on meeting comments, is that some of the root causes will be corrected, but not all. My organization has just implemented the April CU. Due to new, severe problems being introduced by the CUs (one of the other issues discussed), we’ve determined the safest approach is to remain a few CUs behind current.
Jeremy; you also noted Finish dates pushed out to 2076. We’ve seen this issue (ours go to 2049) and the problem appears to be specific resources on a task with a Peak value exceeding the resource’s Max Units. For example, John is 100% Max Units. John is assign to 5 day Fixed Duration Task A at 100% (assignment units) with 80 hours of work. However, the Peak units needed for John to actually complete the task is 200% (or any number > Max Units). When leveling, it appears Project tries to find a future time period in which John has Peak availability (200% in this example). It doesn’t and as a result, three symptoms appear.
1) Leveling takes a lot longer than normal
2) Task A will sometimes be scheduled out into 2049 or some ridiculous future date. Note that the Task Assignment Units value still shows 100% (what you entered), but Project is really using the Peak value to level the resource.
3) You will not receive an error during leveling about Assignment Units exceeding Max Units because, in this case, they match. But Project is really using the Peak value to level.
If you’re not familiar with the Peak field, add the Assignment Units (Task assignment level), Max Units (enterprise availability) and Peak (what it really takes to get the work done in the allotted time) columns to a Resource Usage based view and look for situations where the Peak value exceeds the Max Units. These typically appear on Fixed Duration tasks and need to be fixed manually by extending the task duration or reducing the assigned work. Hopefully, that will fix some of the goofy 2079 dates.