Please can someone help me? I have a multiple projects on the go through project server and within most of them we have started to see more and more broken tasks in the future. We are not manually breaking the tasks. In some cases we can pull the bar back to the present day, however in most we can not make any changes to the bar or within the task usage view to remove this break, with the following error showing:
Could not modify work entered by a team member.
We cant make that change because Project Web App is set to only allow actual work to be entered by team members through Timesheets or My Work.
Why is this happening? The break is in the future, why can I sometimes make changes and some times not.
Many thanks for any help possible.
I’m not sure what you mean by broken tasks but I’ll respond based on my assumptions. What version are you using? There have been several bugs in 2007 and some in earlier versions of 2010 that will inaccurately sync timesheet actuals to the project schedule. I have not heard of this as a problem in 2013 and certainly not to the extent that you are inferring. If the issue is limited, you could temporarily uncheck the “Only allow task updates via Tasks and Timesheets” setting and manually fix the issues directly in Microsoft Project. I recommend doing this off-hours to prevent other problems, and make sure you recheck the checkbox when you are done. If it is happening consistently and growing, I would suggest submitting a ticket with Microsoft.
We are currently running MS Project 2013 configured to only allow task updates via timesheets. We see the same error and it’s a bug in project. We’ve found that Project will on occassion, plug zeroes (0) into the future actuals fields for some resources on some tasks. Meaning, if you look at a Task Usage Time Phased view of the data, you will find resources that have values of 0 (not null/blank) in their actuals fields for future weeks. We’ve also seen this occurring in the past where project will add zeroes to the actuals 1, 4, 8, etc. weeks prior to the tasks actual start date. We’ve reported this bug to MS and it was supposed to have been fixed in a recent CU (we’re up to July) but it wasn’t.
What the error is telling you is that the scheduling/leveling engine is trying to adjust the task, but moving the task on the timeline would mean changing what it thinks are actual hours entered by timesheets.
How do we get around it?
In some cases we can’t. We will occasionally schedule what we call blackout periods where we block all PM access to the tool, turn off the switch to only allow actuals entry via timesheets, and then we manually fix project schedules by removing the zeros manually. After all known schedule problems are fixed, we reset the actuals entry by timesheets only switch and then open access to the tool to all PMs.
Some other things we’ve found that occassionally work.
1) In a Task usage view for the task having the issue, identify the resource(s) containing the erroneous zeros into the future and play around with adjusting the resources remaining work. Set the value to 0, set it back to what it should be, etc.
2) As dumb as this sounds, switch the task from Auto Schedule mode to Manual schedule mode. We’ve seen scenarios where every switch from Auto to Manual removes a week of zeroes from the future. So you may need to do this many times. We can see no reason this should work, but it sometimes does.
3) In timesheets, open up the Actual Finish date for entry. Have the resources with zero future actuals enter in an actual finish date of the desired date. Then, once they are processed, the PM should go back and adjust the remaining work as necessary.
We’ve been dealing with this bug/issue since we installed Project 2013 in May and we can’t determine what specifically is causeing these sitiuations to occur.
Hello Larry and Daryl,
Thank you both so much for your replies. It has been driving me crazy. I have been trawling the web and many forums trying to find a reason and in the end decided to ask the question myself. I am glad I did!
I will figure out how to raise a ticket with Microsoft. I will check with our IT as to what CU we are up to as we are on 2013 and configured to only allow task updates via the timesheets, and we will look strongly at blackout periods to manage fixing projects without interference from others.
Thank you again.
I was wondering if you have new development to share concerning MS-Project that on occasion will plug zeroes (0) into the future actual fields. We’re experiencing the same problem and what I find alarming is that your post dates from September last year and Microsoft still have no clue on what is causing this. I am afraid the resolution is a bit further that lurking at the next corner.
Thanks for any help you can provide.
We are running into the same problems. Zero actual work in the past and the future. The only thing that we have discovered as a root cause is that it occurs when enterprise resources and local resources are assigned to the same task. Sometimes it gets resolved if the resource submits a new start date or finish date when submitting updates but not always. Otherwise we have to resort to black out periods to change the server settings as mentioned in the previous post by Daryl.
Does anyone know when this will be fixed?
Our company has documented several scenarios in which actual work (zero hours or otherwise) appear on tasks. These hours may appear before the actual start date (in one instance, 5 years), and in the future. We also have several other instances for which we can’t document the cause.
One cause is the option to allow Split Tasks. When checked, Project schedules remaining work following a retained logic model and the remaining work is scheduled after all predecessor task work is done. The date the work is restarted is stored in a Resume date field. Unchecking the Split Task option then follows a progress override model and the tool schedules all work for tasks already started to resume on the next day. When Split Tasks is checked, the remaining work is given a Resume date and when time is applied, Project zero fills actuals out to the Resume date which could be weeks/months into the future. When Split Tasks is unchecked, it breaks scheduling dependencies and in effect, the project completion date is now unreliable. I mention this because the answers not as simple as unchecking the Split Task option. There’s consequences either way.
Another cause is closing tasks with non-enterprise resources that have remaining work. When these are closed, project assumes the remaining work must have bee completed and then moves the remaining work into actuals. Project assumes the work was completed on the days it was planned, which could be future dates.
We’ve also found that directly updating the Work field will cause actual work to appear. Recommendation, enter all remaining work adjustments in the Remaining Work field.
And finally we’ve also noted that closing a task with a future finish date will hold the future finish date and add actual work hours to the finish date. Recommendation: Set the Remaining Duration to 0 days, Set Remaining Work to 0 hours, then close the task.
We have finally gotten the attention of MS on the issue of actual work appearing in tasks when it shouldn’t. As of this date, they will be assessing our documentation to determine if it’s really a bug or if the tool is working as designed. Best I can provide at this point.
Has anyone had any more updates on this issue. It has been happening on and off for months are in the past few weeks I have seen a significant up-tick in issues. While I still don’t know what is causing the issue, I have been able to pull the end dates back in.
For us, we are using Project Server 2013 Jun 2015 CU. We are using single-entry mode and actuals are only allowed for the timesheets. Our problem is future actual finish dates, (and future actuals in general), but some of these end dates are getting pushed out by decades!
The workaround I have found to repair the issue is through using the Tasks.aspx page. If I go in as a delegate, select the task with the future finish date, edit the end date of the task to the last working day of actual hours on the timesheet. Save on the task page, and then submit that one task for update to the PM. Have the PM approve and publish. Usually this will pull the end dates back in, though in one case, I had to add 1 hour in the schedule, then remove that 1 hr and it updated correctly. I do not have the resources take these steps and have been doing it as an admin delegate and while it is working, it is just a bandaid.
Has anyone figured out where these issues are beginning? It seems to be happening to PMs and resources alike!
Any help or updates would be appreciated! I have working on testing the May 2016 CU, but so far, I am not hopeful that the issue has been resolved.
I’ve been following this thread since the beginning of the year. I work for an organization that is heavily impacted by this issue.
We are seeing projects with finish dates that can be pushed as far as 2076 (I did manage to reach the limit of 2146), with tons of assignments with 0 actuals in the future.
We developed a VBA macro that we use to cleanse the plans, but an action as simple as a timesheet update will destroy the schedule. As soon as an action that triggers a call to the scheduling engine is done, the plans become a mess…
As Daryl, we did a lot of research to determine whether it was poor scheduling practices, bad infrastructure, inconsistent project pro CU deployment across the various project users, bad language pack versions, etc etc
We’ve had a support ticket opened with Microsoft since February : at the beginning their conclusion was poor project planning…even though I pointed them to this discussion entry, it took a long time before they started changing their mind.
So about a month and a half ago, we were told that the May 2016 CU *might* correct our issue, but we’ve tested it as soon as it was released and it didn’t help, the problem could be reproduced very easily.
We then have been told about three weeks ago that the June 2016 CU will *this time* really target this/our specific issue. I find it hard to believe as they have been denying that the problem comes from the product, but everything is possible…
So let’s hope that this June 2016 CU fixes the problem once and for all…we did reach the same conclusion as Daryl, unchecking the “allow task splitting” does prevent the problem from happening, though I did manage to introduce 0s in the future even though the box was unchecked, might have just been a bad manipulation.
I’ll go back to this thread and post the results of our CU deployment tests as soon as the package is available, which should be next Tuesday.
Thank you Jeremy for keeping us all updated. I’m sure we all will welcome your update once you test the June CU.
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.
hurray, June 2016 CU is out !
The Project Pro CU does contain specific corrections to the actual at 0 in the future, I’m currently deploying it and will test it ASAP, I will let you know the results of the test, probably tomorrow.
The Project Server CU doesn’t seem to contain any fixes regarding the issue, but I’ll deploy it in a lab and test, we never know.
I’ll post back soon to let you know how things goes, hopefully you all will be able to test the CUs as well.
P.S: thanks a lot for the help and detailed description Daryl, I really appreciate that we can share our experience like that. I was aware of that new Peak field but never realized it could be the cause of the 0s. On some of the plans our PM manage here, I even found out that they planned people at 4000%, no wonder things break….
Good point on the CU version to remain behind, I usually advise my clients to not deploy CUs right away and instead to wait about 3 months so that others find the regression bugs for us 😉 However, due to the nature of the problems we have, we decided to make an exception this time and if our lab tests confirm that the 0 bug is fixed, we will deploy ASAP.
I’m sorry – I wasn’t precise in my language. Stephen’s had a resurrection lately and it’s wonderful to see him healthy and playing well. But as a songwriter, I think he faded away a long time ago. No one was a bigger fan of his during Buffalo Springfield and early CSNY but I can’t name more than a handful of songs since 1975 that I’d play to a stranger to convince her Stephen was an important songwriter–compared to the bucketful from 1966-75.
cartier bracelet fake http://www.thislovebangle.cn/cartier-love-bracelet-white-gold-replica-b6035416-p-269.html
it took a bit longer to test but…Project Pro June CU does contain a fix for ONE of the ways that inserts 0 actuals in the future.
The scenario describing the fix is exactly the one we have reported to Microsoft, so that’s good news.
However, it was just one symptom that we had identified, as there are plenty more ways of creating the problem, I unfortunately have to report that neither the Project Pro CU nor the Project Server CU fix this issue.
It’s not exactly back to square one, as we definitely are progressing on this issue, but it’s a long slow and painful process… the project manager team’s confidence in the product is at a record low…
We’ll keep working on the case and if we ever find a solution to this problem, I will post back on this forum.
thanks to all that follows this thread and participate.
Has anyone been able to verify this issue is resolved with June, July, or August CUs? We are having the same problem, but would like to know before deploying the July or August CU if there is an improvement.