I'm not at all experienced on the subject, but, so far, the mindset I liked most is the one presented on "Software Estimation: Demystifying the Black Art": one must be aware about the difference between an estimate and a plan.
Estimates are statistical by nature; they are made of "educated guesses" and historical and empirical data available. Estimates must be unbiased. They are unnegotiatable and they are not commitments.
Plans are not statistical. They are oriented by estimates, but they must present concrete dates and, when they are not met, the plan must be revised and renegotiated. Plans are commitments.
I think this separation brings useful implications and tools to argue sensitively with stakeholders. I've always hated having to commit to hard dead lines based on estimates. While I was aware of the importance of providing concrete deadlines, it felt like I was taking the entire risk of the estimate for myself, which is unfair, to say the least.
By making the separation between estimates and plans, I'm more equipped to discuss the matter. I can show the estimate and, when pressed to commit with a tighter deadline, I have some leverage to trade the desired deadline for a decrease on the project requirements set, for instance.
Depending on the complexity of the plans and the dependencies between activities, you absolutely can go over a planned date, so long as it's the early start.
In critical path method scheduling, you will typically show an "early start" and "late finish" dates for an activity and maintain float to the early or late start of the next (driven by other activities in the DAG and availability of resources assigned to them). I (and others) like to explicitly state contingency factors and/or risks as successor activities that consume this float. They can also be used for Monte Carlo analysis where those activities are randomly increased in duration (usually on some statistical curve as discussed in the article)
What we are really doing is simulating many many permutations of the effects of known risk likelihoods and consequences across the graph. Otherwise in a large program of works we will tell Project Managers or Contractors that they can manage their own float which gives them flexibility to execute.
Another method that simplifies this is PERT[1] method, where you take, optimistic, pessimistic and normal durations to produce an expected duration.
Estimates are statistical by nature; they are made of "educated guesses" and historical and empirical data available. Estimates must be unbiased. They are unnegotiatable and they are not commitments.
Plans are not statistical. They are oriented by estimates, but they must present concrete dates and, when they are not met, the plan must be revised and renegotiated. Plans are commitments.
I think this separation brings useful implications and tools to argue sensitively with stakeholders. I've always hated having to commit to hard dead lines based on estimates. While I was aware of the importance of providing concrete deadlines, it felt like I was taking the entire risk of the estimate for myself, which is unfair, to say the least.
By making the separation between estimates and plans, I'm more equipped to discuss the matter. I can show the estimate and, when pressed to commit with a tighter deadline, I have some leverage to trade the desired deadline for a decrease on the project requirements set, for instance.