Off track and target date

[Zachary Belzer]

Our team has run past our target dates a few times and wanted to simply mark the project as "off track" and leave the date for which it was originally targeted. However, there is a validation enforcing the target date in the future.

While I understand this restriction for most statuses, the team has had a consensus that we'd like to be able to make an update stating why it is/was off track for a specific date and leave updating the target date to a subsequent meeting.

Is there any plan to change or make this behavior configurable? It just seems weird to call something off track for a date you just moved into the future.

[Vernon Laquindanum]

Hey @Zachary Belzer I don't believe we have any plans for this currently but that's a really good point about saying it's off track for a date we'd just moved. We'd intended the updates to be a bit more "moment in time" in the sense that you missed the target date, so the following update would explain why it was missed (making it "off track") as an acknowledgment, while then looking forward to the new target date.

I do think more reconfigurability is good though, just so everyone can use these features the way they'd like. I've added your idea to our backlog so we can discuss it further.

Thanks for writing in!

[Zachary Belzer]

To put it a little more simply:

With the current functionality, I can never just provide an update about why it's off track... I have to update the date into the future and it's likely "on track" for that future date.

[Jack Ukleja]

@Zachary Belzer you make a fair point, but I would think about this from the stakeholders perspective. They want to keep track of the project, know when to expect it, and whether it's likely to slip.

The target date is the date they should expect the project delivered. If you start to think you will miss the date, you change at-risk/off-track as you approach that date. But once you are off-track there is a good chance you will need to revise the expected delivery date.

This is the point at which things get confusing. Stakeholders want to know when they can expect the project, even if the project has slipped. But if you delay the project is it now back on track or not? 🙃

I think the problem here is really the incoherence of the RAG concept, or at least its limits, as a communication tool.