Cancel dependency with registered progress

I would like to suggest an improvement by implementing a logic that I believe is essential for the program.

Frequently, a subsequent activity that has a link starts and has its completion recorded in it (even if partial).

What happens is that, if the initial activity is postponed, it moves the subsequent activity, which creates an unrealistic situation in the project, since it has already had progress recorded.

In MS Project, when progress is recorded in subsequent tasks, it ignores the link so that it does not move any further, resolving the reported behavior.

Therefore, my suggestion is to put a condition in the program code that if progress is reported in the task, ignore the link, which will improve usability for all users!

I understand the point; however, I can see some concerns, too.

What happens is that, if the initial activity is postponed, it moves the subsequent activity, which creates an unrealistic situation in the project, since it has already had progress recorded.

In my opinion, the case when a successor is started although the predecessor is not yet finished is “unrealistic” as well. I added quotes because I understand that in reality, we may start working on the successor before a predecessor is done, there may be different reasons for that, however, from the project logic, I see no big difference between these two: we move a task that is already in progress vs we started a task although the predecessor is not yet done.

There may be other solutions, for instance:

  • remove the dependency
  • split the successor task in two parts
  • add a lag
  • just let it move since we don’t really care if it started on this day or on some other.

Probably it makes sense to draw user’s attention to this and suggest the options.

Would love to hear the opinions from @malcaraz, @csimeon and @twa

1 Like

I only use dependancy between two tasks, if the successor task can only be started, if the predecessor is truely completed (it is blocked by the predecessor).

In this special case described in this thread, I would simply remove the dependancy, as Dmitri already stated, since it doesn‘t exist.

There are many tasks, which start after other tasks in my charts. They start after, but can start independantly. For me the dependance is a very special case.

But that’s my perspective. I do understand, that others may have other points on this topic, which is totally okay for me.

Good afternoon

I’m glad to see the debate on this topic.

Regarding the question:

“There may be other solutions, for example, we can decide to remove the dependency or split the successor task into two parts, or just let it move, since we don’t care if it started on this day or some other day.”

The big problem is that if the system doesn’t freeze the task, in complex schedules it is only discovered after it has moved, making it difficult to remove the dependency and discover when it actually started.

The dependency in these cases should be start to start with some delay, in practice since projects tend to be delayed there comes a time when the activity is started without the other one being completed.

My projects are very complex with many dependencies and thousands of tasks, which causes significant disorganization when they move.