Improve critical path

[Ka_Nishiyama]

Critical path on timeline (asana.com)
(Understanding Dependencies in Project Management [2024] • Asana)
Calculation method in the function to highlight critical path in timeline is different from the critical path calculation method in the general project management field.
In the documentation, the Critical Path (Timeline) is described as follows:" Calculating your project’s critical path Your project’s critical path is the longest chain of dependent tasks that need to be completed for your project to be finished. However, subtasks are not included when calculating your critical path. Calculating how long it will take you to complete your project is done through task duration and dependencies between these tasks, including any time gaps."

Append: The result of executing the critical path is different between “Asana” and another company’s “PMsoftware”. I attach an image.

In addition,
Please refer to this document

• Critical path method - Wikipedia
• ISO 21500:2021 - Project, programme and portfolio management — Context and concepts

In ISO21500, it states that “2.8 critical path sequence of activities that determine the earliest possible completion date for the project or phase”

[Ka_Nishiyama]

The Gantt view has been added and there is an option to highlight the critical path, but I still find the display of the critical path unsettling.

In the figure below,
The critical path is highlighted as “1(1)-2(2)-4(3)-2(4)-1(5)”.
However, according to my understanding, “1(1)-2(2)-5(31)-2(4)-1(5)” is the critical path.

[Jan-Rienk]

@Ka_Nishiyama I agree with you.

I’m not a fan of Gantt charts in general, but I’d thought I’d play around with it.

The way the Gantt view displays the critical path is incorrect. It should be the path that can’t afford any delays compared to planning.

I have the same experience, where it picks the wrong path.

@Marie @Emily_Roman Can you flag this for the involved team?

[Emily_Roman]

Thanks for sharing your feedback, @Ka_Nishiyama and @Jan-Rienk!

I’ll create a task to our product team to investigate further and consider updates to critical path in future updates. I’ll let you know when I have any news

[Ka_Nishiyama]

I found out why the critical path calculation was strange.
It’s because there is no total number of days set for the tasks. Tasks have start and due date fields, but the start and due dates are both date fields, and there is nothing between them.

I noticed this when I was looking at this post.

Waterfall Due Date Changes from List View

I was talking with one of my Project Managers the other day who pointed out that updating a series of task/subtask due dates can be a real bother. From the timeline view we have Maintain Buffer and Weekend Awareness checked and in theory this should do what we want. However it’s been noted that: When shifting a task/subtask in the middle of the timeline, it shifts the ENTIRE timeline instead of just the tasks after the one being adjusted. While the tasks/subtasks will avoid the weekends, ofte…

Custom Date Field Needs Start / End Date Range Support

Really excited to finally have the ability to create custom fields with Date information. That said, would love to be able to set a start date similar to the standard date field. And have that information be available in the timeline/ calendar views. I see us using this for the various “Stages” of a project that might last several days and our sub-tasks are tied up already that I cant use them for this.

[Jan-Rienk]

I think duration would be a welcome addition anyway.

We’re not thinking in dates, we’re either thinking:

• “when is this due and how long does this take” to calculate when to start
  or the other way round:
• “when can we start and how long does this take” to calculate when it could be due

Related topics:

• Auto calculate due date with duration & dependencies
• The ability to use RULES to set a DUE DATE based on a numerical duration (CUSTOM FIELD) that adds to a changed START DATE

[Ka_Nishiyama]

Hi, @Jan-Rienk
Thank you for the information. This is the answer to the question about the period. It means that it can be set in the Gantt view. I’m wondering how it will be consistent with the timeline. I’ll check it out later.

Auto calculate due date with duration & dependencies

Since this thread was started, Asana released Gantt view available in any project. You can do that now in Gantt view. There are also new options for date shifting with dependency management options in Gantt, Timeline, and List views: Thanks, Larry

[Jan-Rienk]

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.

[Phil_Seeman]

Really excellent post and discussion, @Jan-Rienk!

I agree with you that Asana’s definition of critical path is not correct. But also I’m confused. If you take your very first example:

Why does Asana choose A-C-D as the critical path???

If their definition (quoting their documentation as well as your post) is

Clearly A-B-D has a longer total duration than A-C-D. So why do they choose A-C-D as the critical path?

[Jan-Rienk]

Hi @Phil_Seeman ,

Thanks for the compliment, glad to hear.

The article at the end is not the documentation of this feature. The documentation is linked in the beginning of my post.

When there are paths of equal length ( last_due_date - first_start_date ) Asana is said to pick randomly (if the amount of dependencies is the same)

It looks however that Asana prefers the path with a shorter duration, but I’m not sure if that is a coincidence or not.

[Phil_Seeman]

@Jan-Rienk

When there are paths of equal length ( last_due_date - first_start_date ) Asana is said to pick randomly

I wish that statement were a joke but I fear you’re serious.

Anyway, while I disagree with an implementation that selects a path randomly in that scenario, it’s really a moot point because, as you well illustrate above, the underlying logic is not correct to begin with.

To me, the key factor they are not taking into account is the concept of float. They even mention it in their blog article but oddly then don’t use it in their actual logic. You can’t calculate a critical path without taking it into account.

[Jan-Rienk]

Funny to realise I kind of explained the concept of float before I knew what it was called.

[Phil_Seeman]

Yeah @Jan-Rienk you pretty much nailed it.

[Ka_Nishiyama]

Regarding the critical path,
I tried it again in Gantt view.
I wonder why it’s displayed like this.
I strongly hope that it will be improved soon.

[Angelo_Brisimitzakis]

I’m having the same issues with how Asana is calculating the critical path in Gantt view. As others have pointed out, it is not highlighting the path with longest duration. When will this be fixed?

[Bastien_Siebman]

While I love J-R post and the discussion, this is all very complex, and can’t be explained simply by a consultant during a session. Can someone explain in one sentence, even over-simplified, why the critical path is “surprising”? thanks

[Phil_Seeman]

I’ll take a shot at it, @Bastien_Siebman:

The critical path is the path of dependent tasks that has the least amount of flexibility - that is, the least amount of leeway for slippage - in order for the project to be completed on schedule.

Asana is not following this rule. The clearest above example is:

Asana has incorrectly identified A-C-D as the critical path; it should be A-B-D. Why? Because any delay in task B would delay the project. Whereas task C could be delayed for up to two days and not endanger the project completion date.

Clear as mud?

[Ka_Nishiyama]

I would say “Asana should not describe this feature as critical path.”
If Asana would like to use an original expression that differs from critical path, please feel free to do so.

Critical path method

Program evaluation and review technique

Testing the Wikipedia example with Asana

[Jan-Rienk]

@Bastien_Siebman

While I love J-R post and the discussion, this is all very complex, and can’t be explained simply by a consultant during a session. Can someone explain in one sentence, even over-simplified, why the critical path is “surprising”? thanks

@Bastien_Siebman I think we should avoid over-simplification. @Phil_Seeman, your example doesn’t hold true when task C is (poorly) planned two days later. This would mean a delay in task C would delay the project and both A-B-D and A-C-D would be critical path in that definition.

@Ka_Nishiyama

I would say “Asana should not describe this feature as critical path.”
If Asana would like to use an original expression that differs from critical path, please feel free to do so.

Yes, current functionality is not critical path. And I agree that the most accurate thing would be to refer to the definition. Yet I think @Bastien_Siebman is not talking about what he feels Asana should do, but rather how he as a consultant could explain why people at this time should ignore the feature that is currently being called critical path, and why it isn’t actually critical path. Here is my attempt to explain it in simple terms without over-simplification:
“The minimal project duration is determined by the critical path, which is the sequence of tasks that has the largest sum of task durations.”

An alternative method to find the actual critical path and end up with planning where non critical path tasks can afford delays is to show it:

1. Go to timeline view
2. Select all the tasks and drag them to before the project start date
3. Set dependency management to consume buffer
4. Take the first task and drag it to the project start date
5. If any tasks are left behind, drag those to the project start date

Results:

• The sequence of tasks that is performed back-to-back from start to finish is the critical path.
• There is no faster way to complete the project, assuming the task duration is estimated accurately
• Any task that has space between it and the next dependent task is not along the critical path and can afford delays without extending the project duration until they are planned back to back with the next dependent task.
• Any improvements made that can shorten the sum duration of the tasks along the critical path can allow for a shorter project duration.

You could apply the same tactic when working towards a project deadline as opposed to a start date, but that would require nudging the first task forward until the last task ends up finishing on the project deadline for step 4. (It’s the same principle as tuning a guitar. Once you overshoot you should start over and approach again from below)

One caveat I feel I should make is that this assumes accurate estimation, and enough capacity to do the work as planned (or re-planned when it concerns non-critical path tasks).

Could be a cool feature to have Asana re-plan the project in this way against a start or a due date.

I don’t feel I have enough experience in this area to claim with confidence that this is all correct and without over-simplification. But I’m curious if @Ka_Nishiyama or @Phil_Seeman are able to poke any holes in this or use easier to understand language without meaning being lost.

[Phil_Seeman]

This latest discussion is all well and good but I think @Bastien_Siebman had a very valid request of a way to distill the concept of critical path to one or two sentences - an “elevator pitch”, so to speak. One doesn’t always have 10 minutes to explain the concept to a client or prospect, and I don’t think we should deflect his request.

Also @Jan-Rienk I don’t agree that my statement doesn’t hold in your alternate example. If task C were scheduled 2 days later than shown in that diagram (which might not be poor planning; there might be a valid reason why that 2-day lag is required), then yes, both paths would be considered as a critical path and both would still match my definition of a path of dependent tasks that has the least amount of flexibility - that is, the least amount of leeway for slippage - in order for the project to be completed on schedule.