MS Project Date Auto Update when Adding Predecessors

Question

I am creating and updating an integrated multi-project/vedor MS Project task tracker with the sole purpose of finding date issues, dependency issues, etc., so that we can align vendors in future meetings.

However, whenever I connect tasks (add predecessors) if there is an issue with the dates, instead of just highlighting them, they change them to "fix" the issue, which completely rendors this MASSIVE integrated task tracker pointless.

I don't want it to auto-change/fix ANYTHING! I'd rather it red them, highlight them, or literally do nothing, as we should be able to see late, past, overlapping tasks in a report.

I have to CONSTANTLY go back and change dates so they are correct for that particular vendors plan. It's honestly Beyond frustrating. I have literally unchecked EVERY box in the schedule area and it still does it. I would NOT use MSP for this if I had a choice, but I don't. I'm just a guppy in this pond.

PLEASE HELP before I lose my mind. How do I turn this auto correct for dates off?????

Answer 1

It sounds like you are trying to force dates but still want task dependencies. The whole point of creating a linked network is to allow Project to help schedule the plan based on estimated task duration and task interaction.

One thing you might consider is to set up the plan with your pre-defined dates with no task dependencies. Then set a baseline. Now, add desired dependencies. In the Tracking Gantt view you can see the impact on dates (baseline versus current plan). In particular, the Variance fields (Duration Variance, Start Variance, & Finish Variance), definitize the differences. If things don't line up then either the pre-defined dates are "premature" or the dependencies are not valid.

Answer 2

It's hard to work out exactly what you are doing from your description, however it could be that you are setting the relationships as FS (Finish - Start) which will move things around. Maybe if you set the relationships as SS (Start - Start) with defined start dates, that would resolve the date movements. Then if you set the resource levels to be one resource per vendor throughout each task, you should see where that vendor's time is overlapped on multiple tasks / projects as they should show up as over-committed.

Answer 3

When I am doing what you appear to be doing I will have the dates when things will arrive from the vendor as a dependency milestone. The subsequent tasks will hang off that so that if the date the vendor says things will arrive changes the plan can react to this.

If I am also tracking the vendor plan we can have their delivery milestone in the plan but we can choose not to link it to the "arrival" milestones in our plan.

This provides the opportunity for a mismatch across the plan but it sounds like this is what you are trying to track.

To do the tracking I set a text field for Dependency In or deliverable out (Dep in / ep out). Then I add an additional text field there for a unique dependency reference (Dep Ref). The two milestones (arrival and delivery) will be flagged with the relevant Dep in / out handle and they both have the same Dep Ref.

Now we can combine the plans into a Master / Sub plan so that we can see all the plans across the portfolio. A simple filter on Dep in /out and a group by Dep Ref will allow you to inspect the two plans for discrepancies visually.

To automate it more you can copy and paste it into Excel and do more analysis and tracking of the discrepancies. You can also use Excel as a dependency log and record updates, decisions etc if you are running dependency from across the portfolio or program.

If the program is very complex with dependencies that stitch across projects so that a movement in dependency 1 will cause a change to dependency 2 etc you can have a macro which makes electronically links the program's files to see the full impact and then destroys the links to return you to the starting place with all the dates changed. I had to use this approach with a program with 14 sub-plans and over 120 dependencies stitching the plan together.

In this way, you have an aligned program which isn't linked up and comes around in the way that you describe.