Make 'Start' and 'finish' dates Read only
PMs often change 'Start' and 'Finish' dates for tasks accidently which, in turn, applies scheduling constraints to tasks. This often introduces confusion and complexity into a schedule.
Instead I suggest that 'Start' and 'Finish' columns for 'Auto scheduled' tasks be made read only. (if you want to adjust dates, use manually scheduled tasks).
If a PM wants to impose fixed date (my means of a Scheduling Constraint) they could double click on the task and from the advanced tab of the Task Information apply a scheduling constraint from there.
I understand that this is a significant paradigm shift for Project but this is the next step since introducing 'Manually scheduled' tasks (which in my opinion should not be the default within Microsoft project, as this sends new, untrained users down the wrong path to scheduling greatness). If Apple can remove the earphone Jack, Microsoft can do this!
I like this idea. I often have to tell people new to MSP not to touch the Start and Finish columns, but only change dependencies and durations. Making Start and Finish into read-only fields would support this behavior.
The same idea could be applyed at Start and Finish baseline dates.
B SAI PRASAD (MVP) commented
Keeping the Start and Finish read-only for auto-scheduled and editable for manually scheduled task will be confusing. The reason for Start and Finish to be made editable is to provide the user to set quick constraints for auto-scheduled tasks, and set probable dates for manually-scheduled task. To make this change in habit, I recommend to insert Scheduled Start and Scheduled Finish (read-only fields) and hide Start and Finish columns. The Scheduled Start and Scheduled Finish would provide the to-be dates for both auto-scheduled and manually scheduled tasks
Dr. Edward M. Hanna commented
A very good suggestion. I would say that "accidental constraints" (i.e. those created when you enter a Start date or a Finish date) is an insidious problem with many, many client project schedules that I review. This, of course, leads to a great deal of user frustration when an accumulation of constraints is causing bizarre behavior in their schedules. They frequently blame the product (spreading the news to colleagues) and--when frustration reaches a limit--they stop using the product.
I would, however, like to suggest an even broader feature (i.e. configurable read-only fields) so that ANY field could be configured to be "read only". In addition to Start and Finish, there are other fields (e.g. WBS) that could benefit from being protected from spurious changes.
To explain my WBS comment, we don't want the WBS assigned to a task to inadvertently change when it has been mapped to the Project Cost Accounting System using that WBS code. (To be more precise, the OOB WBS code has a renumbering feature--making it unusable for PCAS linkage. So, I would be using an Outline Code as "WBS" and wanting to make that field "read only".)