Expand my Community achievements bar.

Do you have questions about the migration to Adobe Business Platform? Come join our upcoming coffee break and ask away!

Projected v. Estimated?

Avatar

Level 2
I am trying to understand if our teams should be tracking to Projected dates or Estimated dates. I "believe" the critical path (and the project condition) is linked to the projected dates, what value are estimated dates? Mitchell Tatum Confluent Medical
5 Replies

Avatar

Level 8
At a high-level summary, I believe Projected dates are over-written by commit dates while Estimated dates are not. So that... As a team member (worker), I have a task assigned with an effort of 40 hours, and a duration of 5 days. It is due to start on the 1st of the month I log time to say I started on time, I've completed 10 hours, and I'm 20% done. This indicates it will take 50 hours, not 40 so projected AND estimated dates show a completion date 6.25 days after the start, which (given the weekend) is on the 9th of the month. Planned completion date = 5th Projected completion date = 9th Estimated completion date = 9th I then change the commit date back to the 5th - I'll get this done on time, even though I'm behind. Planned completion date = 5th Projected completion date = 5th Estimated completion date = 9th Estimated will not update unless I say (for example) at 20 hours I'm 50% done to bring it back on track. Note that the project owner can't change the commit date - they can see it, they can reject it (not update the planned date) but it doesn't change the projected date unless the assignee manually changes the commit date back. So if you want your PM to have the final(ish) say, use Estimated (Planned + time logging). If you want everyone to contribute, use Projected (Planned + time logging, overridden by Commit dates). Barry Buchanan - WMA Work Management Australia

Avatar

Level 10
Hi Mitchell, Further to Barry's summary, this help article also contrasts the two, and concludes with the assertion that "In comparison with the scenarios described above for the Projected Dates, the Estimated Dates always reflect the real analysis by the system on when the task will start or complete regardless of the Constraint or Commit Dates." Regards, Doug Doug Den Hoed - AtAppStore

Avatar

Level 2
Thanks, this is very helpful. Seems keeping an eye on Estimated completion is smart, along with Projected. Is the critical path designation and project condition based on projected v. planned only? In other words, do estimated dates every play into critical path or project condition calculations? Mitchell Tatum Confluent Medical

Avatar

Level 10
Hi Mitchell, In my observations, it is a Task's planned completion date (for the typical ASAP left-to-right plan from start projects) that drives whether that Task is on the (one) Critical Path that - should that Task slip at all - the Project's planned completion date would then slip. That said, your concept of using either projected or estimated dates in conjunction with critical path is intriguing. Would you care to elaborate with any usecases (or ideas or hunches) to imagine either date (projected or explained) might be employed? Regards, Doug Doug Den Hoed - AtAppStore

Avatar

Level 2
To try to test out a use case, I put in a simple project: task1 -> task2 -> task3 -> task 6, all are 3 days in duration. task4 -> task5 -> task6, all are 3 days in duration. Take the project to "current", recalculate the timeline. All tasks are "as soon as possible", "calculated assignment". Viewing the ghantt view, the critical path is task 1,2,3,6. For all tasks, planned=projected=estimated. Condition is "on target". For reference, the finish date is September 5th in this example. If i take task 4 and assign it, but then commit to having it done September 3rd or later, and recalcuate timeline. then strange things happen... -the critical path switches to tasks 4,5,6 (rightfully so) -the projected dates are pushed out. -yet the project condition still shows "on target" So in this case, although projected are farther out than planned, the project condition stays on target. Also to note, estimated = planned So, I guess that is not what I expected. I expected that the project condition would light up if the projected > planned. Maybe the best option is to track planned completion v. projected v. estimated, and then monitor the project condition for good measure? Mitchell Tatum Confluent Medical