Change duration instead of dates?

Thank you Skye. I had looked at your link previously but just reviewed the first chart the first time. I have now read through and you are correct - this is very helpful! Stephanie Brown NXT Capital

hi there, were you able to access the link I referenced above? Workfront Support wrote a lovely section on how constraints come to be. "https://support.workfront.com/hc/en-us/articles/217297147-Task-Constraint-Overview" title="https://support.workfront.com/hc/en-us/articles/217297147-Task-Constraint-Overview">https://support.workfront.com/hc/en-us/articles/217297147-Task-Constraint-Overview Your task constraints will change themselves if you fiddle around with your dates for sure. For example, something cannot be set to "As soon as possible" AND have fixed start and end dates, so as soon as you change your dates, you will notice that the task constraint will automatically change to accommodate what it assumes was your intention. And yes, you should check your templates. Any task constraint on a templated task will carry over to the project. -skye

Hi all - thank you very much for all of the replies. Adding the Task Constraint column to my view, as recommended by Heather, helped considerably as I was then able to modify the constraint as I went to achieve the desired results. As a follow up question - where are these Task Constraints originally coming from? When I start a new project and start adding tasks - is there a default somewhere on my project or in a template setup where this is defined globally for my project? Also, when I added the Task Constraint column to my view my constraints were initially all over the place - I kind of expected that since I hadn't modified them they would have all be set to one constraint? Thanks again for the help. Stephanie Stephanie Brown NXT Capital

Thank you Heather. This was a super helpful recommendation and allowed me to achieve my end result. Stephanie Brown NXT Capital

Yeah, you would lose pred ability. So I don't see a way to accomplish that in WF. But changing the Duration is barely more difficult than changing the date. You're just changing one field instead of the other. The only difference is you have to do a little math. Hopefully if the plans are kept up to date regularly, you're only moving the date by a few days or a week, so the math is easy. Just keeping in mind it's counting in Business days. Honestly I also hated this process at first. But once I did it, the reality is it's not difficult at all.

Oooh, now that is an interesting idea, Heather, A few years ago (thread 23 on "https://community.workfront.com/discussions/community-home/digestviewer/viewthread?MessageKey=0a9d8b02-1f3e-4b61-af22-7d32e7f3b2e2&CommunityKey=aaafaff0-5e4e-4e38-8903-f1f990935567&tab=digestviewer#bm0a9d8b02-1f3e-4b61-af22-7d32e7f3b2e2">this post ), we enhanced our "http://store.atappstore.com/product/ubercalc/">UberCalc solution to automatically override (unwanted/inadvertent) Commit Dates "back" to their (official/reinforced) Planned Completion Dates (e.g. nightly), to ensure that Workers were aware of and aligned with the same timeline as the PM was intending. Following your "power to the Workers" suggestion, though, we could have UberCalc apply the reverse logic, automatically setting the (outdated/unrealistic) Planned Completion Date to match the (latest/human-confirmed) Commit Date, thereby keeping the PM (and owners, etc.) aware of what's most likely really going to happen. And (bonus) since UberCalc uses a filter to determine which Tasks to consider in each case, certain (top down) Projects could use the former approach, and other (grass roots) Projects could use the latter. In each case, it removes the manual grunt work of forever trying to "catch up" with the date changes, and instead simply presents the latest best known version of the truth. Regards, Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads

Have you looked at having the person assigned to the task change the Commit date (if your PMs are actually assigned to the tasks)? The assignee can go into the task and change the " This will be done by" date, the Project Owner then gets a notification that the assignee will be late (or early) and can adjust the duration or constraints as needed.

Yes! Okay, so you're both agreeing with exactly the conclusion I was reaching. The challenge I'm facing is that they want the system to do the hard work for them, without having to manipulate anything but the dates . i.e. they don't want the PMs to have to tinker with the duration or change task constraints. They just want them to be able to say "Okay, this task that was starting on 02/07 and I had until 02/15 to finish I really am going to need until 02/28"....input 02/28 in the end date and let the system calculate the duration, change the constraint or update the remaining tasks accordingly. I don't think there's a way to accomplish this - I'm either going to lose the predecessor ability or sacrifice duration. Christina Jarosz Ascensus

Yes I completely agree with Doug. Fixing Dates is a big risk and will in fact override your Preds. So we either change the Duration or change the Start Date (which does still fix a date, but it should at least allow the successor tasks to move as desired). Our basic rule of thumb is: If the Task has already started - change the Duration to move the end date to the new desired date. This requires a little math and sometimes some tinkering to get the desired date. But if they're updating the plan regularly, it takes about 30 seconds. If the Task hasn't started - it's ok to move the Start Date. This will change the Task Constraint to Fixed Start, but that's ok because the predecessors on subsequent tasks will still roll off this task and move everything accordingly. It would be the "head of the snake" as they say.

Hi Christina, Predecessors are most useful where the dependent Tasks Constraints allow movement, such as the "As Soon As Possible" Task 20 in your example, which is being pushed to start on 2/21/19 by Task 18, which finishes later than 1/30/19 on Task 19 (which Task 20's other predecessor; ASAP correctly taking the later of the two). Conversely, non-movable Task Constraints will override the Predecessor directive, such as the "Must Finish On" 2/20/19 on Task 18, and the "Must Start On" 1/29/19 on Task 19. I suspect that in editing the End Date, Workfront is also automatically changing the Task Constraint to Must Finish On, which in turn then leads into these non-movable situations. Instead, if I'm following what your director is after, I invite you to consider leaving all Tasks as ASAP (so they can move) and instead instruct the PMs to edit a Task's duration to push to the new expected Planned Completion Date. Regards, Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads