Earlier quoted context omitted.
MSFT did the same thing with Project when they introduced something called "Manually Scheduled Tasks." Project is fundamentally a critical path scheduling tool, or at least was. Task A must finish before Task B, which must complete before Task C. If A is delayed, then that delay pushes B and C out, too. This is what it's FOR, more or less. Manually scheduled tasks don't move. They're set with whatever dates you give…
> People wanted this because some (dumb) people insisted that "well, that task CANT move because it has to be done by then!" So? There are tasks like this that simply CANT move, why should a project management tool not have the ability to model that? If you don't like the feature you don't have to use it. I get that you wouldn't want these fixed dates and if you can just plan and execute your project by yourself, but…
I've been working with scheduling and project management tools for 20 years -- not just MS Project (widely regarded as the idiot cousin of the market, honestly) but also things like Primavera.
There's no reason to have a "manual" task in a scheduling tool.
First, if you have a task that can't move, you set it with a deadline and watch your deadline (as well as watching to see if the task moves PAST the deadline). Cementing the task in place doesn't help you; in fact, it actively HURTS you because it hides the fact that your forecast path isn't valid anymore.
Second, these tools ALSO include the idea of constraints. Scheduling tools include the idea of constraints which limit the critical path motion according to specific rules (based on the type of constraint in play).
Using ANY constraint, though, is frowned upon in serious scheduling circles precisely BECAUSE they distort the predictive ability of a critical path schedule. If Task C has a hard deadline of 1 Sept, then you watch you critical path to see if that remains possible. As tasks slip, you stay on top of the chain of tasks to seek opportunities to streamline or reduce scope ahead of critical task so that the deadline can be met.
(Guess what? It's not always possible.)
And you do this because you SEE that the schedule shows Task C moving to the right.
If you lock the task in place, odds are you won't notice that your critical path is collapsing.
The tl;dr is that cementing a task in place in a critical path schedule is not a good way to model deadlines. This is something any competent scheduler will tell you. It's part of the PMBOK, it's built into DoD scheduling guidelines, etc.
>Maybe there is more to Microsoft Project than just YOUR use-case?
Hilarious. I will say it's clear one of us doesn't quite understand the problem domain as well as they might represent, but given my background I know it's not me.