Commit Dates are killing us

[DavidCo3]

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.

[MichaelLa1]

This is great, Doug! It's my first time getting in to AtAppStore and I'm having a hard time gaining access to UberCalc to install/connect. Any advice or suggestions would be great. Thanks! Mike

[Doug_Den_Hoed__AtAppStore]

Ah, you busted me, Mike! I'm just about to step onto the golf course for the rest of the day, and I believe my colleague Malcolm is also out of pocket. I'd be happy to get you set up tomorrow though. I'm in Calgary (Mountain time) and currently open from 10am-11am, or after 1pm. Would you please send a meeting request to doug.denhoed@atappstore.com for a slot that suits you? Regards, Doug

[Doug_Den_Hoed__AtAppStore]

Hello fellow non-committers, I'd like to invite you to view this "http://screencast.com/t/MlrO66OC3tT">video of the "http://store.atappstore.com/product/ubercalc/">Synchronize Commit Date solution I announced last week, which shows how it works in action. Also -- with thanks to a colleague of mine at Workfront who pointed out that in principal, the Commit Date concept is a powerful communication tool when used properly -- I'm also pleased to announce that our solution can also be configured to EXCLUDE Projects where the As Designed Commit Date functionality is valued. I look forward to chatting further with those interested offline -- doug.denhoed@atappstore.com Regards, Doug

[Doug_Den_Hoed__AtAppStore]

Hi David. Welcome back from vacation. When you get to it, I look forward to your thoughts on our solution to your Commit Dates Are Killing Us challenge. As you were away, I would also be happy to extend our August offer to you, in appreciation for raising the original concept. Regards, Doug

[DavidCo3]

Hi Doug, Thanks for the welcome back! I've had a look at the video and read through the thread regarding the scope you used to build the tool. It looks like it should work for us. I will discuss with those who hold the purse strings. I've got a bit to catch up on, so any answer on this will likely be a week or two away I suspect. Would you license this separate to, or only with UberCalc? Obviously our natural preference is for Workfront to modify the system rather than us needing to pay for (very good) 3rd party solutions, but we will see how the ROI looks. Thanks for responding to the community concerns and I hope you already have some people signed up! Cheers, David.

[Doug_Den_Hoed__AtAppStore]

Thanks David -- I'm delighted to hear that you think it should work for you. UberCalc is the underlying framework that allows us to provide scheduled jobs such as Syncronize Commit Date , so they do go together; but only the former has ongoing annual licensing. When you're ready to proceed, please drop me a line at doug.denhoed@atappstore.com. Regards, Doug

[LauraRa1]

Sorry to go back to this but.... Doug.... You mentioned in your post to me that although you can hide the commit date for the user, the system still relies on the Commit Date. Could you please clarify what calculations it does/what relies on the commit date please? I now have a report that shows where the commit date doesn't equal the planned date and there's over 1400 tasks in that situation. I'm concerned but I don't know why I should be concerned. Thanks :)

[PhilipSt]

Hi Laura, The one concern I have is that the Worker who changes the commit date, only sees the new date, whereas the Project Manager still sees the original planned completion date. So, you are working to two different dates. Cheers, Phil

[EricLu2]

Hi: We have issues with comparing the commit date and the Planned date. The root of the problem is that the CLEARTIME function doesn’t work the way you think it should. As a result, when you compare two dates (DATEDIFF) and don’t want to consider the hours/time associated with that date, well, it doesn’t work. We also get thousands of tasks where the commit date doesn’t equal the planned date. That can happen because: 1) The commit date is originally set when the planned date is calculated originally. If you move the planned date, the default commit date doesn’t change (I think this is true…); 2) When someone commits to a date, and the planned date changes, they need to go back and recommit given the new planned date change; 3) The commit date was set to Planned date, but when you compare them, they don’t match - something to do with the hours, we have a ticket open on that. We have a ticket open to address the whole ability to find the difference between two dates without considering the hours. How are you calculating the difference between the two dates? Thanks, Eric

[LauraRa1]

Hi Eric I’m not looking for the difference between the two dates, only that there is a difference. I’m really just trying to figure out why I should be concerned about it, especially if our users don’t see the commit date since we changed it to show planned completion instead in the my work screen. So I’m wondering what WF uses the commit date for - that’s what I’m worried about. ☺ Laura Ray Project Support Analyst Bakkavor Information Systems Bakkavor Group West Marsh Road, Spalding, Lincolnshire, PE11 2BB, UK Direct: +44 (0)1775 763 010 www.Bakkavor.com // Laura.Ray@Bakkavor.com< [cid:image002.png@01D21E4C.E094ED90]

[DavidGu1]

Hi Laura, I think the overarching problem here is that changing this in the My Work page is not necessarily the end of the story. It obviously depends on how you're set up and how you're using the system but that commit date is front and center when you navigate in to any task page. The commit date is the ONLY date shown when you first land on a task page - directly under the assignments. So the problem here lies with any users who are going to that task page - they're immediately presented with a date that is NOT their due date (planned completion date). It's their commit date, which may or may not match the planned completion date. This then gets your resources off on the wrong foot because they're being shown a big date on the task page that SHOULD be their due date but it's not. So it's confusing. At least that's the experience I'm having with users. It doesn't matter that they can go to the Task Details page to find the due date, it matters that the due date isn't visually right next to the commit so they're being shown that these are two completely different dates. We've seen folks miss deadlines because they're staring at the commit date on the task page thinking they have more time than they do. As far as uses for the commit date, my understanding is that this is simply to communicate back to project owners that resources CAN commit to as far as timing - this allows quick and easy changing of dates by simply accepting a commit date change, which sets the planned completion to that new date. This is helpful if there's a comparison point to the due date and a little less helpful when that's several clicks away. Change takes time, patience and practice.

[LauraRa1]

Aha! I see what you’re talking about. That IS a problem! So what happens when there’s multiple people assigned to a task? Which user sets the commit date? Laura Ray Project Support Analyst Bakkavor Information Systems Bakkavor Group West Marsh Road, Spalding, Lincolnshire, PE11 2BB, UK Direct: +44 (0)1775 763 010 www.Bakkavor.com // Laura.Ray@Bakkavor.com< [cid:image001.png@01D21E5A.46ACB7E0]

[DavidGu1]

Any of them. The commit date can be changed by any resource assigned to a task. Which brings up the question who owns it in collaborative assignments. Fun stuff, right? Change takes time, patience and practice.

[LauraRa1]

Ok, but say user 1 of 3 assignees is the first one to say ‘work on it’ and then user 2 clicks on the ‘work on it’ button the next day and user 3 the day after that - which is the commit date? Also, one of my users just raised a good point - if the planned comp date and commit date are off by a few weeks, which date does the timesheet use to say it should be listed on the timesheet? Fun stuff for sure - well for WF Geeks lol Laura Ray Project Support Analyst Bakkavor Information Systems Bakkavor Group West Marsh Road, Spalding, Lincolnshire, PE11 2BB, UK Direct: +44 (0)1775 763 010 www.Bakkavor.com // Laura.Ray@Bakkavor.com< [cid:image002.png@01D21E5C.9CE05DE0]

[DavidGu1]

Sure thing. The first user to accept the task by clicking "work on it" sets the commit date. The system automatically defaults the commit date to match the initial planned completion date when the first user accepts the work. Changing the commit date after this requires an assigned resource to manually go in and make that change. Problems usually pop up when the planned date changes (because it cannot automatically change any commit dates). Users 2 and 3 are not changing the commit date, they're just accepting the work so the commit date remains what the system automatically set it to. The timesheet uses the planned completion dates and/or projected completion dates to determine what shows up. You can check your system setup to verify exactly what's going to show up for your users. Go to Setup > Timesheet & Hours > Preferences and then check the "Pre-populate timesheets with..." section. The commit date has a direct impact on the projected dates so that means checking projected dates AND planned dates means a task could show up on the timesheet in either situation. Basically, the more out of sync commit dates are, the more out of sync projected dates might be as well. Articles about commit dates and projected dates: https://support.workfront.com/hc/en-us/articles/216743818-Commit-Dates https://support.workfront.com/hc/en-us/articles/217182397 Change takes time, patience and practice.

[LauraRa1]

Great explanation, this helps a lot. Thanks David. I definitely need to address this with our Workfront Core Team so they can filter it down to all our users. ________________________________

[Doug_Den_Hoed__AtAppStore]

Sorry Laura -- your question about commit dates slipped past me, but thanks David: your answer was spot on! Regards, Doug

[LauraRa1]

No problem, you can’t catch all of them ☺ Laura Ray Project Support Analyst Bakkavor Information Systems Bakkavor Group West Marsh Road, Spalding, Lincolnshire, PE11 2BB, UK Direct: +44 (0)1775 763 010 www.Bakkavor.com // Laura.Ray@Bakkavor.com< [cid:image002.png@01D21FAD.A9EAB420]

[LauraRa1]

Hate to do this and add to this already lengthy post but we're having an issue with a report I produced showing tasks where planned completion dates don't equal commit dates. It's pulling in tasks where the dates match. We're assuming it's to do with the time stamp? Is there any way around this? This is slightly annoying, along with the fact you can't in-line edit the commit date within this report! I've attached screenshots of the report. Can anyone help?

[EricLu2]

Oh yes, I can help. The problem has to do with the fact that the commit date does not have a time associated with it and the planned date does. Adjust your report to show the hours associated with each attribute and you’ll see what I mean. When you compare the two, even though the date is the same, the hours are different, so they do not match. The next thing you’ll do is try to use the CLEARTIME function to truncate the hours from the task. Um, CLEARTIME doesn’t work correctly. I’ve had a ticket open for months trying to get them to fix it. We still don’t know how to compare those dates in a way that gets around the hours, using the functionality WorkFront currently provides. ☺

[LauraRa1]

Ok, I’m not completely sure why I would want to truncate the hours. I believe you for sure but I want to understand what you’re suggesting. So the report I’ve produced where I have a column in days of the difference between the two dates isn’t accurate then either? I think I’m ok with that because at least it puts up a red flag. Wondering what I’m missing. Thanks Eric ☺ Laura Ray Project Support Analyst Bakkavor Information Systems Bakkavor Group West Marsh Road, Spalding, Lincolnshire, PE11 2BB, UK Direct: +44 (0)1775 763 010 www.Bakkavor.com // Laura.Ray@Bakkavor.com< [cid:image002.png@01D2302C.19F5D040]