All posts tagged Activity Relationships

You are here: Home / Blog / All posts tagged Activity Relationships

Jul

Understanding Driving Relationships

Categories: Activity Relationships, Constraints, P6 EPPM, P6 Professional

Tags: Activity Relationships, Critical Path, driving relationships, Gantt Chart, lags, non-driving relationships, TSLD

Comments Off

by Bill Pepoon

Proper scheduling requires an understanding of driving relationships. These are the most important relationships in the schedule because they drive the start and finish dates of the activities that follow. So it stands to reason that all critical path relationships are driving. In Primavera P6, driving relationships appear on the Gantt Chart as solid lines: red for critical path and black for non-critical activities. When “crashing” the schedule we must focus on driving relationships in order to move up the start dates of critical path activities, thereby shortening the project duration.

Now, if every activity had only one predecessor we could ignore talking about the counterpart to driving relationships: the non-driving relationships. After all, if there is only one person in front of you performing a task, how could they not be driving your work? Well, there is one possible exception. Activity constraints can, in some situations, drive activity dates. For example, if the successor wants to start on August 3rd because the predecessor finishes the day before (i.e. the classic Finish-to-Start relationship) adding an activity constraint that pushes back the start date means that the constraint is driving, not the predecessor.

Finish-to-Start relationships make it easy to separate driving from non-driving relationships. If Activity C is waiting for both Activity A and Activity B to finish, whichever predecessor finishes last is the driving relationship. (I am assuming that both relationships have zero lag, but it is considered bad form to use any lag other than zero days with Finish-to-Start relationships). Where it gets more interesting is when the predecessor relationships are Start-to-Start and Finish-to-Finish. So here is my favorite example from our P6 102 class:

The predecessor has a duration of 20 days
The successor has a duration of 15 days
There are two predecessor relationships coming from the same activity
One of the predecessor relationships is Start-to-Start with a lag of 8 days
The other predecessor relationship is Finish-to-Finish with a lag of 5 days

Which predecessor relationship is driving?

Keep in mind there is only one predecessor activity, but there are two relationships. I will always add a Finish-to-Finish relationship to a Start-to-Start relationship. It is my insurance policy. I doubt that most Primavera users realize that if you only have a Start-to-Start relationship, the predecessor can finish on the last day of the project without causing a delay. For this reason I consider the Start-to-Start relationship by itself to be an open end – even though technically the predecessor does have a successor.

To be clear, “open end” refers to an an activity that is missing a predecessor or successor. The Schedule Log will display activities that are missing predecessors or successors under the “Warnings” section.

Non-driving relationships appear as dotted lines on the Gantt Chart. Pro tip: the Time-Scaled Logic Diagram (TSLD) in Visualizer (Tools > Visualizer) allows users to choose different colors and line styles for driving and non-driving relationships. There is also the option to show only driving relationships. TSLD also has the unusual feature of placing more than one bar on the same row if the bars do not overlap. This reduces the number of rows in the printout substantially.

Getting back to my earlier question, the Finish-to-Finish relationship is the driving relationship, and the Start-to-Start relationship is non-driving. Here is a visual representation:

Note that all durations are in calendar days to make the ordinal days and working days match.

Let’s take a look at the math. The successor is scheduled to start 8 days after its predecessor. The successor has a duration of 15 days. So the successor finishes on day 23 (8 + 15) when only this relationship is considered. But the successor is also supposed to finish 5 days after its predecessor, and the predecessor has a duration of 20 days. As a result, the successor now finishes on day 25 (5 + 20). The Finish-to-Finish relationship adds two more days to the sequence between these activities.

We should also realize that the successor cannot start 8 days after its predecessor because the Finish-to-Finish relationship is dragging the successor by its tail. P6 has a dilemma. The successor’s 15 day duration must be contiguous (other than on specified non-work days according to the calendar). In order to meet both the Start-to-Start and the Finish-to-Finish requirements, the successor would need to be two days longer. In which case both relationships would be driving.

The original Primavera scheduling program, P3, had an option to allow non-contiguous durations. P3 would “stretch” the successor so that both relationships could be fulfilled. But the displayed duration of the successor would not change. I suppose this did confuse some people because the length of the activity bar was occasionally quite exaggerated compared to the displayed duration. P6 dropped this feature, perhaps for good reasons. We must now recognize that not all of our specified conditions can always be met.

Driving and non-driving relationships can also be identified in the Activity Details at the bottom of the Activities window. Select the Predecessors, Successors or Relationships tabs. The columns shown in these tabs can be customized to show the Driving box, which is found in the General category of columns. I always display this box. The example I provided is rather simple because there is only one predecessor activity. Imagine if there are several predecessors starting on different dates and more than one relationship type!

Schedules can get very complex rather quickly because of the available relationship types. Ah, the old days when all relationships types were Finish-to-Start, things were rather simple. What we called the “I-J” or “Activity-on-Arrow” method of scheduling basically disappeared in the mid-1990s. But I am still a big fan of Finish-to-Start relationships because they are the most conservative relationships. I try to make about 80% of my relationships Finish-to-Start.

Keep in mind that as logic and durations are revised, what used to be driving may now be non-driving, or vice versa. Schedules are never static. Out-of-sequence work can also create new situations not previously anticipated. Similarly, new activities representing scope changes or unexpected events can alter the importance of relationships. But ultimately, if the start date of a task just seems wrong, driving relationships must be analyzed first. Don’t let the non-driving relationships become a distraction.

Aug

The Pit Stop Relationship

Categories: Activity Relationships, P6 EPPM, P6 Professional, P6 Tricks

Tags: Activity Relationships, Constraints, float, Primavera Contractor, Primavera P6

Comments Off

by Bill Pepoon

During our advanced Primavera P6 classes I like to tease my students with the “weirdo” activity relationship and challenge them to find a practical situation for applying it. This relationship type is not available in scheduling programs like Microsoft Project so most of my students have never seen it before.

I am talking about the Start to Finish relationship, whereby the predecessor must start before the successor can finish. Unless a very large lag is used, the successor will start before the predecessors starts. Think about that for a moment. The successor starts first! The following illustration will make that statement rather obvious:

The predecessor (yellow bar) starts on the same day that its successor (green bar) finishes. If we add a lag duration the yellow bar will start before its successor finishes, so they will overlap. For example, a one-day lag would cause the predecessor to start the day before the successor finishes.

Well, you can probably see why we do not unleash this relationship type on beginners!

Other than showing off, one might wonder why the Start to Finish relationship is used at all. My favorite example is the pit crew that services a race car. The pit crew is the predecessor to the car arriving in the pits (the successor).

No, that is not a typo. I am saying the pit crew is the predecessor. Put another way, the race car is not supposed to pull into the pit lane until the pit crew is ready. The pit crew is therefore logically the predecessor because they, not the car, must be ready first.

At this point I am sure you are thinking, “why not make the race car the predecessor to the pit crew and use a Finish to Start relationship?” The issue is that we do not want the car to arrive early. So it is logical to say that the successor’s start date should determine the predecessor’s finish date. Hence, Start to Finish.

While I wish that race teams used Primavera software (official scheduler for Ferrari would be a very cool job) the reality is that one of my clients was already using this relationship type before taking my class. They work at a nuclear submarine facility on the East Coast. Similar to my example, they do not want the sub to show up until they are ready to perform maintenance. So maintenance is the predecessor.

The downside to this relationship type is that you can end up with some strange looking float values, as the backwards pass algorithm seems to get confused by what almost seems like reverse logic. We expect relationship lines to always be pointing to the right, after all. Other activities tied to the ones with the Start to Finish relationship can likewise behave rather strangely.

An alternative would be to use a Finish to Start relationship and put an “As Late As Possible” (ALAP) constraint on the predecessor. This way, the race car can be the predecessor but it will not finish until the pit crew is ready. Schedulers often use this constraint to avoid having materials or equipment delivered to the jobsite too early. Sort of like Just In Time manufacturing.

Perhaps it comes down to personal preferences. Some people dislike using Start to Finish relationships and others dislike using constraints. Owners in particular view constraints as an artificial device to sequester float. The contractor is in theory suppressing float on certain activities to keep the owner from using it. Fine, but when the door hardware shows up a year early perhaps they will reconsider!

Personally, I prefer to use the ALAP constraint, albeit with discretion. A side-effect of this particular constraint is that the predecessor(s) will not be driving. This can confuse some people. While other constraints sometimes have the same effect, this always happens with the ALAP constraint.

Try the Start to Finish relationship for yourself and see what happens!

Jun

The Schedule That Can Be Beat

Categories: Activity Relationships, logic, Primavera P6

Tags: Activity Relationships, Critical Path, Finish-to-Start, logic, Longest Path, Primavera Contractor, Primavera P6

Comments Off

by Bill Pepoon

My wife and I recently participated in a group hike to see the new land acquisition by our homeowners association. We own property in a 7,000 acre resort in the Sierras and the new parcel adds several hundred more acres of wilderness that will prevent development near our resort. The problem was, our group leader had told us in no uncertain terms that the last bus back to the resort would be leaving at 5:15 pm. Yet here we were at 4:00 pm still hiking in the wrong direction and realizing we had at least an hour of strenuous hiking uphill to the staging area. So we turned around and headed back. Our group leader was clearly cutting it a little too close.

I feel the same way about scheduling. Yes, there will always be critical activities, but they are of course only critical because other activities are, well, less critical. But if the longest path of activities are themselves quite aggressive then we are only setting ourselves up for failure. So my preference is to have a schedule that can be beat.

I am not talking about sequestering float. You may have heard about strategies to hide float in a schedule. This all started several years ago because nearly all construction contracts in the U.S. state that float belongs to the project and is therefore not for the beneficial use of just one party. The contractor or the owner can use the float, with dibs belonging to whoever grabs it first.

Contractors who felt more entitled to the float began devising ways to hide some of the float by tying activities to unrelated work that starts sooner than the more obvious successors. This removes float from the schedule and makes it more likely that an owner delay to a task will also delay the project. A non-critical activity can quickly become critical because it has very little float. For this reason, the sequestering of float is often prohibited in construction contracts.

In my case, however, I am only trying to avoid being too aggressive with activities that are on the critical path and for this reason I choose the least ambitious type of relationship for the majority of my activities: Finish to Start. My goal is to make roughly 80% of the relationships in my schedule Finish to Start. This percentage can be checked using the DCMA checklist available in P6 Web. DCMA stands for the Defense Contract Management Agency. This checklist – called Check Schedule in P6 Web – can be seen below:

You set up the parameters of the schedule in this menu. Once Check Schedule is run, the results appear in a separate window, seen below:

At a glance I know whether I achieved my goal of making 80% of the activity relationships Finish to Start. Other goals include managing durations and relationship lags. Anything in green is in compliance while red indicates not in compliance with the specified parameters.

My strategy of primarily using Finish-to-Start relationships is a direct result of the early years of CPM scheduling, when Activity-on-Arrow (AOA) was the dominant scheduling technique. In those days, the arrows represented tasks, whereas the nodes (circles in most cases) were the activity identifiers. Because of this technique, each task had two nodes referred to in this order: the I-Node and the J-Node. So you would see something like Activity ID 1000-1005. This technique was also referred to as the Arrow Diagramming Method (ADM).

The Activity-on-Node (AON) method became very popular in the early 1990s and was certainly spurred along by Primavera Systems’ decision to drop Activity-on-Arrow altogether when the first Windows-based version of Primavera Project Planner (P3) was released in 1994. Ignoring this brief history of scheduling software for a moment, consider that if the arrow represented the activity, then all relationships were Finish-to-Start. The J-Node of the predecessor was also the I-Node of the successor. Leads and lags were non-existent. The predecessor(s) always had to be complete before the successor could start. This can be seen in the following Activity-on-Arrow diagram:

We used to split activities into percentages so that, say, the first 25% of drywall hanging could start as soon as 25% of the walls had been framed. This effectively became the lag that we use today with Start-to-Start and Finish-to-Finish relationships. Otherwise, it was fully expected that some work would start out-of-sequence, meaning the successor starts before the predecessor is finished.

By the same token, Finish-to-Start relationships are far more likely to generate out-of-sequence progress in today’s precedence schedules. And my response is “great!” You are beating my schedule! I have set you up for success, not failure. Now, I realize some people are bothered by out-of-sequence progress, but unless there is truly a “bust” in the logic or the result of unexpected delays I see this as a positive sign.

There is another benefit to the Finish-to-Start relationship. It is more likely our resources will not become over-allocated. Older schedulers like myself used logic to limit the number of resources required because the scheduling software was too primitive to do this. We called this type of logic “crew restraints” and I still use this technique today. The resource leveling feature in Primavera P6 is not always the best option for controlling the allocation of resources. And besides, if the schedule is not resource loaded then leveling is not an option.

My attitude often comes down to this: prove to me you can get ahead of my schedule and I will modify the logic accordingly. Until then, my logic assumes a more linear progression of the work and is therefore more forgiving. And everyone will feel better because the project end date does not keep slipping. What could be better than that?

May

Primavera P6 Version 16.1 Released

Categories: Claim Digger, P6 EPPM, P6 Professional, P6 Web, Primavera P6 Client

Tags: Activity Relationships, Claim Digger, Primavera P6 EPPM, Primavera P6 Professional, Visualizer

Comments Off

by Bill Pepoon

Spring is in the air, which means another release of Primavera P6 Professional Project Management (PPM) and Primavera P6 Enterprise Project Portfolio Management (EPPM).

The list of changes to Primavera P6 Professional is short, but sweet. First, after years of begging, Oracle has finally introduced a feature that has long been part of Microsoft Project: the ability to show the relationship type and lag in the Activity Table. Yes! Previously, this information was only available in a tabular Report or by exporting to Microsoft Excel. Now we can finally show this level of detail in a graphical setting. These are new columns called Predecessor Details and Successor Details, as seen below:

Second, Claim Digger has been moved to Visualizer and is now called Schedule Comparison. I suspect this was done to avoid the problem of running Claim Digger with the SQLite database. This type of database does not support third-party applications like Claim Digger, which is an important tool for many Primavera users. Rather than wait for SQLite to change its spots, Oracle apparently decided to take a more proactive stance.

Quite a few enhancements have been added to Primavera P6 EPPM to improve performance and to bring it more into line with Primavera P6 Professional:

Advanced HTML5 Activity and EPS Views
Basic HTML5 Resource Assignment View
Additional copy project options
Daily Timescale in Team Usage View
Additional Global Search & Replace functionality
Streamlined installation and management of the P6 Pro application with the removal of JRE

One of the new copy project options is the ability to copy projects that are linked to other projects but not copy those (external) relationships. Previously, we could only choose to not copy external relationships when copying one or more activities. Now this option can be applied to the entire project.

HTML5 pages load faster than the Java-based applets that were originally used in Primavera P6 EPPM and do not require plugins. The HTML5-based pages are referred to as Basic View, but users have the option of viewing the Java-based pages in Classic View.

Relationship types and lags can also be shown in the Activity Table in Primavera P6 EPPM.

Additional information regarding these enhancements can be found here. In addition, Oracle has created a very nifty app called the Cumulative Feature Overview Tool. It is sort of like Claim Digger for analyzing different versions of Primavera P6. You input which version you are currently using and the tool will tell you what features have been added since then, and when the changes were introduced. Click here to access the Cumulative Feature Overview Tool.