Project for the Web Scheduling Engine Bug

[SlinginTaters]

Error Description

There appears to be a bug in the Project for the Web scheduling engine where Effort, Effort Completed, Effort Remaining, and % Complete do not stay in sync. This appears to depend on the sequence in which they are modified. GIF below showing a live example:

Testing & Reproduction Of Error

I devised a test to determine in which cases this behavior occurs:

1. I created 24 tasks in a Project
2. I modified values for each of them in different orders (they all were given a starting Effort of 10h and the project is set to Fixed Effort).
   1. Each task was modified 4 times - once for each of: Effort, Effort Remaining, Effort Completed, % Complete
3. I made these modifications in every ordered permutation of those 4 values (hence the 24 tasks)
4. I labeled which ones "failed" (their values got out of sync) and which ones "passed"
5. I also took note of which step they got out of sync at
6. I stopped at the "failing step" each time and did not  make additional modifications (see note on this later in post)

Test Results

NOTES:

• Tasks in the data below are named according to the edit sequence.
  • EF=Effort, ER=Effort Remaining, EC=Effort Completed, %C=% Complete
• Screenshots below are from my Org's default environment but I have reproduced this in a CDS/Dataverse named environment (configured for vanilla P4TW)
• Assigning (or not assigning) resources to the tasks appears to have no impact on this behavior

Final Project State with Pass/Fail labels

Here's the final state of the Project after all edits:

Where Did We Go Wrong?

The below table documents where in the sequence each task's data got out of sync. You'll notice that most of them did get out of sync (this is really not good), but a few stayed in sync:

NOTE:

Examples are not presented here, but continuing to change values after the data gets "out of sync" does not eventually result in the data getting back in sync. It appears to permanently remain out of sync once it's gotten into this state. The only resolution that I have found is to delete the task and re-start.

Apparent Cause

After boiling down the above information, it appears that this issue occurs when modifying values in the following sequences:

• % Complete -> Effort
• % Complete -> Effort Remaining
• Effort Completed -> Effort
• Effort Completed -> Effort Remaining

Put more concisely, this seems to be caused by the following sequence:

{ % Complete | Effort Completed } -> { Effort | Effort Remaining }

[#2]

@SlinginTaters I'll start by saying the scheduling engine in Project for the web is exactly the same as that used in Project desktop and Project Online, but obviously in Project for the web we don't give you access to all the settings you might change in either of those tools - so understanding why you get the result you get may be the problem here, rather than a bug.  Also it would be helpful in any reproduction of an issue to be very clear exactly what you changed, (from what to what) and what you saw at each step - and why you think the final result is incorrect (and what you think would be correct). For example - in your first task I can't follow what steps you actually took. You mentioned that you set each task to 10h effort. So for the first task for your 'EF' step did you change 10 to 6? If so, then setting EC to 4 would have set effort remaining to 2 anyway - so nothing to change at step 3? Or was effort set to 10, effort completed set to 4 and then effort remaining set to 2 (which would have updated Effort to 6. This would leave % complete as 40% in Project for the web, and the exact same steps would give the same results in a fixed work task in Project desktop. % Work complete (a field available in Project desktop but NOT Project for the web) would show 67% (Is this what you were expecting?). If so then 40% isn't out of sync - it is just not calculating what you thought it was. Here is the same task showing in Project desktop.

The calculation of %Complete is based on Duration (see https://support.microsoft.com/en-us/office/percent-complete-fields-84ec5068-4a34-497c-97eb-e12b6dc47...) and as Fixed Duration is the default scheduling mode for Project for the web this probably isn't confusing unless you change scheduling modes.  Also, in Project desktop you are able to set some options that change behaviors - something that is not available in Project for the web - to avoid some of the complexities that sometimes challenge people when using the desktop.

I'm happy to explain any of the other calculations if you want to give me the precise steps.
Best regards,
Brian

[#3]

@Brian-Smith 

Thank you for the insight!

I did some testing in P4TW and Project Desktop and I think the issue/confusion is more related to the engine in general (and it's only made more confusing in P4TW because of the limited fields shown), so I will pose it differently:

Here is my expectation - please tell me if this is flawed: % Complete and % Work Complete should theoretically be the same as long as I am not using resources with non-uniform burn rates. The exception to this would be if I modify Effort/Work after there are actuals on the task. My understanding is that if Effort is modified while actuals exist, new actuals will be calculated at the updated "burn rate" which is Effort Remaining / Remaining Duration. This updated time-phasing which is triggered by changes to Effort after actuals have been logged could cause % Complete and % Work Complete (really, Actual Work and Actual Duration) to get "out of sync". Again - we are leaving out considerations of non-uniform working calendars.

My confusion comes from the fact that in order to reset a task to it's initial state where this weird updated-time-phasing stuff doesn't affect the calculation, I need to zero-out all Work/Duration fields on the entire task and start over. That's the only way I can find to "reset" the task's behavior w/ respect to calculating actuals. I would expect that simply clearing actuals would be sufficient, but in fact I also need to clear out Duration and Work/Effort to trigger a reset of the time-phasing.

Here's an example:

1. Create a 5d 40h task
2. Set % Complete to 50% (actuals = 20h and 2.5d)
3. Change Work/Effort to 30h
   1. Past actuals don't change but future actuals will now calculate with an updated burn rate of 10h/2.5d = 4h/d
4. Set % Complete to 80%
   1. Actual duration is set to 4d and 6h of Actual Work are added (1.5 additional days at the new burn rate of 4h/d) so Actual Work is 26h and Work % Complete is 87% - makes sense according to my above logic on burn-rate calculations

At this stage if I want to re-set the burn rate/time-phasing such that Actual Work and Actual Duration are "back in sync" (essentially starting the "actuals" from scratch on the task), shouldn't I be able to simply clear out the "Actual" fields or the % Complete fields? Both of these actions would in theory reset the task actuals to 0 and thus reset burn rate. However, that does not seem to be the case. It appears that I also have to clear out Duration and Work (both "planned" fields) and start over to reset the under-the-hood burn rate.

This is all coming from someone (me) who only thinks they understand the under-the-hood calculations fairly well, and I'm making some inferences in P4TW land because, as you said, not all the fields are accessible to users. However, I do not feel that there is enough information available to the average user in P4TW to be able to reverse engineer this behavior or to make any sense of the calculations. I think the average P4TW user's expectation is that % Complete has some relationship at all to the other fields that are visible to them. If P4TW is truly meant for the audience it's marketed towards, this background knowledge of how the scheduling engine works in Project Pro should not be a prerequisite for understanding the numbers in front of them.

The "easy" fix would be to surface Work % Complete and Actual Duration to users - then at least they could figure out how the percentage are being calculated differently, even if they don't understand why they could be different. But as it stands today, a user can end up in a schedule state where they cannot reproduce the % Complete calculation with any of the fields visible to them. This is enormously confusing.

I also think a "burn rate" (how many hours/day are future actuals going to be accrued at) would be beneficial, but that's not as useful because users can calculate this information for themselves if Actual Duration is shown ( Effort Remaining / (Duration - Actual Duration) ). However, I still think the behavior of "resetting actuals" is a bit unintuitive because I have to clear more fields than should be necessary to reset the burn-rate/time-phasing behavior. Is this "burn rate" something that is maintained under the hood and is only recalculated under certain conditions? Also, if there is a better term that MS uses internally or that is used in the community for this, please let me know. I think burn rate is a loaded term and is probably not the right way to refer to this concept.

At any rate, this "burn rate" stuff and it's interplay with Effort/Duration (especially if either of those have been changed in-flight) could probably use better documentation - I can't find much online and am only guessing based on experiments in Project. I don't think many P4TW users are going to figure this out without access to Project Pro to test theories. Please let me know if there is existing documentation on this that I am just not finding.

----------------------------

Side note (though I do not believe it's super relevant at this point): Here are the values I used in the tests in my original post:

• Starting Effort: 10h
• Effort Modified to 8h
• Effort Completed: 4h*
• Effort Remaining: 2h
• % Complete: 20%

* I used 1h instead of 4 when 4h would cause the task to be 100% complete (since there seems to be a check for Effort Completed >= Effort that overrides all other behavior). This was used on the following test tasks:

• EF-ER-%C-EC
• EF-ER-EC-%C
• ER-%C-EC-EF
• ER-EC-%C-EF
• ER-EC-EF-%C