Troubleshooting: Why does my Gantt chart in MS Project keep shifting dates?

"It's less about the software being broken and more about it applying a rigid priority order." This is a distinction without a difference to the sales team watching their launch date slide a month because the tool prioritized a hidden rule over their explicit plan.

You're describing the problem from the inside out. The rigid priority order *is* the broken part for anyone using this outside of pure CPM theory. When a hard deadline for a vendor deliverable breaks the chain, the "nonsensical" downstream push isn't a teaching moment about network design, it's a failure of the tool to surface the conflict clearly before it commits the change. It enforces its logic silently, then presents the chaotic result as a fait accompli.

The suggestion to design with slack and lags is academically sound, but it's just workarounds for a tool that can't gracefully handle the real-world mix of fixed dates and fluid dependencies. We're optimizing our process to fit the software's pathology.

I agree that the default behavior feels like the tool is working against you. The moment you manually adjust a bar, it's converting your intent into a hard rule, often without a clear warning.

This actually makes me wonder how other tools handle this. Does Asana or Monday.com have a clearer way of showing when a date becomes manually overridden versus being driven by dependencies, or do they just avoid the complexity altogether?

That's a great question about a "placeholder mode." There isn't a single setting for it, but you can get close with a specific combination. The closest thing is turning all new tasks into "Start No Earlier Than" constraints by default under File > Options > Schedule. That gives you some flexibility, but it's still a constraint, just a softer one.

Your draft forecast analogy is perfect, because that's really what manual vs. automatic scheduling tries to do. If you set a task to "Manually Scheduled" before you drag the bar, it *should* act as that true placeholder and not create any hidden logic. The problem is the default "Auto Schedule" mode, where any direct edit gets interpreted as a hard "Must Start On" date.

So the ritual is: switch the task to manual, move it, then maybe switch it back to auto to see how it recalculates. It's clunky, but it's the sandbox you're looking for. Honestly, this is why I often sketch initial timelines in a simpler tool first.

You've correctly identified the primary technical triggers, but you're focusing on the tool's mechanics instead of the human process that allows it to happen. Your first bullet point is the key: the software converting a drag into a hard constraint.

In cloud billing, we see an exact parallel. A finance team drags a budget forecast line in a spreadsheet, breaking its link to the underlying cost driver formulas. The system isn't sabotaging them; it's just dumbly obeying the last manual command. The failure is the lack of an immutable audit trail showing *why* the date changed.

The fix isn't just understanding SNET constraints. It's implementing a policy that any manual date adjustment must be accompanied by a task note explaining the business reason. Otherwise, you're just documenting the symptom, not the cause.

That's a really interesting parallel to cloud billing. It feels like the same core issue, just in a different tool.

But doesn't adding a note policy just add another step people might skip? Like with the manual scheduling switch, if the process is manual and easy to forget, won't the audit trail have the same gaps? Maybe the tool should force a note pop-up when you create a hard constraint by dragging.

That's a good point about the policy being another forgettable step. But a forced pop-up could get annoying fast, especially for small, valid adjustments.

Maybe the real need is a clearer visual cue? If the bar changed color or had a tiny icon the moment it became a hard constraint, you'd see the impact immediately without an extra click.

That's a practical suggestion, and I think you're onto something with a visual cue. A subtle icon or color shift in the Gantt bar itself could act as a real-time nudge without interrupting workflow.

The challenge is making it intuitive enough that people immediately understand what the cue means. In a busy project, a new icon might just become visual noise unless it's paired with some basic team training on what to look for. But as a first-line alert, it's a solid idea.

Oh, that first bullet is something I've definitely seen. The "Start No Earlier Than" constraint catches so many people off guard. You drag a bar thinking you're just sketching, and suddenly it's a rule that fights your other plans.

Can you explain what you mean by "inadvertent use of automatic constraints"? Is it that the software adds them without asking, or that users create them by accident just by clicking?

Exactly, that infrastructure-as-code comparison hits home. The undocumented default is the killer. It's like comparing SaaS onboarding templates, where one tool's default "send welcome email" checkbox can blast a test contact list.

Your point about documenting initial settings in the plan is key. I've started treating the project summary task as a config log, listing the key schedule options from File > Options. It's the first thing I check when a plan from another team acts weird, kind of like checking a Dockerfile for an odd base image before debugging the app. Have you found a standard format for that, or is it just a bulleted note in everyone's own style?

The SNET default is notorious and mirrors a classic AWS Reserved Instance issue. You buy a 1-year convertible RI expecting flexibility, but the system locks you into a specific instance family unless you manually convert it, often after the savings window has passed. Both are cases where a default "helpful" automation creates a hard constraint that fights later adjustments.

Your second bullet about dependency types is equally critical. It's the difference between a Finish-to-Start and a Start-to-Start dependency, akin to choosing between a Standard vs. Convertible RI. One creates a rigid sequence, the other allows parallel execution. Misapplying them wrecks the schedule just like misapplying an RI type locks you into the wrong compute family.