Delete Commit Dates?

Hi Amy, I don't know of a way to do that, but they shouldn't be causing much harm. Dependencies in the project don't use the Commit Date. It's just a date for the Assignee to communicate when they'll be done (and view their work in My Work or Home). Once you have that information you can either agree and change the Planned Completion Date of the Task to match, or have a negotiation (move some of their work or reassign etc.) and change the Commit Date. But it shouldn't impact your project plan. Is there another pain point being caused by this?

Hi Amy, To clear the Commit Date, you can manually remove and then re-add the Assignment(s), or if you'd prefer something more automated, I invite you to consider our "http://store.atappstore.com/product/ubercalc/">UberCalc solution, which will (for example) force the Commit Date back to the Planned Date each night, as the latter changes from time to time when schedules and plans shift around. Regards, Doug Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads

Vic - The only drawback is that I have team members that put in commit dates for tasks that are waaaay out in the future. They are making my Projected (not planned - just projected) completion date look wildly off because the planned dates have moved up based on predecessors getting completed. I also originally thought it might be driving my Project % completion (it doesn't move much even when I close out lots of tasks), but based on what I'm reading, it shouldn't be impacting it. I also just don't like that it's setting Commit Dates automatically for tasks that I assign to myself and I'd like to get rid of some of those. Thanks! Amy Amy Widicus

Hi Amy, Yeah they don't impact your project % complete. That'll be driven by your Planned Hours or Duration, depending on how you configured it. I hear you on the large disparities in the Projected vs Planned. And Doug's workaround is the only solution I know of if you want to go through that. Or the easiest way to accomplish what you want is to simply ignore the Commit Dates and the Project Completion Dates. They shouldn't hurt you. But I would consider viewing the Commit Date as your friend �� . I guess I view it as a valuable tool. It's another communication option for the PM and team members to communicate dates and obtain any early warning signals. For me the Project Plan is all about early warning detection. The sooner I know of a scheduling issue, the easier it is to recover. Like you, I use the Projected Completion Date to compare to the Planned Completion Date to tell me if something is off (early warning). This could actually be your early warning sign from the team. For example, why are they setting them so far out? If the answer is that's when they truly believe they'll get them done, you get your warning that the project (plan) is now in trouble and you can have an important conversation to determine what to do (i.e. remove other and/or outside tasks from their plate, reassign tasks, etc.). If they don't have a valid reason for moving the dates out so far, it's a training opportunity �� . And once they start using them effectively you'll gain another early warning tool. There's really no right or wrong, it'll just be up to your preference. But based on the WF constraints, I believe your options are boiled down to: Ignore Commit & Projected Completion Dates (even remove them from your View) Doug's method of unassigning and reassigning Embrace the Commit Dates �� . Best of luck!