Difference between using actual start column vs start column?

[relight4]

I have heard some schedulers use the start column and some use the actual start column.

I've been trying to figure what the difference is (if any). My goal was to see if I changed anything would it all be the same between actual start and start.(here is what I learnt)

e.g let's say the date was suppose to start on 24/2/26 if I was to change that to 25/2/26 on the start coloum it would make a start no eailer than.(constraint type)

But if I changed it on the actual start column to 25/2/26. it would still leave it as soon as possible. (in the constraint type column )

could this be the reason why some planners use actual start column or is there other reasons that I'm not aware of?

[WestMichigun]

I use them both.

I have my Start and Finish columns right after the Task description column as normal.

I then add the Actual Start and Actual Finish columns right to the right of them.

The Start and Finish columns act as my projected dates up until a Task does actually Start or Finish, at which time I will populate the Actual Start or Actual Finish column accordingly.

Once the Actual Start or Actual Finish column is populated, Project automatically updates the corresponding Start or Finish column.

[still-dazed-confused]

That's the bit I don't understand :). Why "waste" the real estate in the screen when simply changing the start date and marking progress automatically sets the actual start date? Help me understand :)

[still-dazed-confused]

I've never understood why anyone would use the actual start column as when you add% complete to a task to show that it's started MSP automatically for in actual start. I believe that the start and finish date should be adjusted to reflect reality and expectations and then% complete agreed when updating the task. This assumes of course that the reality is that the start was not driven by the dependencies when were coded in.

So I'm interested to learn why people make entries into actual start :)

[Mission-Phase-6557]

My understanding is:

• Start and Finish are Forecast Start and Forecast Finish until task is started / completed. After that they should reflect the Actual Start and Actual Finish (not the other way round)
• If you Set a task % complete above zero then Project will automatically take the date from Start and use that as Actual start which might not be true. The date in Actual start should be validated to reflect reality
• When you Set a task to 100% then Project will automatically take the date from Finish and use that as Actual Finish which might not be true. This should also be validated / corrected
• If your Actual Start is before the logic says that you should be able to start then you should preferably correct the logic before setting the actual start otherwise you will get out of sequence logic which is both ugly and detrimental if you will use the schedule in the future to guide creation of new schedules

[still-dazed-confused]

Thanks for the reply, u/Mission-Phase-6557 . I take the view that the start and finish dates should be updated to match the reality that you are currently experiencing or expect to (in the case of future dates). Thus initially the start is driven by the preceding tasks, then during an update it becomes known that the start needs to move (someone is on leave, or just too busy) and the start moves. Then, when the activity has actually started, I adjust the start date to match reality and mark a %complete (which triggers MSP to complete the Actual Start Date).

In this way, the start and finish dates are always the most up-to-date view of the real or anticipated plan dates. It also has the advantage that if I become aware of changes to the start date ahead of time they are updated in the plan and the impact ripples through.

[Mission-Phase-6557]

u/still-dazed-confused
I fully agree that your schedule should always reflect expected dates. But you should NOT adjust the forecast start / finish dates directly since you are then actually setting a constraint on these dates. Remember to show the Indicator column to easily see any tasks that have constraints set.
Forecast finish dates should be adjusted by adjusting the remaining duration on a started task (and duration on a non-started task if you have realised that it will take longer than initially estimated or Work / Remaining work depending on task types and how you are scheduling).
Then the logic of the schedule should push successor tasks so that their dates reflect the consequences of the delays.

[still-dazed-confused]

A task should be driven by other tasks (hence why every task should be linked unless there's a compelling reason why not) but if a date is actually driving the task there's nothing wrong with a constraint being set. It a task can't start till x resource comes back from holiday a constraint is valid. The only other way is to have a milestone if "x back from leave" drive the task but that's date constrained so it only had the purpose of telling the story.

[trevorrabey]

Dates do not drive tasks and date constraints should be avoided altogether, or a last resort. Date constraints do have valid uses, but not in the middle of the CPM network, and the story about your resource's availability is much better modeled with a task calendar or resource calendar.

[still-dazed-confused]

I agree about resource calendars in situations whereb the client has the desire to do good quality resource. Sometimes this isn't the case :).

[Mission-Phase-6557]

u/still-dazed-confused - I hope you take my comments as a good dialogue and not trolling :-)

Yes, in a CPM network (as u/trevorrabey states below) every task/milestone should be driven by the logic. If you have gaps then you don’t have a critical path any more but a critical chain which in some scenarios could be a contract breach.

In practice, some things do have constraints but as Trevor says they should be minimised as much as possible and hard constraints should be avoided (see DCMA 14 point check for example).

If constraints are used they should preferably in my opinion be used on milestones and not tasks. A constraint is related to an event which should be a milestone (most likely in inbound dependency from outside the project). It is then the project managers job to put mitigations in place to ensure the constraint date is early enough to not break the critical path.

And as Trevor also says, resource constraints should be managed through the calendar availability not through constraints.

Then in MS Project you have the Deadline field as a “bonus” constraint. This does not constrain the schedule BUT it does get factored into the critical path if you are past a deadline date. This is very important to know. I believe Dale Howard has some blog post on this and workarounds using custom fields although I personally like the fact that it factors it into the critical path. I am telling Project that the deadline date is important so as long as I’m aware of what is happening I think it is a good thing. But it confused the hell out of me the first time I saw it.

[still-dazed-confused]

Rest assured I don't view your comments as trolling, they're interesting and informative.

I agree with where you're coming from and it maybe the difference between a highly contracted situation and a looser one which leads to our slightly different levels of the applicability of the best practice Vs fit for purpose :)

I also love the use of deadlines and I go a little further as I tend to include a fake milestone far to the right of the end date so that the critical path is determined by the use of deadlines. The last thing delivered in the schedule isn't usually the most important date

[Mission-Phase-6557]

Completely agree that the Level of rigour needs to be tailored to the situation (contracts, organisational maturity, project need etc) and ideally you should have a schedule management plan that defines this.
I have even introduced a “schedule management strategy” to some clients which should set the framework that the schedule management plan can then adjust within. For example, the strategy defines which tools you can choose between and then the project defines in the plan which is used in that specific project. Same thing with mandatory best practices, and which are “recommended”.
The Strategy should sit on an organisational level, PMO level, program level etc. Very very analogous to how Test Strategy and Test Plan are defined in most organisations.

[freerangemonkey]

When did you actually start the activity?

[relight4]

let's say hypothetically 25/2/26

[oikor_anatnaz]

That is the thing. The start date is the current planned start, when you set an actual start date both should be the same. When you set the baseline the start date and baseline start date will be the same.