Shouldn't predecessors and dependencies work differently?

BSADK

This is not just with Smartsheet, but any project planning software I've seen so far. Dependencies have four types, and this is how they work:

Finish-to-Start (FS): The "normal" type of dependency. This sets the start date equal to the day after the finish date of the predecessor. You can adjust the duration or finish date, but not the start. It removes predecessor if you edit start. If you edit the finish, it automatically adjusts duration. If you edit duration, it automatically adjusts the finish. [Definition: "start after the predecessor finishes"]

Finish-to-Finish (FF): This allows parallel work, but you finish on the same date. This sets the finish date equal to the finish date of the predecessor. You can adjust the duration, but not the start or finish date. It removes predecessor if you edit start, does not allow editing of finish at all. If you edit duration, it adjusts the start date. [Definition: "finish at the same time the predecessor finishes"]

Start-to-Finish (SF): This is like a reverse dependency. This sets the finish date equal to the day before the start date of the predecessor. You can adjust the duration but not the start or finish date. It removes the predecessor if you edit start, does not allow editing of finish at all. If you edit duration, it adjusts the start date. [Definition: "finish before the predecessor starts"]

Start-to-Start (SS): This allows parallel work, but you start on the same date. This sets the start date equal to the start date of the predecessor. You can adjust the duration or the finish date, but not the start. It removes predecessor if you edit start. If you edit the finish, it automatically adjusts duration. If you edit duration, it automatically adjusts the finish. [Definition: "start at the same time the predecessor starts"]

Descriptions above are my wording of what happens, but definitions and Smartsheet documentation/wording are from here: https://help.smartsheet.com/articles/765727-enabling-dependencies-using-predecessors

I can see how, for a programmer, this makes the program easy to set up. You set one thing rigidly equal to something else, and let whatever adjust adjust. Any change to start date removes the predecessor. Convenient for them.

But for the user/planner, it's not so convenient - and it doesn't reflect the reality of project work. For SF in particular, the defined "predecessor" doesn't fit the meaning of the word "predecessor" in English - in fact, it's exactly the opposite. Word semantics aside, does anyone really find SF dependencies useful? Why wouldn't you just use an FS dependency on the other row instead?

Using lag/lead time helps - but it's limited. When you put in a lag/lead time it's fixed. So it shifts with the predecessor exactly. Shift the predecessor by 3 days, it shifts by 3 days, etc. But if I have an FS predecessor and I have a 3 day lag - chances are if the predecessor slips by 1 or 2 days, I will actually KEEP the same start date, not move it. When I update my sheet, now I have to go edit all my associated lag times, too. This is time consuming.

Now, I realize that FS/FF/SF/SS dependencies as implemented are basically a standard now, so if one day Smartsheet just changed them to mean something else just because of some random user's (e.g. my) request, it could confuse a lot of users, not to mention upset current users whose sheets would suddenly change behavior one day and completely break their sheets. My proposal would be a more flexible version, so for clarity I would precede them with an additional "F" for flexible. Implementing these as new available predecessor functions (perhaps by choosing a "rigid" vs "flexible" mode), rather than replacing existing, would then maintain backwards compatibility.

Here's how I propose they should work:

Flexible Finish-to-Start (FFS): This would set the earliest possible date for the start date equal to the day after the finish date of the predecessor. By default, it would set it to the day after the finish date of the predecessor, but you could then adjust the start date to a later date, if desired, but not an earlier date. If you adjust start or duration, the finish would be automatically calculated. If you adjust finish, the duration would be automatically calculated. If you try to adjust the start date to earlier than the finish date of the predecessor, it rejects the change. [Definition: "start after the predecessor finishes"]

Flexible Finish-to-Finish (FFF): This would set the earliest possible date for the finish date equal to the finish date of the predecessor. By default, it would set it to the finish date of the predecessor, but you could then adjust the finish date to a later date, if desired, but not to an earlier date. If you adjust the start, the duration would be automatically calculated. If you adjust the finish, the duration would be automatically calculated. If you adjust the duration, the start would be automatically calculated. [Definition: "finish at the same time as or later than the predecessor finishes"]

Flexible Start-to-Finish (FSF): This would set the earliest possible date for the finish date equal to the day after the start date of the predecessor. By default, it would set it to the day after the start date of the predecessor, but you could then adjust the finish date to a later date, if desired, but not to an earlier date. If you adjust the start, the duration would be automatically calculated. If you adjust the finish, the duration would be automatically calculated. If you adjust the duration, the start would be automatically calculated. If you try to adjust the finish date to earlier than the start date of the predecessor, it rejects the change. [Definition: "finish after the predecessor starts"]

Flexible Start-to-Start (FSS): This would set the earliest possible date for the start date equal to the start date of the predecessor. By default, it would set it equal to the start date of the predecessor, but you could then adjust the start date to a later date, if desired, but not to an earlier date. If you adjust the start or duration, the finish date would be automatically calculated. If you adjust the finish, the duration would be automatically calculated. If you try to adjust the start date to earlier than the start date of the predecessor, it rejects the change. [Definition: "start at the same time as or later than the predecessor starts"]

Note that with what I propose:

1. FFS, FFF, and FSS predecessors would be VERY similar to the existing FS, FF, and SS predecessors - just with certain dates CONSTRAINED by the predecessor instead of being COMPLETELY FIXED. This allows much more flexibility. In fact, FFS actually fits the existing definition better than the current behavior, as such I didn't change the wording of its definition.

2. FSF predecessors would be completely different from SF predecessors for the reasons I described above. This definition makes it a true predecessor and potentially more useful for planning.

3. A "lag" time entry would not be needed. "Lag time" would be implied by the actual start or finish date of the dependent entered by the user. This would actually make the entry simpler and less complicated as there would be no need for number modifiers.

4. At first it may appear that "lead" time is not possible by my definition. To me, if there's "lead" time, then it's not truly a predecessor. However, if it is a predecessor, you could change which type to create the same effect as a lead time. Instead of an FFS predecessor with lead time, you could use and FFF, FSF, or FSS with implied lag time instead. In particular, with FSF or FFF you can set the start date back as far as you need to without constraint. Or you could do FSS and only be constrained by the start of the predecessor, not the finish.

5. In all cases then, if a predecessor changes, it may or may not change the dependent line based on the following:

a. If the key date in the predecessor (Finish date for FFS and FFF, or Start date for FSF and FSS) is changed such that it now violates the rules above, the dependent row is automatically changed to the next closest date that meets the rule - then it follows the change rules above.

b. If the key date change doesn't violate the appropriate rule above, nothing changes in the dependent.

To me, not only do these make more logical sense and create true "predecessor" definitions, but also fits more real world scenarios. 

BSADK

Sorry, I'm very verbose so I couldn't fit everything in the original post. I wrote this similar to a software requirements specification to be specific and clear. I also wanted to add the following real world scenario but didn't have room:

Here is a common real world example I think this would be very helpful with (happens to me all the time, anyway):

You have a test that can't start until after a prototype is built. The first day available (due to test center resources available across all projects that aren't specifically tracked in your project) is 5 days after the originally scheduled end of the build. In the current system, you would set an FS predecessor with a 5 day lag. In my proposal, you would set an FS predecessor, then set the start date of the dependent out 5 days later directly in the sheet.

Now let's say something delays the build by 2 days. In the current system, when you update the build schedule testing will also move out by 2 days. But that doesn't reflect reality - you can still start the testing you scheduled on the originally planned day, it doesn't have to move. You now have to go and change all your lag times to 3 days instead of 5. Extra work that shouldn't be required. And if you forget to do it, that will create confusion because everyone looking at the schedule may not realize the test date hasn't actually moved. In the proposed system, the test date doesn't shift, it stays where it is because the date is still later than the predecessor.

If the build gets delayed 10 days, then the current system will automatically push scheduled testing out the full 10 days. The proposed system would only push testing out by 5 days. Assuming resources are available, this is preferable. If they are not available, well you have to verify available resources in either case and update manually... you don't really know if they're available in 10 days either without checking, so both cases require intervention. 

Overall, the flexible method would save more time planning by requiring less manual adjustments to the schedule.

Thoughts? I definitely would like to see other people support this idea, but I would also be particularly interested to hear examples where the existing functionality is better / more desired as I can't really think of any examples myself.