4 Easy Ways to Show the Critical Path in P6

1. Check the Gantt Chart

By default, the P6 Gantt chart will show your project’s Critical Path activities in bright red. This makes it easy to have a quick glance at the Gantt Chart et voila!, your Critical Path stands-out like a safety vest.

Hey! It’s not working! I don’t see any red Critical Path activities on my project. What gives?

Glad you asked.   Maybe your Gantt chart looks like this instead.

Primavera P6, by default, uses Total Float to decide if an Activity is Critical or not. Activities with a Total Float value of 0 (or less) usually show red on the Gantt. If you have no red Activities, you may have a Must Finish By date set on your project. If your project is finishing earlier than the Must Finish By deadline, then you may not have any activities with 0 or less Float values which means there are no Critical activities.

If that’s the case, tell P6 to show Critical Path by the Longest Path rather than by Total Float.

1. Press F9, and then click the Options button.

2. Find the setting “Define Critical Activities as”. Choose Longest Path.

3. Reschedule your Project.

4. Notice the Gantt chart now. You should see a red Critical Path now.

You can always read more about the Critical Path vs Longest Path.

2. Use the Critical Path / Longest Path Columns

Edit your columns and go digging for one called “Critcal” and another called “Longest Path”. Add one or both of these nifty columns to your Activity Layout to show clearly which activities are Critical.

3. Turn On a Filter

Using a Filter can also be a quick and effective way to manifest your Critical Path. Click the Filters button to turn on the Critical Path filter. This will show only the Critical Activities. There’s also a filter for the Longest Path.

4. Check the Schedule Log

Lastly, you can always check the P6 Schedule Log.  The Schedule Log is a log file that gets updated every time your project is scheduled. Press F9 and make sure the box labeled “Log to File” is checked on. Then, click the “View Log”button to open the Schedule Log.

Once you have the log file open in Notepad, you’ll have to scroll down to the section labeled “Exceptions”. But you should see in the log a list of your project’s Critical Activities.

See in Plannertuts.

Scheduling Best Practice Conundrums

by TheCobraGuy

The following are top tips from professional schedulers that will help keep your project on track:

There are some common mistakes made during the creation of project schedules, particularly by folks who are new to the art. In this article I’ll be pointing out a few of the most frequent scheduling faux pas that we encounter out in the field, and talk about common best practice guidelines and the dilemmas that these can throw at schedulers working in the real world.

I’m focusing on following guidelines that are common to many publications including Unified Facilities Guide Specifications (UFGS) and the PMI’s Project Management Body of knowledge (PMBOK).

1. Avoid Open-ended Logic.

2. Use as few constraints as possible.

3. Keep activity durations below 45 days unless they are Level of Effort (LOE) type tasks.

One problem I’m always wrestling with when it comes to using best practice guideline, is that they often seem to be contradictory. Following one guideline seems to cause you to have to ignore another. The following is an example of a best practice guideline that will get you into a dilemma.

Open-ended Logic

Various guidelines say to avoid open-ended logic activities that have no successors. This seems to be the most common issue I see in schedules, whereby an activity that has no successor and is just left dangling at the end of a chain of predecessors. If I ask the scheduler about it, the answer is invariably the same: “There are no other activities dependent on that activity, so there’s no successor”. In real-world terms, that actually makes a lot of sense; if there’s nothing dependent upon its completion, then there’s no dependency to illustrate.

However, best practice is to not have such dangling activities in the network. Doing so drops the activity out of the critical path and generates an unusually large Total Float value. Arguably you could say that if it’s in the scope of the project, at some point it’s going to impact the completion of the project, so if nothing else, make the project finish milestone its successor.

However on longer projects, this could really push the boundaries of acceptable Total Float limits; especially if the activity is early in the project life-cycle. And here’s where we start running into some guideline conundrums. The obvious solution is to add a constraint date to the end of the dangling activity. However, this can appear to be in conflict with the following general guideline:

Limit the use of Activity Constraints

Generally speaking the term “Constraint” doesn’t necessarily refer to the special Start or Finish date attributes that can be added to activities in most scheduling software tools. The term “constraint” can mean a relationship between two activities, the constraint being physical: i.e. the roof cannot be built until the walls are completed. It can also refer to a condition in a contract where a crucial delivery date is specified. This is referred to as an external constraint. However for our purposes, I am referring to constraints that can be added as special date attributes to activities in a software tool; dates that will influence the calculation of the critical path.

Many of the published guidelines recommend very limited use of activity constraints in a project schedule, that is: hard dates that are added to activities that will lock down the early and/or late dates.

If the dangling activity (or chain of dangling activities) delivers a major contract milestone, then the use of a hard constraint date is appropriate. This will reduce the overall float of the dangling activity. For greater schedule clarity, a Milestone should be added as a successor to the dangling activity and the constraint applied to it. Depending on how close the constraint date is to the current scheduled dates, this option will reduce or remove the Total Float for the open-ended chain. And if the scheduled date is already later than the constraint date, negative Float will be calculated indicating that you already can’t meet that contractual date and changes to the plan are required.

In the following example, we’ve added a contract deliverable milestone to the back of activity “G’ and then applied a hard Finish On constraint date. The constraint date is 3 days past the scheduled finish date for the activity, so we have 3 days of Total Float, rather than the 21 days we had before introducing the constraint.  We could still link the Contract Complete Milestone date to the Finish milestone, but if I slipped that badly as to push out the project end date, we’re in trouble anyway.  We could add a long lag between the new milestone and Finish milestone, but some guidelines also discourage the use of long lags and leads.  What you finally do will be a judgment call in the end, based upon the particulars of the actual work being modeled.

The guidelines that discourage the use of constraints are sound because too many constraints will mask the true critical path. It makes it harder to differentiate between activities on the critical path and constrained activities. I’ve seen schedules littered with constraints and it was nearly impossible to see the true critical path. Also it can potentially create bucket-loads of negative float, never a good thing. If the customer is schedule savvy, they will think that the dates cannot be met and constraints have been used to artificially paint a happy, but horribly unrealistic picture of workflow; underpinned by an inability to meet the goals of the project.

In short, only use constraints when you have a very good reason to do so. And even then use constraint types such as Start on or After or Finish On or Before type (soft constraints), that will still allow the schedule to shift in at least one direction if needs be.

Keep activity durations below ‘n’ days

I’ve seen this guideline in various publications with differing duration limits depending on the types of projects being scheduled. Of course such ongoing activities as Management, Safety, Security and so on may run the entire length of the project, but these are normally created as some kind of hammock: that is a task whose duration is dependent on activities to which it is linked.

Above: activity A1005 is a Level of Effort activity

Any activity that doesn’t create a deliverable can be of virtually any length; however discrete work packages that describe a particular package of work should be kept to a reasonable length. A common maximum length is to keep activity durations below three months. When the activity is longer than this, it suggests it’s functioning as more of a summary activity, and it probably represents many operations that could be broken down to smaller packets of work.

Figuring out the right level at which to break out the work and estimating the durations for activities can be a conundrum all of its own. There are various guidelines that discuss formal methods for doing this, such as Expert Judgment, Analogous Estimating and Parametric Estimating. Nevertheless, because the work can always be performed in more than one way, getting the activities at just the right level and duration for your particular project is always a challenge.

When creating your activity list, one tip is to keep in mind how the work’s status will be recorded. If the activity’s description covers more than one discrete step of the work, it will be difficult to track and apply status. For example you may have an activity named “Build Foundations”. For a small project, this makes sense as a single task because the entire operation may only take a couple of days. However if this is a larger building where the foundation takes a few weeks to complete, then it will need to be broken out into more discrete packages, such as “Dig footings”, “Wire Rebar”, “Build and Set Forms”, “Pour Concrete” and so on. With each of the activities being a few days long, status will be more discrete. The footings have been dug so that task is 100% done. If the activity was just called “Build Foundation”, and was 5 weeks long, what percentage of the activity is complete when the footings are done? So think about the need for accurate updating of status when you are considering the level of detail at which to create the activity as this often helps in estimating the durations too.

Summary

In the end, all guidelines are designed to give you the optimum way of achieving a viable schedule. They are guidelines and not hard and fast rules precisely because every schedule has unique challenges to overcome. As schedulers, dealing with the day-to-day challenges of putting together a viable schedule, being given guidelines can be a prickly subject, particularly when you know you’ll have to ignore some of them in order to make the schedule reflect the reality it is attempting to model. When challenged about scheduling guidelines I simply say this; “if you can defend it, and there was no better way to do it, then just do it”, even if you’ve had to ignore a guideline or two to make it happen.

Primavera P6: Critical, or not so Critical?

by TenSix

Many scheduling guidelines including the PMI’s PMBOK (Project Management Body of Knowledge) use the term “near critical’ to describe activities in a schedule that are within a few days of joining the critical path; that is to say they only have a few days of Total Float.

Because Primavera P6 Professional has such a flexible method for defining how activity bars appear in a Gantt chart, you can create extra bars whose appearance can be controlled by the amount of Total Float they have. This allows you to easily see near critical activities in a Gantt chart.

This blog shows you how to create activity bars that appear different to standard red, blue and green bars when the activity is near critical.

The process of creating a near critical bar starts with the creation of a Filter. This filter is then used by an additional bar that you define in the Bars dialog of Primavera P6 Professional.

Create a Near Critical Filter

Open the Filters dialog and click on the New button.

Create the following filter:

This will show any activity whose Total Float falls within 0.1 days and up to 10.0 days. You should test this filter on your schedule before proceeding to the next step.

Create a Near Critical Activity Bar

The next step is to create a new activity bar style in using the Bars dialog.

Right-click in the Gantt chart area of the Activities view to open the Bars dialog.

In the Bars dialog, scroll down to and select the current Critical Remaining bar in the table area. This will cause a new bar to appear below the selected bar when you click the Add button.

Upon clicking the New button, a new default bar appears on below the selected row. You then need to name this new Bar in the Name column; we suggest “Near Critical”.

In the Timescale column, set the value to “Remain Bar”, and then set the Filter column by selecting both the Normal and Near Critical filters.

Finally set the Bar Style colors and patterns that you want for your near critical bar. In the following example we’ve simply set the bar to an orange color.

Once you apply the new bar to your layout, you can see any near critical activities showing as orange in the Gantt chart.

You can take this a lot further than just near critical. Using the same techniques, you could create filters for ‘Potential Critical’ whereby the activity has between 10 and 30 days total float, or perhaps even super-critical where there is negative float making a darker red bar appear. Of course the different bars we can create based upon some condition are only limited by our imaginations. One of our customers uses different bar colors to indicate a particular activity code setting, to give just one example. Perhaps you have already made use of this capability? If so, drop us a line – we’d love to hear about it.