All posts tagged float

You are here: Home / Blog / All posts tagged float

Sep

When P6 Late Dates are Early

Categories: Constraints, Late Dates, P3, P6 Professional

Tags: Backwards Pass, Constraints, Early Dates, float, Forward Pass, Late Dates

Comments Off

by Bill Pepoon

Primavera Systems introduced a novel concept when it released Primavera Project Planner in 1983. Having just graduated from university two years earlier with my first CPM Schedule already under my belt, I assumed I understood basic scheduling concepts pretty well. I then spent several years using a proprietary software program owned by the consulting firm that hired me as a scheduler. But when my employer switched to Primavera Project Planner in 1987, well, I learned another approach to CPM Scheduling.

All of my early schedules relied upon a floating project end date. That is to say, the project end date changes depending on progress. Not knowing better, I did not consider that the early dates were not very helpful. On the critical path, the early start/late start dates are identical. Likewise, the early finish/late finish dates are the same. So how do we get back on schedule once there are delays?

Primavera Project Planner (or "P3") allowed constraints to be placed on individual activities or the project overall. This created "hard stops" in the schedule. The late start and late finish dates became fixed dates, more or less (I say "more or less" because progress and logic changes mean that the late dates will often change over the life of the project). But in particular I was intrigued by the idea of the last activity in the schedule being held in place.

Those of you familiar with forward and backward passes understand that the forward pass determines the length of the project - hence the phrase "longest path" that is used in Primavera software in lieu of "critical path". The backwards pass determines the float on each activity. Absent any constraints, the longest path will always exhibit zero days float because both the forward and backward passes generate the same result. For example, what exhibits as Day 70 going forward is also Day 70 working backwards. 70 - 70 = 0.

But on a project that is behind schedule we might see that what is Day 70 going forward is Day 65 working backwards. We have -5 days of float. And we need to reach that point in the schedule by Day 65 if we want to get back on schedule. This assumes of course that we have constrained the last activity in the schedule. In today's Primavera software, "Finish On or Before" is the preferred constraint. If we are on track to finish early, the float will be zero days because the backwards pass starts with the finish date of the last activity in the schedule. When we are behind schedule, the constraint date is the starting point for the backwards pass.

What I really like about "Finish On or Before" is the zero days of float when we are on or ahead of schedule. I have a basic philosophy about projects. You have to plan to finish early in order to finish on time. We might insert a contingency or buffer into the schedule to reinforce this concept, but projects rarely just stay "on" schedule. Subcontractors and vendors see activities with zero days float coming up, which makes those tasks seem very important. The general contractor, and presumably the owner, know otherwise.

One of the biggest criticisms of constraints in general is that they sequester float for the benefit of the general contractor. True, we can create an artificial late start date for any activity by assigning a "Start On or Before" constraint. The general contractor is literally choosing a late start date for the activity irrespective of the longest path. Manipulating the float in this manner is certainly frowned upon, for good reason. The float displayed on an activity should accurately reflect how this task affects other tasks downstream.

Unfortunately, some owners fail to appreciate the nuances of constraints and instead restrict their use altogether. Yes, we can compare the current project finish date to the date in the previous schedule, but that is a cursory examination that does not address where we need to be in the next few weeks. We may have dozens of activities that are behind, some more than others. The worst of the worst need to be addressed first, what I think of as a "whack a mole" game where negative float is being hammered.

But I am not advocating unrestricted use of constraints. A question I present during my advanced P6 training classes is based on the following observation:

"An activity has just one predecessor but it is not a driving predecessor. How is that possible?"

Under normal circumstances there must be at least one predecessor task that drives the start or finish date of the next activity. Otherwise, what exactly is driving the successor? Granted, it could be affected by resource-levelling or mismatched calendars. But the most common explanation is that the successor is being driven by a constraint. This can break the critical path so that the path now starts with the constrained activity.

We speak of the critical path as being a contiguous, or unbroken, string of activities from the current Data Date to the end date of the project. The only nonwork days would be those defined by the activity calendars. Therefore, we must make progress along the critical path each and every work day. The critical path is a difficult taskmaster, as it should be.

A few years ago an engineering firm in the (San Francisco) Bay Area asked me to meet with them to review one of their schedules. "We can't find the critical path", they told me over the phone. Hmm. That sounded like a challenge. How on earth can the critical path be all that difficult to locate? But I did not need to know much about their schedule to presume that too many constraints were being used.

Now, you might have a different definition of "too many" but I think we can all agree that 150 constraints in a schedule is a bit much. So I patiently explained why 99% of them were not necessary. The engineers refused to trust the logic, or fix it for that matter. A typical example was a predecessor with a Friday finish constraint followed by a successor with a Monday start constraint. Um. Finish to Start relationship?

On nearly any project I can live with just the "Finish On or Before" constraint, placed on the last activity. Any other constraint should be justified by a contractual requirement, such as an intermediate milestone that can generate liquidated damages. There are often quite a few milestones in a CPM Schedule but I am only interested in constraining the ones that cause pain for the contractor. We don't want to miss those dates.

The U.S. Army Corps of Engineers probably reviews more CPM Schedules than any other agency in the United States. So it seems rather safe to say that the USACE understand software settings as well as anyone. The USACE require two constraints on each project: a "Start On" constraint on the first activity, and a "Finish On or Before" constraint on the last activity. Additional constraints require approval.

Now, I personally don't feel that a start constraint is necessary on the first activity if the Data Date matches the start date of the project, so I could live with one constraint, on the last activity. But since I am using the start constraint I will move the Data Date up a couple of weeks so that the start milestone is not obscured by the Data Date line. It just looks better.

So, to wrap this up, when the project end date is constrained, activities that are behind schedule flip the script when it comes to dates. The late dates are earlier than the early dates. I spent quite a lot of time explaining this to doubtful contractors and owners back in the 1980s. Surely the software is broken! But the logic is sound. The late dates, being constrained by the last activity, are indicative of how to get back "on" schedule. Following the early dates would be a mistake, as they would maintain the status quo.

This scenario introduces the inverted cash flow curve, which I always find interesting. In the graphic below you can see the late curve rises above the early curve:

Based on everything I have discussed, these curves make perfect sense. We need to perform more work than required by the "early" dates. Otherwise, we finish late. Which means we also need to display the late dates to avoid landing on the "early" curve and therefore finishing late. Yet it still confuses people nearly forty years after I issued my first schedule with negative float.

Feb

Who Owns the Float?

Categories: Total Float

Tags: float, Lag, Project Schedule, Relationships

Comments Off

by Bill Pepoon

Arguments over who owns the float in the project schedule are common. But unless the contract documents state otherwise, float belongs to whichever party that uses it first. This fact makes no one in particular happy, but a very smart lawyer once told me that the perfect settlement is the one that both parties regret the next day.

Sharing the float is a fair solution, although there will always be times when it seems rather inequitable. The contractor waits until the last possible moment to submit a shop drawing; now the architect is under pressure to return the shop drawing in a timely fashion. The contractor ate the float, making the review critical. But at one time this path had plenty of float. The architect is not happy being put on the spot.

Conversely, the contractor submits the shop drawing very early, but the architect sits on the shop drawing for such a long time that all the float is gone. Now the contractor has no leeway in terms of procuring the materials. Any hiccups during fabrication and delivery will mean the contractor is blamed for the delay, yet he tried so hard to stay ahead of schedule.

As a construction consultant I am caught in the middle. My contractor clients want to own the float, and so do my owner clients. Making people unhappy seems to be part of my job. Nevertheless, it is universally recognized that float belongs to the project. Either party can utilize the float while it is still up for grabs.

There is one brief period of time, however, when only the contractor owns the float. He alone decides how much float each and every activity has in the project schedule. So when is this magic moment? It is quite simple: until the original plan is published the contractor has complete control over the float. Pity then that so many contractors squander the opportunity.

The contract documents clearly give the contractor ownership of means and methods. Certainly there may be some specified sequences in the contract documents (such as for project closeout) but otherwise the contractor decides how to build the project. And this means the contractor controls the float in the original plan. He overlaps work that he feels like overlapping, or makes the work more linear because he wants to conserve resources.

In my experience roughly one-half of all activity relationships in a project schedule are discretionary. We sometimes call these “soft” relationships because the work could be sequenced more than one way. Mandatory (or “hard”) relationships, on the other hand, cannot be violated. The wall has to be built before it can be painted, for example.

When the owner reviews a project schedule only the mandatory relationships can be verified easily. The other half of all the relationships are harder to discern. Why is the contractor starting brick work on the east elevation? Does feeder conduit have to start before branch conduit? But as long as the sequence represents what the contractor intends to follow, the owner has no valid objection. It is what it is.

As with any subject there are a few caveats. I have seen some pretty strange restrictions in contract documents that do affect how logic – and therefore float – can be applied. On one of my projects there was a restriction on what percentage of activity relationships could be Finish-to-Start. Yet on another project I was instructed to use only Finish-to-Start relationships. As a master scheduler I rather resent anyone telling me how to use my tools.

Otherwise, the contractor has so many opportunities to reduce the float in the schedule. Nothing can be considered unreasonable unless it is completely unrealistic. Pour the sidewalks next to the building before starting light poles in the parking lot? Why not? Whether the same trade is involved is immaterial. It is all about hitting dates that make the contractor happy. Besides which, owners often question why activities do not start on their early start dates regardless of the available float.

There is one loophole to consider. The owner and the contractor agree to share the float, per the contract documents. This does not preclude the contractor from crafting language in his agreements with subcontractors to restrict the use of float. In other words, the contractor only has to share the float with the owner. He is not obligated to share float with subcontractors.

Starting with my first scheduling position in 1983 I was told to monitor excessive float. In some cases it is a sign of bad logic. I either had the wrong predecessor (thereby starting too early) or the wrong successor, which allowed the activity to finish late in the project. If I thought the start date was too early I would go shopping for another predecessor that was finishing later than the current predecessor. Similarly, I might look for another successor that starts earlier than the current successor.

Some of you might think this is dishonest, that I am hiding float that otherwise should be there. No, quite the opposite. I am concerned that the float is unrealistic. Who in their right mind would say to a subcontractor, “you can show up as early as March 2nd or as late as September 15th”? Such a range of dates implies uncertainty. I suspect that Primavera P6 introduced two new date columns – Start and Finish – to avoid the confusion of early versus late. Hardly anyone other than experienced schedulers truly understands the concept of float. Trust me.

So we are not “sequestering” float, which is perhaps a nicer term for hiding it. Moreover, I am not a fan of using activity constraints to reduce the float on an activity. Excessive constraints are the bane of my existence. I once spent an afternoon with a client explaining why he needed to get rid of all 150 constraints in his 175-activity schedule. He had originally contacted me because he could not find the critical path. Duh!

When I conduct my final review of the project schedule I consider whether the activities on the critical path make sense. Contract documents sometimes restrict the percentage of activities that can be on the critical path (hint: add more non-critical activities such as submittals if you have too many critical activities). But I must also consider whether activities on secondary paths have too much float. Yin Yang.

There is certainly no worse feeling than a project schedule that seems to suck up all delays due to excessive float. We should not be sharing float that does not really exist. Once the schedule is published it is simply too late to rectify this problem. The float now belongs to the project.

Dec

What Dollar General Tells Us About Planning

Categories: Critical Path, Planning, Total Float

Tags: CPM schedule, Critical Path, float, Planning, Resources

Comments Off

by Bill Pepoon

Those of you living in the United States are probably familiar with Dollar General stores. Mostly found in small towns, Dollar General stores sell a wide-variety of lower-priced items. But there is big money in this market. Dollar General currently has 14,000 stores pulling in $22 Billion a year. The CEO of Dollar General, John Vasos, received a lot of press recently on comments he made to the Wall Street Journal that caught my attention as well.

Most commentators seized upon Mr. Vasos’ comments that the U.S. economy was creating more of what they consider to be their core customer – someone making less than $40,000 a year. Dollar General is planning to build thousands of new stores and is moving into metropolitan areas that were not previously identified as their demographic (i.e. the arrive of a Dollar General store in some communities could be considered a backhanded compliment.)

There has certainly been a lot of debate in this country about the percentage of Americans who are unemployed or underemployed (working fewer hours than desired) and how to solve this problem. The disappearance of good paying manufacturing jobs has resulted in many individuals working somewhere else, but for a lot less money. The new job is also far less likely to offer a pension.

Dollar General and other similar “dollar” stores thrive by selling small quantities of items to lower-income households at prices they can afford. These households do not buy in bulk even though it would result in savings. Hence, they are more likely to run out of something and need a replacement quickly. I can buy a 32-pack of bottled water for about the price of three individual bottles at my favorite store so clearly buying in bulk makes a big difference.

But here is the quote by Mr. Vasos that really caught my attention. He was describing Dollar General’s typical customer:

“Doesn’t look at her pantry or her refrigerator and say, ‘You know, I’m going to be out of ketchup in the next few days. I’m going to order a few bottles.’ The core customer uses the last bit of ketchup at the table the night prior, and either on her way to work or on her way home picks up one bottle.”

In other words, the typical Dollar General customer is not a planner. They wait until they are out of something before they buy more. They overpay without thinking. This is not how we manage projects. We do not (CAN NOT) let ourselves run out of resources needed to complete a project. That would be an inexcusable delay. We figure out what we need and make sure sufficient quantities are on hand when it is needed.

The critical path of the project in particular is a difficult taskmaster. We must complete the amount of work we planned each and every work day. It is not good enough to complete tasks totaling 19 days during a 20-day work period. That puts us one day behind schedule. The critical path keeps us honest. I see a lot of arguments at the end of the month when the final tally is taken. “But we did so much work this month”, they will invariably say. “Not enough”, I will reply.

It takes a different mentality to be a planner. We have deadlines based on expectations of quality and scope of work. A bad plan leaves us uncertain as to where we should be at any given time. Every day is a deadline of sorts, because what we did not finish today becomes something else that must happen tomorrow. Granted, we have some leeway with non-critical activities but a recurring problem that I see on many projects is that the amount of float on a secondary task is exaggerated, thereby diminishing its importance. We reap what we schedule.

Planning is all about opportunity. We have many options during the planning stage. Some options are more attractive or feasible, and hopefully the least-expensive option generates the best result. But it can certainly be more complicated than that. The California Department of Transportation (Caltrans) utilizes an “A + B” approach on larger projects: each bidder must specify a contract duration and a price. Both numbers are considered when awarding projects. Caltrans’ experience is that A + B bids result in lower prices and fewer road usage delays.

The longer we wait to make decisions the fewer options that remain. Projects finish on time because we monitor our progress on a regular basis and implement mitigation strategies whenever slippage does occur. We do not use up float for bad reasons but rather to give ourselves flexibility. We do not allow ourselves to run out of ketchup.

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!