To add to the elementary discussion of your article:
There are two main advantages to using a Deadline instead of a Finish-No-Later-Than constraint in MSP:
The single allowed slot for a task constraint may be used for other purposes;
The logical conflict that accompanies unmet late constraints - (by default, MSP re-schedules the task to meet the constraint date even if it violates logic) - can be avoided without changing the default settings for the project.
In every practical respect, Deadlines in MSP function identically to Finish-on-or-Before constraints in P6. That is, they override the late-finish dates in the absence of more stringent conditions, and Total Slack is reduced as a consequence.
Unfortunately, your article seems to invite the novice scheduler to use Deadlines willy-nilly without fear of complications, and this is wrong. Imposing multiple deadlines "throughout the schedule" as you suggest in the final paragraph makes Total Slack completely unreliable as an indicator of the Driving Path to Completion -- of the Project or of any deadlined milestone. Since MSP defines "Critical" tasks solely based on Total Slack, your novice scheduler may be hard-pressed to accurately describe where the real "Critical Path" is.
For these reasons - and for your mention of "longest path", which is a concept that is distinctly foreign to any out-of-the-box MSP schedule - I would suggest deleting your "Summary" paragraphs and starting over. In my view, Deadlines in MSP are essentially not a huge advantage - but a patch needed to offset weaknesses in other areas of the tool.
By the way, all of these issues are easily resolved with a 3rd-party add-in that I use, but very few MSP users seem to have access to similar tools.
Member for
18 years 11 monthsEmily,To add to the
Emily,
To add to the elementary discussion of your article:
There are two main advantages to using a Deadline instead of a Finish-No-Later-Than constraint in MSP:
In every practical respect, Deadlines in MSP function identically to Finish-on-or-Before constraints in P6. That is, they override the late-finish dates in the absence of more stringent conditions, and Total Slack is reduced as a consequence.
Unfortunately, your article seems to invite the novice scheduler to use Deadlines willy-nilly without fear of complications, and this is wrong. Imposing multiple deadlines "throughout the schedule" as you suggest in the final paragraph makes Total Slack completely unreliable as an indicator of the Driving Path to Completion -- of the Project or of any deadlined milestone. Since MSP defines "Critical" tasks solely based on Total Slack, your novice scheduler may be hard-pressed to accurately describe where the real "Critical Path" is.
For these reasons - and for your mention of "longest path", which is a concept that is distinctly foreign to any out-of-the-box MSP schedule - I would suggest deleting your "Summary" paragraphs and starting over. In my view, Deadlines in MSP are essentially not a huge advantage - but a patch needed to offset weaknesses in other areas of the tool.
By the way, all of these issues are easily resolved with a 3rd-party add-in that I use, but very few MSP users seem to have access to similar tools.
Rgds, tom