I have since talked with support about this. I’ll add what I discussed here.
TLDR:
- Critical path is working as documented, so it is not clasified as a bug.
- I still think current functionality is problematic, and my feedback has been passed on to the product team
The issue with using the longest chain
The documentation describes the critical path as “the longest chain of dependent tasks that need to be completed for your project to be finished”. If you interpret that as the longest chain of dependent tasks between start of the first and end of the last task then technically the critical path isn’t wrong according to the documentation.
That’s not the whole story though, as the purpose of critical path in project management is to be aware of the path that can’t afford any delays.
Now Ideally, we’d calculate the critical path on the estimated time per task rather than the deadlines, but I’m fine with assuming the start and due dates are representing the amount of time needed to complete the task accurately.
If you look at my example you can see that a delay in task B would delay the entire project. Task C could be delayed for two days and not endanger timely project completion.
Still, Asana highlights the path through task C as the critical path, which is plainly wrong and misleading.
Using the critical path in this instance (prioritizing task C over B) would work to delay the project rather than ensure it is completed on time.
Now I know that Asana refuses to call something a bug when it functions according to the documentation, but it’s a problem nonetheless. And a bit of an embarrassing one if I’m honest.
=============
When managing a project, the critical path could be a great help in quickly determining what has priority.
Let’s say we’re at Friday 19th, and someone has fallen ill.
If task B isn’t started on Monday, it risks delaying the entire project.
When I can see the critical path (task B) at a glance, I can make sure it is staffed before the weekend.
I can worry about staffing the non-critical path (Taks C) on Monday.
Another argument is that it’s just wrong. Theory indicates how to determine the critical path with good reason, and launching a feature that you call critical path but assign your own (less useful) meaning to seems ill informed and misleading.
I don’t want to sound too harsh (I like Asana, I really do) but I’m choosing to be honest over being polite as I think this is more useful feedback.
The problem with using the longest chain from first start date to last end date
You can see here that you should be able to finish earlier when you shift deadlines in task B. It is however not a problem not to start B immediately after A, as this will not result a longer project time.
The critical path is not to indicate how long the project takes according to current planning, it is to indicate the path that determines the shortest possible project duration. This means any tasks that start before or end after the critical path are planned incorrectly.
Perhaps another visual indicator could be used to indicate an opportunity in finishing the project faster by re-planning task B?
Another indication of unnecessary long project times are tasks along the critical path that don’t start as soon as the previous task finishes, which could perhaps also be visualised.
In this example, red indicates the time wasted because of poorly planning the critical path in orange (assuming only working days)
This is the time that becomes available when the project is planned along the critical path:
- Start with first critical path activity
- Have immediate hand-offs between critical path activities
- End with critical path activity
The problem with using the greater number of dependencies
The amount of dependencies is not relevant when calculating critical path, just that the dependency is there. What is relevant is duration. Looking at the example below the critical path chosen is indeed the one with the most dependencies, and I think this is incorrect and unhelpful. You will notice that we can a delay both task B and task D without any problems, but a delay in task C will delay the entire project.
Again ignoring the fact that estimated time is a better indicator, but for now let’s assume the time between start and due date is a decent indicator for the estimated processing time.
The sequence with the longest duration determines critical path.
This article by Asana about the critical path method correctly explains it. It’s about duration. And the duration determines the path where the handoffs should be instant to finish the project the fastest.
