I find that keeping the scheduling process as simple as possible works best.

People who do not fully understand PM terms can be intimidated by such terms and this can lead to difficulties.

In my view point, a fully detailed schedule for the entire project is usually pointless because the level of uncertainty is too high to be of any real use.

Best practice is to divide the project into stages (or phases.) and produce a detailed schedule for the current stage, with an outline schedule for the rest of the project. This gives you the detail and accuracy to effectively manage the tasks at hand, and also the long-range forecast for delivering the entire project.

One of the tasks in each stage is to produce the detailed plan for the next stage. This is the real pragmatic approach because you are only putting the effort into a detailed plan when you need to, and when the level of certainty is as good as it can be.

Personally, I use placeholder tasks early on the in project - e.g. having a Transition stage which contains various testing, training and deployment summary tasks. Each summary task has a subordinate task called "placeholder" which has an estimated duration. This ensures that anyone reading the plan is clear that the detailed planning has not yet been done for that stage, while still providing some indication of the likely duration.

Most new methodologies follow this approach (Agile, Accelerated, FastTrack, etc..)
These approaches advocates "phases" called "Releases", a 3 month period in my world that enables me to set a meeting schedule, deliver a fairly accurate list of things that will be completed within the Release and discuss "Team Capacity" of the individuals involved taking into account vacations, other commitments, etc