Changing Duration of Project

[ErikaGa]

Hi Workfront Team, Me again. Another question. We are looking for a way to be able to change the duration of the project timeline for accuracy, however we wanted to keep a record of the original dates for historical data so that we could possibly look at why we may have changed the duration. For example, I task our designer an original duration of 5 days, however now I have to change the duration to 8 days due to taking longer to create the proof. This then will change the project timeline. We kind of want to capture both the "original" planned timeline and also the "new" planned timeline. Looking forward to any and all feedback. Thanks, Erika Erika Garrett Gulfstream Aerospace

[SkyeHa]

Look into baselines. https://experience.workfront.com/s/global-search/baselines -skye

[ErikaGa]

Thank you Skye! We didn't even know about this feature, and I think that will help solve the angst of changing the project duration. Now to create a report that will visually display the comparison. Do you perhaps know of a good report that will show this visualization? Erika Garrett Gulfstream Aerospace

[SkyeHa]

I don't know reports really well (I don't come from a background where I have that experience so it's a struggle to figure out what people want to see in a report unless they straight up tell me). I have 2 charts that I created for one of our teams. Unfortunately they employ the use of custom fields, but that's sometimes how life is. The challenge was that the team wanted to see where the slippage was happening on specific tasks (look up Milestones https://experience.workfront.com/s/global-search/milestones ) -- and they wanted to see this on a chart, not a report. So I created two calculated fields, which is sometimes the only way you can get a more visual report. This one (I called this field "Slippage") gets reported to a chart as an average, per milestone: WEEKDAYDIFF(Default Baseline Task.Planned Completion Date,Actual Completion Date) This has to be formatted as a number field, so don't forget that part otherwise you'll have to re-do it. It calculates the difference (in weekdays) between the actual completion date and the original (baseline) planned completion date, and the resulting chart shows different bars to denote different milestones so you can see which milestone has the biggest "average slippage." This next field gets reported to a chart and each milestone gets reported as either being late or not late: IF(Slippage<=1, "On Time","Late") The "slippage is less than, or equal to 1" part: basically if it's a day late we don't really care, right? (if you care, just make that number 0) So anything less than a day late is considered "on time." Otherwise it's late. Then this all gets reported on a bar chart as well, one bar per milestone and I stack them so I can see two colors per bar: one for the lates, and one for the on-times. Honestly, the thing that was the biggest pain in the neck was making sure the custom form with those two calculated fields would populate into every task we needed it to and making sure that no matter what we did, the calculations would faithfully update. (even now, I'm suspicious) -skye

[Kelly_Wehrmann]

@Skye Hansen - Interesting Solution! How do you account or "update" the tasks when/if the default baseline flag changes? Is this something that the Project Owner does as part of their process (recalculate custom data on the tasks) if/when they change the default baseline flag? Or is this handled by some other process? As always, thanks for your contributions to the community, Skye! :) Admin Kelly-Wehrmann SSFCU

[SkyeHa]

@Admin Kelly-Wehrmann -- good question and something I ranted extensively to Matt Broschinsky about during Leap. There are calculated fields which are dynamic (update themselves) and calculated fields that are static (require a recalculation). (I'll elaborate below) My rant to Matt was that you can't tell which ones are dynamic and which ones are static. Here's an example of a dynamic calculated field. If you put a calculated field on a custom form in an issue looking at the issue Name, for instance, you'll notice that when you change the name of your issue, the calc field will update itself immediately. I used this on a form where the assigned worker needed the first 30 characters of the issue's name. Here's an example of a calculated field which requires a recalc. If you put a calculated field on the issue that looks for a project custom form field, and you update the project's custom form field, then you'll need to do something to the issue to get the calculated field to update itself. (e.g. re-save the issue's custom form) It's been a while since I tested, but I think for our purposes and the way we use the system, every test I ran indicated that when either the default baseline changes or the Actual Completion Date changes, my calculated fields will update themselves. So for these particular calcs, it won't be an issue unless I've somehow missed testing a workflow that our users normally use. (which would not be the first time that happened... ;) ) Anyway, that's why we have a sandbox, right? Would love to hear more feedback from other experiments along these lines :) -skye