This topic contains 3 replies, has 2 voices, and was last updated by Heather Agee 1 day, 7 hours ago.
- 04/10/2019 at 7:57 pm #415313
I have only been using MSProject (v2016) for about a year, having lots of experience with P6. One of our clients has been complaining that the baseline dates in their project have changed. The first time, I wondered if I had just updated the wrong column, but then I hid the baseline columns to prevent that. Then I found that if I copy an existing activity, that its baseline dates are copied as well (which I didn’t notice because I had hidden baseline dates). So, I now only add new activities by [Insert] key. But with more complaints, I did a compare against their identified approved baseline and found over 300 baseline dates were different, including many that I never have touched, for sure. Unfortunately, the PM sometimes make changes without telling me, and he has an older version of MSP-2013, so I wonder if that is related. I am completely stumped as to what is causing this problem, and how to prevent it in the future. Is it related to possibly different MSP versions date offsets (like happens going back and forth from P6) or a bug in MSProject, or what? Your thoughts, please. Thanx.04/10/2019 at 9:18 pm #415314
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 helps04/14/2019 at 8:08 pm #415336
Thanx for your well considered answer. I will say that the sheer extent of baseline date changes are as unlikely to be anything the PM has done to individual dates as it is for me. What may have happened is one or the other of us may have accidentally set a new baseline (0) inadvertently, but I’m really not inclined to seriously consider that either. The different versions may be a better candidate for the problem.
As far as establishing rules for baselines and other stuff, the PMs are not supposed to be changing any schedules that have been assigned to a scheduler, but any of them that feel they want to do their own changes do so despite corporate policy, with no repercussions that I can see, so nothing I do or say will have much or any effect. One thing that may at least allow me to have better control would be your idea of setting one of the numbered baselines, and then periodically compare that against the “official” one. Not sure how I can accomplish that at this point, since much has occurred and been updated in the schedule since the November baseline was done.
Ultimately, I must say that I still feel a strong possibility that there is something wrong in MSProject itself, but it is so poorly controlled that there is little that can be done with it. You pointed out one of the most serious deficiencies, in allowing baseline to be editable AT ALL. I can’t even tell you how aggravated that makes me, and how poorly that reflects on Micro$$oft. “Infinite wisdom” — posh and balderdash!
Anyhow, thanx again.04/18/2019 at 7:29 am #415355
If you are using existing tasks to create new tasks, just go to the Set Baseline utility, and hit “Clear Baseline”, then select “for selected tasks” so that you do not clear all task baselines. You have to be very careful with this, but that is a way to copy/paste activities and remove the baseline that was on the copied task. Then when you have updated the activity, you can “Set Baseline” “for selected tasks” and it will set the baseline for only the task(s) you have selected. I also recommend recording all baseline adds/changes/removes in a baseline change log.