Project status and date relationship

[Anton von Borries]

We have recently adopted Atlas specifically for project updates and have a question about the best practice for status changes and dates. 

Our interpretation of the "Off Track" status is that the original target date is no longer achievable and has to move back. 

So ideally in the project update, we'd like to set the status to Off Track for the original target date and provide a new date the team is targeting. However, the phrasing in the update shows up as "Off Track for [new date]". Making it seem like we're Off Track for the new date. 

The only option I can see is leaving the original target date in and adding the new date in the comments, but it's not great as that doesn't surface on the top-level list. An alternative approach would be to: 

1. Set the status to Off Track, leave the original target date in and mention the new target date in the comments

2. In next week's update, set the new target date and whether we're on track for that

The only problem with this approach is that in the top-level project list this project now shows as all green, same as projects that haven't had a date change. So we've lost visibility on the fact that this project is no longer tracking to its original timeline until you click into the individual project.

I am wondering what the intention of the status & date relationship is for Off Track updates? What is the "intended" workflow for communicating that we are off track for the original date and then start tracking towards a new target date?

Thanks

[Walter Buggenhout]

Hi @Anton von Borries,

Allow me to try and change the perspective from the tool to the actual project (being represented as an entry in Atlas).

When the time comes for the weekly update, there's going to be a moment where you notice for the first time that you may not be in shape to meet the project deadline. Or maybe run over budget. Or start experiencing quality issues. At that time, you use Atlas to signal there is an issue, by marking the project as off track / at risk. In the update, describe why you changed the status and what actions you need to take.

Most importantly: take these actions. Look at your scope, resources, timeline. Do whatever you need to do to mitigate the issue.

Whenever the project gets back on track, switch the status back to green, update the timeline (if that's what you decided to do) and document why you can see you're back on track.

Keep in mind that the goal of the tool is signal the need to talk: with stakeholders, with the project team, with partners, ... 

Hope this helps!

[Sing Chen]

Hi @Anton von Borries, 

We had similar conversations in group when we adopted Atlas and went through a similar set of "what does good practice look like" discussions.

I agree with Walter's comments and would add:

• For our projects, while it's good to know the original (or historic target dates - since a project's target could change multiple times, and even come in sooner) what our Atlas 'consumers' are interested in are what the target date IS not what it WAS. Part of our on-going education and reminders to the business (since they aren't project management professionals nor do we expect them to be) is how we set expectations about what status and dates mean. 
• It's very rare for our projects to go off-track and have a new date in the same "reporting" week, so Walter's approach works for us. Original date is set as off-track, project team works on risk mitigation/issue resolution and time is needed to identify a new date (the work to do that is referenced in the update itself) and when a new date is agreed, we use the following reporting week to convey that information and set status to green (against that new date).
• A project's timeline at the top of it's Atlas page will show the ebb and flow of date changes which users can jump into the detail of. Our users are accustomed to that now, they understand that you can't have the high-level and the detail in a single view and if a high-level view raises an eyebrow, they know to dig into the detail and then follow up with the project owner.
• We use other 'vehicles' as part of our project execution. Atlas is there as official reporting system of record but "interested parties" will be involved in different ways and will have an understanding of where the project is without using Atlas as their go-to. Example: the immediate project team shouldn't have to look at Atlas to know if a project is R, Y, or G or to know there is risk to the date or that it has changed. In a similar way, other stakeholders who may not be as directly involved but are consulted or kept informed will generally be involved in discussions around assessing risks, resolving issues, escalations, etc and will typically be aware that an initial date may be off-track.
• Depending on the level of plan you are on, have you considered using Custom Fields? Perhaps defining an "original target date" field or "previous target date" field.

This is not to say Atlas is the perfect solution, there are opportunities for improvement but it aligns much more effectively to how we want to work. No more powerpoint attachments in emails and fewer status meetings.

I hope this helps.

Sing