Question

Commit Dates are killing us

Forum|Forum|9 years ago
June 29, 2016
75 replies
8014 views

Hi, Commit Dates are really killing us and causing a lot of confusion/frustration with users. e.g. A task is originally scheduled for a certain date and an assigned user clicks 'Work On It', Workfront sets the commit date to the planned date (assuming the user doesn't propose an alternative commit date - and we ask them not to do this). If the task's planned date is later changed, the user's original commit date remains. Our users don't remember to go and update their commit dates on such tasks. This then affects tasks' and projects' projected dates, and more confusingly for the user, it leaves the original commit date on their mini-calendar on the My Work screen. We would love to just be able to switch off the Commit Date functionality completely. As this doesn't appear to be possible, how else can we try to keep the commit dates aligned with the planned dates? There doesn't seem to be a way to centrally edit commit dates (even one-by-one, let alone in bulk). The only way I know of doing this is to log on as the user and change the commit date on each task. This is impractical with thousands of tasks in progress per month. Do other customers have this issue? How do you handle it? We have a team who are in charge of scheduling people at the right time, so we really don't need the users to be setting alternative commit dates. Thanks, David.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

K

KatherineHa1

Yep - we struggle with Commit Dates as well. Big time. We have customized the My Work tiles to no longer show the Commit Dates (but to show Planned Completion/Due Date instead). We instruct users to then group and sort their WOrking On list by planned completion date instead of COmmit Date. See attached. This has helped somewhat, but then the calendar above the My Work list is not in sync with the list below - b/c the calendar still shows tasks and their commit dates rather than the planned due date. I have heard rumblings that WF is considering getting rid of (or at least the option to turn it off in your instance) Commit Dates.

K

KarlenRu

I agree. The ability to turn off commit dates would be helpful. It really erodes the ability to have a clear date when something is due, and it's hard to keep a consistent approach when certain features use the commit date and are not customizable.

P

PhilipSt

I have created a Project report with all eight (yes, Eight!) task start/finish dates displayed. It's only useful to explain to folks why they should not mess with the Commit Date!! :)

M

Mohini__Mini_Si

Commit dates are an issue for us as well. We also have an issue where, even if a commit date is changed, people will get Overdue Notifications based on the orginal commit date. Another issue that one of our users have had is getting an over due notification on a task that was marked complete a few weeks ago (for example the task is marked complete on 6/8, the user received an overdue notification on 6/23).

D

DavidGu1

Agree with many of the posts on here about this topic. We also experience issues with commit dates. It's a nice idea from the perspective of giving your users a tool to set a new due date when they can't commit to the current planned date. BUT in practice it's a mess because we deal with shifting timelines and planned dates on a regular basis. The fact that a commit date can't be over written when a project owner is replanning their timeline without unassigning and then reassigning users is a pain. I get you don't want someone arbitrarily moving something a user has specifically committed to but when the users don't also update their commits after timing changes this all falls down. We've done some training on this and found that some users do engage with this (mainly some of our developers) but most do not - they feel it's several extra steps they have to take every time the client moves a deadline on us and is wasted effort on their end. I'd love the ability to turn this feature on/off for individual groups. I could also see it being helpful if the UI of the task page and My Work page provided a side by side comparison of Commit to Plan dates. Those dates really only work well when in direct comparison to each other. Otherwise a resource sees the single, most prominent date and ignores the other. Change takes time, patience and practice.

M

MichaelLaberge

Just stumbled upon this thread. We face/struggle with the same thing. The working on calendar is one of the best tools for users but we can't realize its full potential because of these sticky commit dates. A while back I submitted a product enhancement request to give system admins the ability to toggle this feature on/off. Hoping these rumblings you speak of are true, Katherine!

D

DavidCo3Author

Hi Michael, Regarding the Working On calendar.....my understanding is that it only shows Planned and/or Projected Dates, depending on which you have chosen. Commit Dates wouldn't directly show, unless you are talking about their effect on projected dates? One related thing we would like changed is for the regular Calendars to not show Actual Dates. We have set them up to show Planned Dates, but as soon as there is an actual date, it shows these, which really confuses users. Regards, David

E

EricLu2

Commit dates are a pain. The original intent is noble, to be sure, but in practice, it causes untold confusion. We created a custom attribute on the task called "Promise Date". Only the Project Manager/Owner can see that attribute in the custom form, so only the PM can change that date. This is the date that we promised someone the task would be done. It acts like a Commit Date, but isn't readily changed, which reflects our desire to not readily change our promises. Commit Dates, on the other hand, can change at any time, at any frequency. We don't want to run projects where people are changing their committments that readily. We want continuity and consistency in what people do. The current commit date functionality creates the impression that people can change their committment at any time, and that isn't what our culture values. I'm all for a system level setup flag that shuts off Commit Date functionality. Eric

M

MichaelLaberge

Yeah, that's how I understand the Calendar functionality as well...planned vs. projected. I was referring to the My Work weekly calendar view though. That view only populates commit dates to my knowledge. I have my group's Working On tab set up so they can see both the planned date (what's in the schedule) and the date they committed to. They are able to change the commit date directly within that tab, which seems easy, but typically forgotten and seen as an added, unnecessary step. #NoMoreCommitDates

M

MartyGa

Agree with all the comments. Workfront makes it VERY difficult to replan a project. Once a user "commits" to having work done on a date, that's it. Put the project on hold, and the task stays in the persons Working On queue. Restart and replan the project, no problem --- the planned dates change but not the commit date that is sitting right in front of the person doing the work. Then you also have the issue of the commit date driving the Projected Completion date, so in the case of the replanned project, you're all Green because the commit dates may be WAY before the planned date. ARGH!

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded