How can I manage a project timeline when events and milestone dates change very often?

Question

Editing my question to be appropriate for this board.

What ways of tracking the milestones/events of a project whose dates are changing very often.

My initial thought was to have a timeline that allows the user to easily move the event whenever the date changes but maybe there are other ways to do this.

I am not even sure how to tackle this better because we don't always have set in stone dates. We get a date today, a week later it changes and so forth.

I am interesting in finding a project timeline software that has an interactive >visualization of the actual timeline. This means that if the date of a certain >event has moved, you can just click+hold it and slide it to the new date.

I need something that can be easily modified without having to enter/alter any >text. So, instead of going to a certain event and editing the actual date, you >can just move its marker further from the initial position.

I need this because the dates on my project change often and there are never >100% certain dates. This would allow us to move the marker to a 'proposed date' >and keep on doing this until we have certainty.

An alternative would be a timeline software with which you can easily right >click and "enter a new event". This way we could just delete and easily add a >new mark on the 'proposed date'.

Do you guys know any (open source preferably, but not necessarily) project >timeline software that has this type of user interaction implemented?

Answer 1

Sounds like the real problem is one of schedule and uncertainty; I actually envy you - if people are changing dates that often that means that they care about the schedule. I don't know why your dates are fluid - the answer to that question may provide deep insight. I'll provide some answers based on my experience.

I use a couple of techniques to deal with similar problems.

1. PERT estimation - the simplest solution is simply to average the best and worst estimates, which will probably get you a fairly good estimate. This is tremendously helpful if you want to do Monte Carlo analysis (the best and worst figure prominently).

2. Milestones. usually there are dates that are more certain than others. In my environment, I can usually work with the developer to estimate design & development with some confidence (and I can use the next technique to improve that confidence). In our world, the dates that are highly fluid are the governance dates - We know that we should not or can not move to the next stage until the customer signs off. Those signoff dates are milestones with 0 duration, and all subsequent tasks depend on the completion of the milestone. I can report with confidence that every day that management delays approval, the end date of the project is moved back 1 day. All those milestones are on the critical path. When management asks me why the project is constantly delayed I can point to the milestone and say, "because your boss hasn't signed the approval to move past this stage of the project; get me a signature and we'll get to work on the next step."

3. Monte Carlo Analysis Takes a few moments to set up the first estimate, and you do need a best case and a worst case and a notional shape of the probability distribution. This will allow you to make sophisticated confidence intervals with arbitrary precision.

4. Confidence intervals. I think Glen Alleman introduced me to the concept that all (responsible) numbers are estimates. He trained me to never say, "This deliverable will complete on March 3, 2015." - instead I should say, "Based on the information we have, there is an 80% probability that this deliverable will complete before March 5, 2015." This isn't a popular or easy way to convey information, but it is accurate, and it has some neat knock on effects. Confidence intervals permit you to have conversations like the following:

   • I could increase the confidence to 90%, or 95% or 99%, but there is a cost to that information. Raising that confidence will require us to measure the productivity of our developers; there will be a direct cost in the time, effort and technology to perform the study and an indirect cost in developer resentment. How much is the extra confidence worth to you?
   • I cannot increase the confidence by assigning more people; let's discuss the mythical man month.
   • I can advance the delivery date and improve the confidence if you consent to raise the priority of the work product; right now my developers are split 60/40 between this project and another. If you shift the lead developer to 100% for 2 weeks then we can take 1 week off the estimate and raise the confidence.

There are a couple of cases where none of the above techniques will work; in these cases there is no technique that will work because the problem is outside the schedule.

• Schedule developed in an Ivory Tower - I'm familiar with one Project Management Organization where it is considered ideal for a professional project manager to develop the schedule in consultation with the business leaders and actively isolate the process from the workers. Sometimes workers don't even know they're on the project and they never see the schedule until after they have already slipped. No amount of project planning expertise will fix this. Schedules must be developed by the project team and coordinated with the stakeholders.

• Gritty basement schedules - the opposite of the above. I've worked on projects where the techs build the schedule without any participation from or review by the project stakeholders. The resulting schedules are unrelated to business needs, and are irrelevant before they are printed.

• There is no project. PMI scheduling is based on the assumption that stakeholders endorse the schedule, and the project manager reports on the schedule. If there is no cost to changing the date of a deliverable, then that date will be changed capriciously. The Project manager needs to be able to say, "That change will delay the final project by X days, $Y dollars and risk Z consequences." If you can't do that, then there is no project, there is just a bunch of people doing work.

• There is no sponsorship. If the sponsor is unengaged, then it may not make a difference that a change will delay the project and increase the cost. From what I hear in the literature, this is relatively common. The PM needs to find a way to get the sponsor's attention or the project is doomed.