I have been P6, MS Project 2013 and 16 user.
I’ve not worked in an on-going mixed Project version environment so I can’t comment on the cause being the multiple versions. I did experiment in a mixed 2013/16 environment during our migration from 2013 to 2016 and I can say that scheduling and resource leveling will produce different results between 13/16, but these process don’t update baseline fields.
What I can tell you is that there are two basic ways in which baseline fields are changed in MS Project.
First, Project in it’s infinite wisdom allows the PM to manually edit ALL baseline fields. Unlike P6, Project doesn’t lock any baseline fields from manual update. So it’s possible the PM could be manually typing over existing values. Note that the PM would have to be manually entering values directly into specific Baseline fields. Meaning manual updates to (non-baseline) fields such as Start, Finish, or Work will not automatically replicate those manually entered changes into Baseline fields.
Second, Project will add/update baseline field values using the PM invoked Set Baseline function. Having used P6 and understanding the complexities of trying to update baseline values for select task(s) in a P6 schedule, Project’s Set Baseline function is much much easier to use. But with that said, the Set Baseline function also allows you to do illogical things like update a task’s baseline values without rolling up the impacts of those changes to the rest of the baseline, thus creating a baseline where summary baseline numbers won’t actually match the task details. The Set Baseline function also makes it very simple to accidentally update baseline values on every task when, for example, the PM only wanted to update one task.
What I haven’t seen is a scenario where Project changes the Baseline fields on it’s own.
Here’s a few suggestions.
* Familiarize yourself with all the Set Baseline capabilities. How to take a full baseline, how to update individual tasks, how to copy full baselines.
* Establish rules with the other PM(s) to never manually change baseline fields and for when and how to use the Set Baseline function. As a side note, one PM I worked with years ago updated the baseline values on any task if they made changes to the task, because they didn’t understanding what the baseline was used for.
* Understand that Baseline (0), which is the baseline fields with no appended number, is the standard reporting comparison baseline fields unless specifically changed in the schedule.
* Establish rules for and the use of Baseline (0) and Baselines 1-10. For example, storing the baselines at different key project checkpoints. To illustrate, Baseline 1 could be the ROM baseline used to initially approve the project start. Baseline 2 could be the baseline at the first major checkpoint/gate. Baseline (0) is the current baseline (with approved change requests). And baseline 10 could be used to store the most recent copy of Baseline (0), the current baseline.
* Use the Set Baseline function to copy the current baseline into another set of baseline fields (for later comparison). For example, copy Baseline (0) to Baseline 10. Doing this also allows the baseline to be reset if needed by copying Baseline 10 into Baseline (0).
* Establish a view displaying tasks only when key baseline fields (such as Start, Finish, or Work) are not equal when comparing Baseline (0) and Baseline 10 values. Using a view like this daily will allow quick identification of Baseline (0) changes so that actions can be taken to investigate what somebody did to cause those changes to occur and then correct them.
While I can’t point to anything specific as the cause, I think these items will help establish baseline guidelines and help you identify how the baseline values are changing.
Hope that helps