In construction industry it is often not wanted to put negative lags between activities such as

(Predecessor Activity) FS - x days

I can understand that, as this means we are depending our link on something in the future and has not happened yet so it is not recommended.



Instead, it is suggested to use

(Predecessor Activity) SS + y days

But even here we are talking about something in the future. Because we do not know how well the predecessor will progress during that y days, or will it progress according to plan, will it progress y days worth of work as planned, that would allow the start of successor after y days worth of work.

We take care of this problem by eliminating the lags alltogether, and instead, put a milestone for start, then put something like %40 of predecessor, then link it with a simple FS to successor, and then at the same time continue the remaining of predecessor. This would be the theoretically correct way right? But it looks like this complicates the schedule a great deal. What is the best way to deal with this?

I'm not sure what your question is here.

You are correct that Finish to Start and lead requires you to be able to project when the predecessor task will finish.

Mathematically F to S with a lead is equal to a S to S with a lag.

my question is this: when you give SS + y days... you do not know how well the predecessor will proceed in those y days, which would enable the successor to start. how do you solve this problem?

also,

even if you just gave SS, you still dont know how well the predecessor will proceed after starting. for example, the sucessor may still depend on predecessor even after starting even though it just may have SS.

The project plan is a model of reality as best we can project. It requires monitoring and control after the plan is built and updating to reflect the current reality in the project. Project planning is not a once and done exercise. You will need to re-plan and and adjust throughout the lifespan of the project. Microsoft Project is just one of the tools in the project manager's kit.

If you are monitoring progress in the project and the successor cannot start as planned - revise the plan.

Actually, your original assertions are not correct in all cases. I often need to put lead times on activities, such as procurement, and this requires a ss- y days. The procurement period MUST happen before the desired event can occur, but its latest start date is determined by the projected start date of the activity. It is possible this will change, but I tend to put additional time in the lead period, which is generally a judgement call on how much variation is likely to occur.
As far as links depending on something in the future goes, this pretty much describes a programme. Planners predict the future, as best they can, and generally a good one will get it correct enough, but the unforeseen can and will occur.

/Using a baseline milestone (and I may have read this wrong)- you want to put a milestone in, and then use that as the basis for the activities that follow to negate a negative lag? This requires the milestone to be in advance of ALL activities, and the only way I can see to put this in with any accuracy is to put a negative lag on this activity, which defeats the purpose. A static milestone would give the problem that it does not move relative to other events, and you would need to move it manually, which defeats the purpose of a good programme.

As Julie says, a programme is live for the duration of a project, and you need to see what is happening (or trending) to be able to react positively with it. If tasks are slipping, you need to determine why - over optimism in planning, contractor not performing, unforeseen difficulties? A good planner will look for the cause of the problem and look for solutions- be it revising estimates of time and labour, replanning around obstacles, or simply kicking a contractor into picking up the pace.
How you plan your work is less pertinent than whether or not it works. I find that clients oftem insist on no negative lags, not because of any sound planning basis, but because they have an interrogative system that doesnt like it. "Good practice" is a phrase often used to justify a way of doing it for the sake of things, not because it has a soud basis.