Critical Path Not Showing on P6 Schedule

Define Critical Activities as Total Float is Less than or Equal to 30days.

To eliminate all schedule margin or Terminal Float is not a good idea.  It is basic Project Risk theory that the more margin the more you increase the probabilities of success.  Still some "old school" specifiers require all Baseline Float to be used.

Anyway, padding activity duration mask true intent, it lacks transparency.

Better European specifications such as NEC require you provide some margin and if not it might be a reason for rejection.  You shall include allowance for rain as well as some schedule margin.  How much schedule margin can be rationalized if using project risk methodologies.

http://www.stevencevans.com/float/

Tom Tom pick 10 activities on your current critical path and increase their durations by 3 days each.

also have you included holidays in your calendar ? if not add them

also have you included the average monthly anticipated adverse weather days as non working days in your calendar and have you assigned the weather sensitive activities to to this calendar  ?

• That critical path can be anything is quite ambiguous. 
• It looks like Hammer's Rule at it best, "if it does not fit then hit it with a hammer until it does".
• No matter what ambiguous rule you want to follow the use of mandatory constraints will override any calculation.
• Please be reminded that P6 calculation of "Longest Path" breaks under resource leveling as well under any other type of constraints.
  • http://docs.oracle.com/cd/E17462_01/Web_Access/Help/en/Projects/Tasks/p…
  • The longest path is broken when activities are no longer driven by relationships; that is, when activity dates are driven by constraints or resource leveling. Longest path calculation includes interproject relationships. Therefore, activities designated as on the longest path may change depending on whether you schedule a project alone or with its related projects. If a project has interproject relationships and you schedule it alone, the interproject relationships are treated as scheduling constraints.

In their desire to see a flag fixed in time for a contractual milestone some schedulers use the mandatory constraint, not a recommended practice. Make sure you are not using a mandatory constraint, instead use a FNL type constraint.

http://warnercon.com/wp-content/uploads/2012/07/Article-7-Use-of-Milestones-and-Constraints1.pdf

• Finish-No-Later-Than (FNL) This is more commonly used, especially for projects with multiple, phased occupancy dates. Activity strings are highlighted as critical if they are driving a constrained item past it’s assigned ‘no-later-than’ date.
• A mandatory constraint will override the logic of the schedule when performing a schedule update for the sake of holding the date in place. A normal constraint date can be overridden by a schedule update but a mandatory constraint date cannot. Mandatory constraint dates are not considered a best practices in schedule updating for this reason. Similarly, if used in schedule leveling, the sequences might become altered in order to hold the constraint dates firm. With mandatory constraints an activity would be frozen from moving beyond the date constrained, thus potentially not reflecting reality. The mandatory constraint date does not show the effect of late or early completing activities. A normal constraint date would show negative float (behind schedule) if it was late to complete when its predecessor and successor activities had completed, whereas, a mandatory constraint would instead freeze the associated activities from being completed. Effective use of mandatory constraints requires recognition of the implications of its use. Some schedulers try to show that the schedule can finish on time by constraining the end date and then leveling the schedule. This is not recommended unless trying to create a recovery schedule and the resulting activity durations and logic are carefully reviewed.

Same as client I am not an advocate of using activities to represent buffer, we compare current schedule start and finish dates to a target late-schedule and calculate start and finish buffer for every activity.

 

Tom Tom, 

You need to escalate this as a contractual issue, as the client is attempting to force you to schedule the project using unsound practices.  First take a very close look at the specs.  Re. the three options from Zoltan:

1. Use FOB constraint.... Not allowed by client (check spec?)
2. Use project buffer activity.... Not allowed by client (check spec?).  How else do you handle schedule contingency?
3. Bump Critical Float Threshold.... Not allowed by client (check spec?) Longest Path method required.

Another option (which your client seems to want) is to sprinkle 30 days of duration padding along the rest of your critical path.  Though not unheard of, this is the first step to turning your schedule into a pretty picture to hang on the wall rather a tool for effective project management - Not recommended.

Check the specs, then call your boss.

1st I think that the Client is wrong in rejecting the FINISH ON OR BEFORE constraint. The finish on constraint can delay an early finish or accelerate a late finish to satisfy the Constraint date.

However, the finish on or before limits the latest time it can be finished. The finish on or before constraint affects only the late dates.  Use this constraint to ensure that the late finish date of an activity is no later than the date imposed. This is where the backward pass will start and is the correct setting to use here. 

2nd if you have 30 days of float add an activity of 30 days for test,checkout and punchlist you now know you have a buffer in there. You can reduce this duration if you begin to lose time.  

3rd the other option is to go to scheduel then options and where it says define the critical activities as select total float less than or equal to and make that 30. Then anything with a float value of 30 or less wil show up as critical. 

Hi Tom Tom,

In your case, you still have a critical/longest path, but it consists of the Project Finish Milestone alone.  "Finish on" (FO) essentially combines an early finish (FOA) with a late finish (FOB) constraint.  As long as an FOA is more stringent than the predecessor logic, it effectively breaks the driving path to/through the constrained milestone (i.e. the longest path).  This is always the case. 

Your client's requirements may be aimed at prohibiting an early-completion baseline schedule, and in my view such requiremements are only appropriate if you (i.e. your company) have explicitly agreed that early completion is not planned.  In that case you can meet the requirement by inserting a 30-day "Contractor's schedule buffer" activity between the project finish milestone and its predecessors.  The result is a critica/longest path extending from the data date to the completion milestone.  At each update period you would need to adjust the duration of this buffer activity to ensure that a) the milestone's early finish remains driven by the buffer rather than by the constraint (thereby preserving the longest path), and b) you do not waive any rights to EOT in case of excusable delay.  This is a cludgy and time consuming - maybe the client can limit the requirement to the baseline schedule only, allowing you to remove the buffer and convert to FOB constraint for the monthly updates.

Good luck, tom