Estimated Due Date Calculation

Hi Greg, By marking each task as 50% complete, I expect you also (inadvertently?) set the actual date on each of them to "now"; ahead of schedule on all but the first, which (given the original duration) lead to the early finish. To model your expectation, I would set the first task (only) at 50% complete, recalculate timelines, and then look at the Projected dates, which should cascade off the ASAP relationships. Regards, Doug

Well yes, if I show the others as NOT 50% complete and put them back to New status, the estimated due date will be in line. But that's not the case. All the other tasks ARE in process and the actual hours on all of them are 4 out of 8, so they are all 50% complete. I'm looking for a way to portray the real/actual percent complete status and maintain and accurate estimated completion date. Again, I thought the logic would be that if I had a predecessor on a task, and that predessor is 50% done, that it would calculate the estimated completion date of the current task starting from the estimated completion of the predecessor task, plus the time left to do the current task.

I think I'm following, Greg; in my experience, though, the reason you are not getting what you want is that the Actual Date on those tasks with predecessors (2, 3, 4, and 5) is overriding their Planned Start Date. I have a blog post called "http://store.atappstore.com/2011/02/as-soon-as-impossible/">As Soon As Impossible that is somewhat related to this behavior, which might help. One other thought for you though (untested) would be to consider using the (rarely used) "https://support.workfront.com/hc/en-us/articles/216742058-Enforcing-Predecessors">Enforce checkbox on your predecessors, which states: When setting predecessor relationships on a project, users can choose to enforce that relationship. Enforcing the relationship means that the relationship can’t be circumvented by users beginning tasks early. By enforcing a relationship between Task A and Task B, Task B will not be able to be marked as started until Task A is complete. Enforcing relationships applies to all predecessor types. Keep in mind that enforcing relationships will lock the relationship to prevent users from starting tasks early. My thought is that perhaps, if you have Enforced turned on, the Actual Date will not override the Planned Start Date, as far as the Projected Dates go. Regards, Doug

Thanks Doug. I had actually thought of the enforced predecessor, but you can't put a successor task at 50% complete if the predecessor is not complete. So I'm stumped on how to have the project plan show real-world dates.

Hey Greg, I read through this thread and believe I have an understanding of what is happening. When you go into the tasks and mark them as 50% complete work has started on the task and ithose tasks now have an actual start date. So now that the task has an actual start date and work has begun on the task the remaining 4 hours of work needs to be finished within the 1 day duration assigned to the task. This is why you are seeing 4 hours for all tasks completing in the same day the task was makred 50% complete. I hope this helps, Adam

Hi Adam, Thanks for the input. Yes, I get that, but that isn't realistic, is it. All (10) tasks can't be completed in 4 hours. Because a task is "in progress", why does it ignore predecessor relationships then? Is there a way to set up the tasks (via duration type, etc.) that would make this reflect what is actually happening. And to be clear, here's the real world example: I User is assigned to 10 tasks to complete - each taking 1 day. Instead of fully completing one before moving on to the next, he completes 50% of it then moves to the next, etc. Once he's worked on each task 4 hours each, he now has 4 hours left for each task, so in real life, the tasks will be completed 5 days from now. That's the date I'm trying to portray. Thanks. Greg

Hi Greg, A predecessor would usually be used to indicate that the successor task can't start until the predecessor is completed (i.e. Finish-to-Start constraint). Obviously there are other constraint types, but that is the most common one. In your example, it sounds like there is not really that kind of relationship between the set of tasks. I.e. it is not "do one, then do the next, then do the next". I don't see how Workfront can be expected to estimate when each task will actually be completed if any of them can be worked on in any order at any time. Removing any system from the equation, I couldn't work that out with a piece of paper other than to say that if you want an accurate answer, then all of those tasks will be complete when the last task is finished. To achieve this you could set them each with the overall duration. Based on your example, all tasks would have a duration of 10 days, with 8 planned hours each. You can then group them under a parent task. Then, the parent task's estimated/projected due dates will be correct for that set of tasks to be fully completed. Perhaps Agile is another option for this kind of work....burndown could help indicate when they will all be completed? See if any Agile gurus have ideas..... :) Regards, David

Toughie, Greg. I read your usecase this morning -- thanks; I get it now -- and have been mulling it over since then. Arguably (but with respect), to me, these ought not to have predecessors between them if they can all be advanced independently. However using SNET (or MSO, or FIXT, etc.) to achieve the desired "step shape" would be painful to set up and maintain, whereas ASAP chaining as you have is relatively easy. Splitting the Tasks to more accurately represent the portions that can start early is another option -- either up front, or as it happens -- but I can already hear the squeals of "Micromanagement Oppression!" as I type the thought. Besides: even with two stacks of five half-the-size-each Tasks, your fundamental objective still exists; it just looks propitionately smaller. And so, I'm now of the opinion that what you want is not possible, out of the box. That said: a third party solution of some sort that Does The Math then Resets the Planned Dates and Durations to thereby ensure that your timeline best represents the Most Likely Scenario based on the Latest Information available at any Given Point In Time in order to make the Best Decisions Possible...? Yeah. I might know a guy. Regards, Doug

David, Thanks for the ideas. You're correct that really there aren't true dependencies, but they are put there in order to get an estimated end date. In this simplistic example, there is only one resource on this project. You'd mentioned that you dont see how Workfront can be expected to estimate it. This is how I expected the calculations to work: To calculate the estimated Due Date of Task 1, take (1-percent complete) * duration and add that time to now, and that's the est. completion date (i.e., dur = 8, pct. cpt = 25; so .75*8=6, so est. cpt date is 6 hours from now. Workfront does this now! Task 2 does the same thing, but it "starts" from the est. cpt date of task one, so if it's 50% complete, it's est. cpt date would be 6 hours from now (from task 1) PLUS, 50%*8= 4, so it would be 10 hours from now. Etc. I looked at your idea about grouping the tasks and making all their durations the same as the total duration and not using predecessors, but the issue is that the Est Cpt Date then becomes whatever the longest task is, meaning that the percent complete on all the other tasks have no meaning. meaning that est. cpt date will not be accurate. I'm going to continue to noodle on this, and hopefully others will too. Thanks. Greg

Greg, The calculation in workfront will not work as you have outlined in Task 2. Since the work on the task has started it will not look at task 1 and wait until it's last 50% has been completed. Once you have gone into the tasks and marked them as 50% complete the predecessors are null. If you would like you can submit a ticket to the support team and we can submit a feature request on your behalf to see if the product could function in this way, but currently it does not function like this. Adam Support Engineer