(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?
(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.
Dear,
What is the implication if I tick or not tick the Caculate Multiple Critical Paths box in the Options, Calculation tab in MS Project 2007.
I find that a lot of tasks become critical if I tick the box.
Gary Lo
Printer-friendly version
Send to friend
At one time I had hoped that MSP's "calculate multiple critical paths" option would be similar to the multi-float path calculation options in Primavera. But no, as described already here, it simply takes all tasks without successors and forces them to a Zero-Total-Slack condition (by pulling in the late dates).
In my experience (i.e. with complex projects, multiple contracts, multiple deadlines, and variable calendars), the suggestion that this allows one to "track" multiple critical paths is just wrong. Total Slack in MSP is a reasonable indicator of a project's (single) critical path only under ideal conditions. Throwing five bunches of tasks - each representing a separate "critical path" - into a single bucket called "Zero-Total-Slack" is hardly "tracking". Which path is which?, and what happens to total slack when you introduce variable resource or weather calendars for different tasks.
Tracking progress - and more importantly, making accurate schedule forecasts - against multple, drop-dead contract milestones is important in many projects. Even simple projects would be better served by focussing on a contractual completion milestone that may or may not align with the last task in the project schedule. (The grass versus bridge example in prior discussion comes to mind.)
For MSP, my firm developed our own tool to trace logic and visualize the "driving path" for key project milestones or for any other selected task in the schedule. We also compute the Path Relative Float for non-driving tasks - e.g. "how much could Task ID 24 slip before it starts to drive Task ID 137?" We are considering sharing this tool with others and are looking for advanced MSP users to test: http://www.planningplanet.com/forums/microsoft-project/578224/logic-tracing-msp
Evgeny,
I agree with you, if delay of an activity will delay a contractual milestone then it is critical.
It is not uncommon for our contracts to have several contractual milestones. This I understand but I have some issues with the following:
Ancient CPM was developed without considering resource leveling, without considering date constraints, the computations were correct under the absence of these. But soon resource leveling and date constraint were incorporated, unfortunatelly the computations of some values were not adjusted.
I understand delay analysis shall consider all contractual constraints, that non-contractual date constraints shall not be used is another requirement.
I do agree with reserving some buffer float to the contractor while remaining belongs to whoever reaches it first. It is onerous under the excuse of reaching it first to take ownership of all float leaving the contractor without some reserve. It is also onerous to say every action that the owner takes represent a relevant impact to the contractor and owner will always be liable. This is starting to change on our side of the Atlantic thanks to the British who adopted the concept long ago and allow for the use of buffers, they consider it a good practice and I completely agree.
Eventually you will find that under resource leveling most software computes wrong values of float what some of those who could not figured it called Phantom Float, but it can be correctly computed as Spider does. This is another challenge to ancient CPM concepts that Spider dare to question, resource critical float can be computed correctly as well as date constrained floats if using appropriate mathematical models.
Best regards,
Rafael
Mike,
I am not sure I entirely agree with you.
It is just that Microsoft Project has option to effectively have several finishes of the project and gives you possibility to have therefore several critical paths and to track each of them independently.
As an example you can have a Finish, called “Building of the bridge is finished” and another one, called, “Grass around the bridge is planted”, which will be done later, and which is less important.
Without this option switched on, all float will be calculated against “Grass around the bridge is planted” milestone, which is probably not so correct, as one would want to concentrate on finishing the bridge.
Regards.
When there are "separable portions" they are like sub-projects within the overall project each one proceeds through its own mini network to its own concluding finish milestone, and this is what "calculate mutiple critical paths is for, and MSP will show it.
Hi Evgeny
Thanks for the example - just another reason why MSP is not fit for purpose in delay analysis.
Best regards
Mike Testro
Gary,
This option effects, how MS Project treats tasks without successor. It is explained here:
“You can choose to calculate and display a critical path for each independent network of tasks within the project. By default, Project sets the late finish date for tasks without successors or constraints to be the project finish date. If you choose to calculate multiple critical paths, Project sets the late finish date for these tasks to be their early finish date, making the task critical.”
Look at how MSP calculates the total slack of the task without successor with and without this option enabled. Also notice, that in 2nd example MSP shows task ID=6 as critical
Calculate multiple critical paths DISABLED
Calculate multiple critical paths ENABLED
Regards.
Evgeny
Hi Lo
In my experience more than one critical path on a project means the schedule has been rigged for a result.
Section Completion programmes should have a critical path of there own but MSP wont show it.
Best regards
Mike Testro
Email: PPadmin@planningplanet.com
Replies