How to manage a project schedule based on Late Start dates?

Question

We finished planning a project a month ago and since then have had four formal changes pushing out start dates to the latest possible. Scope change isn't a factor, rather the root cause appears to be a general lack of resources for all the projects the different functional units are assigned.

I would like to figure out a way to avoid having so many project changes when the scope of the project isn't changing, it just seems like a lot of unnecessary effort. A couple of alternatives that I can think of are:

1. Define schedules based off of Late Start dates rather than the MS Project default of early start date. The pro here is that it is simple to interpret (only one date is visible to stakeholders) and reflects the likely reality; the con is that there is a reduced tolerance for delay as more tasks will get on the critical path and there is a human tendency to not start work before you "have to".
2. Define schedules with a range of possible start dates (Early to Late Starts). The pro here is that it gives more leverage to push the team to start work before the latest possible date; the con is that I am pretty confident at least some in project oversight positions will have a hard time buying into date ranges and I'm not sure people will actually start work before the Late Start date. (As an aside, I've used date ranges to report predicted deliverable completion, which worked well but I don't think I've ever had anything finish before the latest possible date....)

My goal is to get the schedule closer to what the end reality is most likely to be on the first iteration. Are these viable approaches? What other solutions would meet my goals?

Answer 1

This is risk management. The same logic goes into determining your target start date as what goes into your target timeline and budget. Based on your risk assessment, you have to draw a line in the sand and say this project is going to start on this date. The early start and late start date for the rest of your work package network is calculated based on your target durations and your predecessor-successor logic.

So you would analyze this as you do with all areas of uncertainty. That is, under your best case, what is the earliest date the project has likelihood of starting; under your worst case, what is the latest date the project has likelihood of starting; and under your most likely case, what is the most likely date. Once you understand your probabilistic distribution of the possible start dates, you can draw that line in the sand based on your level of risk aversion.

Once you choose, that is the date that is baselined in your schedule. If you get delayed, you DO NOT reschedule the rest of your baseline. This becomes a source of variance to which you manage, applying techniques where you can to bring your dates back in line.