Tracking and reporting on late due dates

How does everyone track and report on lateness?

Do you base your reporting once a task status changes to "Complete"? If so, how do you ensure it is accurate (i.e. is it late because the assignee forgot to change the status or is it really late)?

Also, how do you account for when the due date changes? If you change the task date, how do you compare to the original (or previous baseline) plan?

Any ideas would be helpful!

Find more posts tagged with

Comments

Maria Phillips

I would also like to know - I should think this falls under risk management, as late tasks will snowball until a person is swamped. For us, that is one of the top things we are using Wrike to keep on top of!

Pietro Poli

Hello @Rosalynn Mok,
We have an automated control for task movements.
That is, every time a task is moved, we increase a custom field (nr moves) by 1 unit.
We also save the Original Due Date so as to obtain a report on:
1- How many times the tasks are moved
2- How much average time passes from the original due dates to the current ones
Of course, we can divide this report based on the task statuses (active, completed, canceled, deferred).

In addition, on tasks, marked as High Priority, in the event that the due date is moved, a comment is started for the author, assignee, assignee's manager that says "A high priority task has been moved".

I hope it helps

Kelsey Rudolph

Hello!

I've developed a process to track project completion dates more effectively. It involves three custom fields:

OG Finish Date: This field records the requested finish date when the project is submitted, which initially matches the project due date.
Date Change Reason: This field is used to document any reasons for changes in the project completion date.
Date Shift: This field calculates the difference between the OG finish date and the due date. If the difference is greater than zero, it shows red, indicating a delay. If it's zero or less, it means the project was completed on time or ahead of schedule.

Here's how it works:

An automation auto-completes projects if all subtasks are finished or canceled.
When a project is completed, an automation @mentions me and updates the due date to the current date.
If the Date Shift field shows red (due to conditional formatting indicating it is greater than 0 days), I manually investigate the cause of the delay and update the Date Change Reason field accordingly.

Although this process isn't perfect since I have only found a way to easily work at a project level (hence why I need to put eyes on the individual tasks), it helps me identify areas where the team might need additional training or where certain tasks consistently run over time, suggesting a need to reevaluate the project blueprint.

Tiffany Sands

Hi @Pietro Poli I'm trying to do something similar where we count how many times something is sent back because edits are needed. I'm having some trouble with the formula though. Would you mind sharing how you set up your field?

Robyn Smith

Kelsey Rudolph Are you only doing this at a project level, not a task level? How did you set up your Original Finish Date to match the Due Date? I want to have Original Due Date on tasks and use the Completion Date to determine when tasks are being adjusted from initially planning. Yes, changes happen but want to investigate any root causes if this is a recurring issue. Thanks!

Pietro Poli

Hi @Tiffany Sands,
we use external API to count each time task is mooved.

Kelsey Rudolph

@Robyn Smith correct, the dates are only being tracked at the project level. It is when the project ran overdue that I need to manually figure out what happened within that project to cause a project delay and update the "date change reason" field to reflect my results.

Project level is the only way I've found to have a reliable "Original" date stamping (using the request form by asking a due date question and having it populate both the due date and original finish date fields at the same time).

Teddy Otero

@Kelsey Rudolph - Thank you so much for that great tip! We had a much more complex automation in place to track lateness that we just replaced with a variation on yours. Quite simply, when a task is mark completed, we tag a custom field called "Completion Date" with the current date, and then a formula field called "On-Time" calculates how many days early or late it was completed.

Is there a way to prevent our users from manually altering the Completion Date field? I trust the team, but why not remove the temptation altogether?

Maria Phillips

What is a formula field? That sounds like an amazing idea, I want to implement it in our own tasks!

Could the Completion Date field not be filled out by an automation task? 'When a task is marked as completed, put in current date to the Completion Date field'? Then users wouldn't have to input it themselves.

Kelsey Rudolph

@Teddy Otero I'm so glad it works for you! The way I manage folks not being able to edit is by editing custom fields within settings. Simply locate the custom field you wish to edit and when the right menu appears, I believe it defaults to "Everyone can see and edit," click on that and you can edit individual users or user groups to have visibility.
In my example below, you can see our ops team has permissions to see (since this is a formula field, there wouldn't be anything to edit), but everyone else has no access.

Pietro Poli

Hi @Teddy Otero, you can give different permissions to custom fields

@Maria Phillips, formula custom fields are very useful to make simple calculations with data taken from other custom fields
https://help.wrike.com/hc/en-us/articles/360036858954-Adding-Formulas-to-Custom-Fields

For Completion Date, is a standard Wrike field and is populated when a task goes in Completed Status Group.

Teddy Otero

@Maria Phillips Here's the automation that fills out the completion date, just as you say:

Here's the formula field that tells us whether the task was completed early or late:

Literally just implemented on Friday, so we'll see how it works out.

Thanks for the pointers @Kelsey Rudolph and @Pietro Poli!