Comment by VonGallifrey | Hacker News Reader

Comment by VonGallifrey | Hacker News Reader

Parent Full thread

> 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 that is not always the case.

As an example: I had a project where it was really important for us to inspect the Aircraft Type (A321) into which we wanted to install our hardware and software. We where given an opportunity to do so by an airline during the maintenance of one of their A321. This was a fixed date. If we didn't finish our preparations before that maintenance date then we simply would not get this opportunity (or at the very least would have to wait a very very long time for the next opportunity). The Aircraft would simply not wait for us.

Not every task can move and just because you think they should does not make it so. Maybe there is more to Microsoft Project than just YOUR use-case?

This is such a "peak HN" kind of response.

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.

This feels more "peak HN" than the previous poster as it's dripping with self-importance and condescension.

Or, you know, actual knowledge about the problem domain. But you do you.

Reply on news.ycombinator.com