Improve critical path

[Jan-Rienk]

@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.

I don’t think these answers are deflecting the request. They are alternative ways to answer the question. The simplest is pointing to Asana’s definition of the feature, and the common definition of the feature and point out they are completely different.

@Phil_Seeman

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.

The problem is that your definition - like Asana’s definition of the feature - is conflicting with the real definition of critical path. And I don’t think that’s helpful.

PS:

On a side note… I’ve been active training sailing instructors for many years, and I’ve always found that the oversimplifications that many of my trainees have been taught have been misguiding their understanding of sailing, and hampering of their understanding, application, and teaching of the concepts to others.

I’m confident the same principle holds true here. Simplification is great, but over-simplification gives people a misguided sense that they grasping the mechanics. Many times I have seen these oversimplifications being taught from one generation of instructors to the next, and it’s an uphill battle to set the record straight.

[Phil_Seeman]

@Jan-Rienk

The problem is that your definition - like Asana’s definition of the feature - is conflicting with the real definition of critical path.

Uh oh. Where does the statement I wrote fall flat in describing what a critical path should be? (Granted it doesn’t tell you how to compute it, but that’s not what @Bastien_Siebman asked for.)

[Jan-Rienk]

I think the example we talked about earlier. When task C is planned 2 days later:

Critical path not only defines the path that can’t afford delays, but also which tasks require improving to shorten total project duration.

Although task C can’t afford delays in this scenario, it’s duration does not determine the minimal project duration.

Curiously, Asana seems to now correctly identify the true critical path, also when I move task C to start with B again.

Anyway, you could call it nitpicking, and you might be right. But this is how I look at it.

[Phil_Seeman]

I still stand by my statement as accurate - the critical path is only concerned with the one path that has the least leeway for slippage (technically, the smallest total float). It’s not concerned with other tasks in the project that aren’t in that path; so in the A-B-C-D example we’re discussing, Task C is irrelevant to the critical path.

See for example The ABCs of the Critical Path Method from Harvard Business Review:

In essence, the critical path is the bottleneck route. Only by finding ways to shorten jobs along the critical path can the over-all project time be reduced; the time required to perform noncritical jobs is irrelevant from the viewpoint of total project time. The frequent (and costly) practice of “crashing” all jobs in a project in order to reduce total project time is thus unnecessary.

[Jan-Rienk]

@Phil_Seeman I’m a bit confused. These statements seem conflicting. I agree with the latter.

@Phil_Seeman

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

@Phil_Seeman

It’s not concerned with other tasks in the project that aren’t in that path; so in the A-B-C-D example we’re discussing, Task C is irrelevant to the critical path.

[Ka_Nishiyama]

There should be more than one critical path.

---

Asana: Only one path is marked as critical

---

Other PMS: All paths are marked as critical

[Phil_Seeman]

[post removed - I just realized I had responded incorrectly to JR, so to try and avoid even more confusion than is already present in this thread, I’ve removed what I initially said here]

[Bastien_Siebman]

[post removed]

[Phil_Seeman]

@Jan-Rienk

I’m a bit confused. These statements seem conflicting.

No, they’re not. In the diagram I referenced in my “definition” post above - I’ll put it here again for clarity -

my second statement of

@Phil_Seeman

It’s not concerned with other tasks in the project that aren’t in that path; so in the A-B-C-D example we’re discussing, Task C is irrelevant to the critical path.

applies. Here A-B-D has a float of 0 days; A-C-D has a float of 2 days; hence A-C-D is not a critical path.

My first statement of

@Phil_Seeman

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

applies in the case where Task C is scheduled two days later, as in:

In this case, both A-B-D and A-C-D have 0 float; that is, neither path has any room for delay without impacting the project completion date and thus both are critical paths. (This is actually what @Ka_Nishiyama has illustrated in his post just above this one.)

[Jan-Rienk]

This contradicts the definition. The sum duration of that path is not equal to the max sum duration, so it cannot be critical path.

@Phil_Seeman

See for example The ABCs of the Critical Path Method from Harvard Business Review:

In essence, the critical path is the bottleneck route. Only by finding ways to shorten jobs along the critical path can the over-all project time be reduced; the time required to perform noncritical jobs is irrelevant from the viewpoint of total project time. The frequent (and costly) practice of “crashing” all jobs in a project in order to re

This doesn’t hold true in your definition.

A shorter project time can be accomplished without improving path A-C-D, but instead improving B, which is in the critical path A-B-D.

This is exactly why I’m against over-simplifying such a definition. If Asana were to adopt your definition it would still deviate from the textbook definition, and it could lead to falsly concluding a path needs improvement in order to over-all project time.

If you are not convinced I suggest we organise a call.

[Phil_Seeman]

@Jan-Rienk

This doesn’t hold true in your definition.

A shorter project time can be accomplished without improving path A-C-D, but instead improving B, which is in the critical path A-B-D.

Clarification required… Which diagram are you referring to, the top one in my most recent post or the bottom one?

[Jan-Rienk]

I was referring to the last image you posted, but it holds true for either variant. (C having time before or after)

[Bastien_Siebman]

Not sure if this helps the discussion or not, but below the toggle to enable the critical path, it says “Critical path identifies which dependent tasks are crucial for project completion”. I am curious to see if you believe this is correct, misleading, or wrong ^^

[Phil_Seeman]

@Jan-Rienk

I was referring to the last image you posted, but it holds true for either variant.

Gotcha. I still think my definition is accurate but let’s circle back on this a bit later when I have the bandwidth to continue this exploration!

[Phil_Seeman]

@Bastien_Siebman

below the toggle to enable the critical path, it says “Critical path identifies which dependent tasks are crucial for project completion”. I am curious to see if you believe this is correct, misleading, or wrong ^^

I think it’s not wrong as far as it goes, but it’s so vague, it doesn’t really help you that much.

At a very minimum, I wish it would say “Critical path identifies which dependent tasks can least afford a delay in order to achieve the current completion date.”

[Ka_Nishiyama]

I’ll say it again and again:
The description of this toggle is correct.
(It’s just that Asana doesn’t work that way.)

[Jan-Rienk]

@Bastien_Siebman

Not sure if this helps the discussion or not, but below the toggle to enable the critical path, it says “Critical path identifies which dependent tasks are crucial for project completion”. I am curious to see if you believe this is correct, misleading, or wrong ^^

I think it’s wrong. Tasks outside the critical path might be just as crucial to complete the project, it’s just that they don’t define the minimum project duration.

A correct description for how Asana functions at the moment is described in the Help center.

@Asana Help Center

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.

The confusion is caused because “the longest chain of dependent tasks” is interpreted by the most time between the start of the first task and the end of the last task. And it is unpredictable which path it chooses when there are multiple options. Asana should instead consider the chain that has the longest sum duration, and not count any float, which is the space in between tasks that are not planned back-to-back.

If I were to make a new attempt at giving a helpful description should Asana function according to the real definition it would be this:

The critical path defines the minimum time it takes to complete a project. Shortening the minimum project duration requires reducing duration of critical path tasks. ()

Perhaps with some extra clickable information:

Find the minimum project duration by planning critical path tasks back to back.

Or even better there would be functionality to automatically (re)plan the project to the shortest duration.