How do I Change my forecasted start dates when work doesn't begin?

[Oimate28]

I have a project task forecasted to start on 5/8, but work has been delayed
and will not start until 6/9. Should I leave the forecasted date alone and
put in an actual start date when work has begun? Or should I change the
forecasted start date, knowning it has not yet beguN?

 

[JulieS]

Hi Oimate28,

You could use the Tools > Tracking Update Project > Reschedule
Uncompleted Work to start after to change the projected start date of
all tasks not marked 100% complete.

I hope this helps. Let us know how you get along.

Julie

 

[Ratheesh]

I would leave the forecasted date alone and put in an actual start date when
work begins as this will allow me calculate various other parameters at the
end of the project.

 

[Oimate28]

Thanks to you both for your responses. I love this discussion forum. I
guess my question is 2 parts. 1st part asks about the principle / philosophy
of project forecasted dates. I have heard that you should never change
forecasted dates in project. Is this true? If it is not true, then I have a
question about Jules suggestion. Jules, I followed your instructions to
update the forecasted start date from 5/8 to 6/9, but when I do this, I get a
constraint icon in the information column. I have been trained that any
constraint icons are an indication of weaknesses in the schedule. What are
your thoughts? Thank you so much for your earlier feedback. I have been
looking for a resource to help me learn the true fundamentals of project so I
can learn to manage a project from a foundational sound project schedule. I
have been in over my head in the past on Project.

 

[JulieS]

Hi Oimate28,

You are most welcome and thanks for the feedback. I'm glad you are
finding the newsgroup helpful

To your questions:

The idea of "forecasted dates" in Project is actually two-fold. Once
you have created your plan, you should save a Baseline (Tools > Tracking

Save baseline). The baseline is a copy of the start, finish,

duration, cost, and work as planned. That information (Baseline) does
not change unless you re-baseline the project or tasks.

Once you begin to supply actual data to project through tracking, the
dates in the Start and Finish fields may change. For example: you
originally planned a task for 3 days duration. In tracking the task you
have already worked 2 days in actual duration and your resources realize
that instead of 1 day in remaining duration, they actually have 2 days
remaining before the task will be complete. By updating the remaining
duration to 2 days, Project will forecast the new Finish date, which
(assuming the task has a successor) will change the schedule of the next
task. In my opinion, that is precisely what should happen. The
baseline data has not changed and we now have Variance (Duration
Variance, Finish Variance, Work, and Cost Variance).

To your second question: Constraints seem to have a somewhat bad
reputation. I agree, in part, that constraints may be a sign of
"weakness" in the schedule but usually only because people use
constraints instead of links (predecessors and successors) to drive the
schedule. Constraints such as those imposed by the Reschedule
Uncompleted Work command are not, in my opinion, a sign of weakness, but
rather a reflection of reality. We were supposed to start this task on
5/8 but due to circumstances, we cannot start until 6/9. If you waited
to reflect the change in start until you actually started the task (by
entering an Actual Start date), you have potentially lost the time
needed to make adjustments to the revised schedule to meet your
deadlines.

I hope this helps. Let us know how you get along.

Julie

 

[Oimate28]

Yes. That is very helpful! Thanks.

Hi Oimate28,

You are most welcome and thanks for the feedback. I'm glad you are
finding the newsgroup helpful

To your questions:

The idea of "forecasted dates" in Project is actually two-fold. Once
you have created your plan, you should save a Baseline (Tools > Tracking
duration, cost, and work as planned. That information (Baseline) does
not change unless you re-baseline the project or tasks.

Once you begin to supply actual data to project through tracking, the
dates in the Start and Finish fields may change. For example: you
originally planned a task for 3 days duration. In tracking the task you
have already worked 2 days in actual duration and your resources realize
that instead of 1 day in remaining duration, they actually have 2 days
remaining before the task will be complete. By updating the remaining
duration to 2 days, Project will forecast the new Finish date, which
(assuming the task has a successor) will change the schedule of the next
task. In my opinion, that is precisely what should happen. The
baseline data has not changed and we now have Variance (Duration
Variance, Finish Variance, Work, and Cost Variance).

To your second question: Constraints seem to have a somewhat bad
reputation. I agree, in part, that constraints may be a sign of
"weakness" in the schedule but usually only because people use
constraints instead of links (predecessors and successors) to drive the
schedule. Constraints such as those imposed by the Reschedule
Uncompleted Work command are not, in my opinion, a sign of weakness, but
rather a reflection of reality. We were supposed to start this task on
5/8 but due to circumstances, we cannot start until 6/9. If you waited
to reflect the change in start until you actually started the task (by
entering an Actual Start date), you have potentially lost the time
needed to make adjustments to the revised schedule to meet your
deadlines.

I hope this helps. Let us know how you get along.

Julie

 

[JulieS]

Hi Oimate,

You are most welcome and thanks for the feedback. Do post again with
any further questions.

Julie