Expert, flexible training in the use of the most powerful scheduling software program in the world: Primavera P6 by Oracle. Call today! (916) 779-4145
Primavera Scheduling

All posts tagged Primavera Contractor

The Pit Stop Relationship

Categories: Activity Relationships, P6 EPPM, P6 Professional, P6 Tricks
Comments Off on The Pit Stop Relationship

Primavera SchedulingDuring 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!


Primavera SchedulingA simple word – certification – can create so much confusion. Nearly every day we are asked about this word. How do I become certified on Primavera P6? Or how do I become a certified Primavera P6 scheduler or trainer?

Let’s start with the highest level of certification: Oracle University. Yes, there really is an Oracle University. In order to sell Oracle software a company must become an Oracle Partner (which involves a lot of paperwork and payment of fees) and get a certain number of employees certified on the Oracle programs the company wants to sell. Oracle offers Guided Learning Paths (GLPs) to help its partners prepare for these certifications.

In order to view the GLPs, however, you must have access to the Oracle Partner Network. In other words, individuals who do not work for an Oracle Partner cannot review the training materials. The GLPs cover a lot more than just the software itself, so it is vital to access to this training. Moreover, this trainer is geared towards implementing software solutions in various industries, which goes beyond what most schedulers would be expected to understand.

The next step is to take a proctored exam. By “proctored” we mean an exam observed by a third party. Oracle offers some exams during OpenWorld in San Francisco (an annual event for Oracle Partners, programmers and devotees) but there are computer learning centers around the country who offer the same exams on a more frequent basis. A passing score is 70%.

Passing this exam (1Z0-535) establishes someone as a Primavera P6 Enterprise Project Portfolio Management 8 Certified Implementation Specialist. If you are wondering, the “8” refers to Release 8 of P6 EPPM. Oracle has not changed the certification process even though we are now up to Release 17.7 as of July 2017.


You can view my certificate here.


Wait a minute! What about Primavera P6 Professional and Primavera Contractor? Well, Oracle does not offer separate certifications for those programs. But the reality is that P6 EPPM is by far the most difficult version of Primavera to learn and there are many features common to all three programs.

In addition, there is a desktop component of P6 EPPM that is identical to P6 Professional with one exception; the Admin menu is missing. Administrators are required to use the web component. But this also means that users who understand P6 Professional understand P6 EPPM to some extent, and vice versa. No one other than the administrators are required to use the web component and most schedulers prefer the desktop component. 

I can promise you that just understanding Primavera P6 is not enough to pass this exam. There are questions related to the target markets for this software and how to implement various solutions. Companies who sell Oracle software are expected to be able to demonstrate why this software is the right solution. As you might imagine, P6 EPPM is the solution favored by Oracle.

In a nutshell, this is what it means to be “Oracle Certified”. Not all trainers are certified, and it should be rather obvious by now why firms that are not Oracle Partners are unlikely to have trainers who are certified by Oracle University. Being certified by Oracle University implies a pretty serious commitment to teaching Primavera P6. Oracle Partners also have access to resources unavailable to anyone else.

The next level of certification is by an Oracle Partner. While this may not sound as prestigious as being certified by Oracle University, the ultimate goal for non-trainers should be to learn the program, right? We are aware that job postings sometimes specify that applicants must be “certified” yet it is unlikely that the company posting the ad really understands the certification process. 

Certification by an Oracle Partner will vary depending on the class. For example, our online classes are either 8 or 16 hours of instruction, while our in-person classes are 8, 16 or 24 hours. Each class has its own certification. We also offer certification via our On Demand Primavera P6 Training. When someone asks us which class to take, we try to understand what their job function requires. We offer a variety of classes to accommodate everyone’s needs.

The fact is that we have certified more than 2,500 people and not one of them has been turned down for a job because they lacked the correct certification. Each certificate we issue includes our Oracle Partner logo, and these companies know they can call us to discuss our curriculum. We want our students to succeed and we want companies to accept our imprimatur.

Perhaps more importantly, the employers we talk to overwhelming support training provided by an Oracle Partner. They appreciate that Oracle Partners are accredited by Oracle University and maintain a formal business relationship with Oracle. Moreover, only Oracle Partners can offer software sales and training. Oracle Partners are the most qualified to recommend the right solutions.

Some companies are looking for certified trainers to teach other employees – someone often referred to as the Subject Matter Expert (SME). These individuals most certainly need to be certified by at least an Oracle Partner given their additional responsibilities. After all, they are setting the standards for the entire organization. Oracle Partners work with companies in many industries and understand the proper procedures for each.

Several people who have taken our classes were initially trained by non-accredited instructors at companies not affiliated with Oracle and learned that their prospective employers would not accept their certifications. Those classes might have been cheaper, but in the long run these people end up paying a lot more to get the proper certification. And keep in mind that just because the instructor knows more about Primavera P6 than you do does not make them an expert.

Of course, real-world experience is important as well. Our company has prepared more than 600 initial schedules and more than 10,000 periodic updates. Each of our instructors has at least 25 years of experience in project management. We are in fact often asked to teach Primavera courses offered by other training firms because they recognize that our level of experience is unrivaled.

Yes, you read that correctly: some of our competitors are willing to pay us to teach their classes!

A couple of years ago a gentlemen contacted our firm and said he already knew Primavera P6 very well and therefore did not want to take a class. Instead, he wanted to buy a certificate from our firm! Needless to say, we declined. We have had our share of “experts” who did not understand the program all that well.

Any questions? Hopefully not, but let us know!

 


Primavera SchedulingDuring our training sessions in Kansas City this summer I was describing how Primavera users approach status updates differently than many Microsoft Project users. Primavera P6 users will change the Data Date when updating the project schedule to match the cutoff date of progress. So a Data Date of November 1, 2016 means that we have considered all progress up to November 1, 2016. (The default time for the Data Date in Primavera is 12:00 am so normally we do not include any progress on the Data Date; I will explain how to change the default time in another post).

In Microsoft Project there is the Status Date, which functions like our Data Date. But inexplicably, many Microsoft Project users never change the Status Date when updating the schedule. I realize I am using a bit of a broad brush here, but I have personally reviewed many Microsoft Project schedules where I was not able to determine the cutoff date of progress very easily because the Status Date was still set to the day the project started. I end up searching for the latest actual date in the update to approximate what must be the Status Date.

The end result of not moving the Status Date in Microsoft Project is that activities will have planned start and finish dates that are in the past. A nominal November 1, 2016 update will show activities starting and finishing before that date. That would be a mean feat unless one has a time machine! Now, I suspect that many Microsoft Project users are self-taught and the program is easier to learn than Primavera P6 or Primavera Contractor. So it is possible that many Microsoft Project users simply lack the formal training to apply the tool correctly.

One reason for the confusion might be Microsoft Project’s insistence on displaying the day you open the file as the Status Date. Granted, until progress is applied to the schedule nothing happens to the planned dates, but making the Status Date appear to be fluid is not a good idea. And I suspect many Microsoft Project users are not changing the Status Date because they think the date has already changed; it has, but until the schedule is calculated this date is meaningless. This is why the true Status Date is often the project start date.

If everything went according to plan, we could get away with not moving the Status Date. But that has not been my experience for the past 29 years that I have worked as a scheduler in the construction industry. Field Marshall Helmuth von Moltke famously said, “no plan survives contact with the enemy.” Battles and projects are both unique endeavors where anything can happen. Work often does not start according to the planned dates, takes longer to complete, or is performed out-of-sequence. Moving the Data Date is the only thing that keeps the schedule honest.

When I started my career as a professional scheduler I would often sit down with my clients and mark up the large (30″ x 42″) hand-drawn logic diagrams and tell them, “here are the activities on the critical path; it has been four weeks since I was last here, so you need to give me four weeks’ worth of progress along this path.” My clients would sometimes think I was being a bit harsh, but I knew what would happen when I changed the Data Date. The work not performed gets shoved to the right.

Temporary procrastination does not always cause an immediate impact to project completion, however. Activities that are ready to start but not currently on the critical path may still have enough Total Float to wait until the next schedule update. My favorite way to track these lagging, non-critical tasks is the Schedule Performance Index (SPI). The SPI compares planned progress in the baseline schedule to the actual progress in the current schedule, expressed as follows:

SPI = Performance Percent Complete ÷ Schedule Percent Complete

Performance Percent Complete sounds mysterious, but normally it is the same as Activity Percent Complete. You can check this setting under Admin > Admin Preferences > Earned Value. Schedule Percent Complete is merely the progress expected per the Project Baseline, whatever that might be. It is important to check which schedule is assigned as the Project Baseline since it may have been changed recently.

Because Performance Percent Complete is the numerator in the above equation an SPI of 1.00 or greater means that more work has been performed than expected. This is also quite hard to achieve, since SPI is based on the early dates in the schedule. So not starting a non-critical activity as early as possible hurts SPI just as much as starting a critical path activity late. For this reason I usually run SPIs filtered by: (1) all activities, (2) critical path, and (3) non-critical activities for comparison.

An SPI of 0.80 would tell us that we failed to complete 20% of the work scheduled for the current update period. Early in a project the SPI may not look so great, but the closer we get to the end of the project the SPI has to improve if we have any chance of finishing on schedule. The baseline can be the previous update and still be valid in some situations. We may have deviated so much from the original plan that running the SPI off the original plan is simply not relevant.

I do warn my students there is no clear threshold for SPI where being under a certain number means the project is clearly behind schedule. The most important thing is the trend. We cannot keep ignoring work that is otherwise ready to start if we want to avoid mass chaos during the waning moments of the project. Unless it will somehow cost us more money to start activities on time, what excuse have we got?

The only drawback to SPI is that the schedule must be resource-loaded, either costs or units. Without knowing the “weight” of each task Primavera cannot compare the progress of one task to another. The activity durations might be the same but the daily effort to perform the tasks can be quite different. In any case, we must still consider that not every activity may be resource-loaded (such as submittals) so SPI will not tell us anything about the progress on these tasks.

Getting back to the snowplow, the analogy that I always use is a broom sweeping the remaining work to the right. (Why we tend to see the future as being to the right and the past as being to the left is a bit curious, as if time travels west to east, but we seem to accept this as making sense). One of the participants in my Kansas City class mentioned how they think of the Data Date as a snowplow. I liked their analogy so much I warned them I would use it in my blog. And so I did!

 


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:

Primavera Scheduling

 

 

 

 

 

 

 

 

 

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:

 

Primavera Scheduling

 

 

 

 

 

 

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:

Activity-on-Arrow

 

 

 

 

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?


Primavera SchedulingSome features of Primavera P6 are easy to ignore without a better appreciation of their true benefits. Expected Finish dates are a good example. The concept is pretty simple: pick a date when a task is expected to finish and – presto – the Remaining Duration is automatically adjusted to achieve the desired date. This works in all versions of Primavera scheduling software: P6 Professional, P6 EPPM and Primavera Contractor.

We typically use Expected Finish dates for long-lead items with big durations. It can take several months to fabricate and deliver specialized equipment, which means the task will span several update periods. So rather than have to manually adjust the Remaining Duration during every update, Expected Finish dates basically automate this process for us.

Several years ago on a project in Calumet City, IL the time required to procure blowers for a new building was nearly 18 months so I prepared a special procurement fragnet to more accurately track the blowers’ progress. My normal procurement fragnet of submit > review > fabricate/deliver was not enough for such an important long-lead item. This was a blower facility, after all, so if the blowers arrived late we would have had a major problem. With this in mind, I set up a series of activities to track the fabrication in Germany, transport to the port, loading on the ship, and the voyage to America.

There is perhaps one small catch with Expected Finish. We only recommend using Expected Finish dates on activities with progress. Once a task has started it is easier to decide whether a particular finish date is still valid. Otherwise, if the preceding logic is changed you might wind up with a very large Remaining Duration because the task is now starting much sooner than before.

Conversely, if an activity starts much later than anticipated because of re-sequencing the original Expected Finish date may be unrealistic (and possibly before the actual start date, which will obviously seem weird). So we are much better off waiting until the task has begun before putting too much faith in the Expected Finish date. We can verify that the preceding tasks are finished and therefore be more confident that no other obstacles remain.

There are just three steps required to set up an Expected Finish date. First, make sure you have checked the box next to Use Expected Finish Dates under the Schedule Options, as seen below:

Primavera Scheduling

 

 

 

 

Second, select an Expected Finish date under the Status Tab in the Activity Details window. In the example below I have selected February 19, 2016 as the Expected Finish date, which is about a month later than the current Finish date:

Primavera Scheduling

 

 

 

 

 

And third, schedule the project. The Finish date will now match the Expected Finish date. Note that if the Expected Finish date is not a normal work day according to the activity’s calendar then the next available work day will be selected instead.

What I like most about Expected Finish dates is that it reinforces the accuracy of the current Finish dates. In other words, the current Finish dates are not the product of Remaining Durations that may or may not have been verified recently. The Expected Finish dates tell me these are good dates.

One last consideration. If you are updating a cost-loaded schedule then I recommend using Physical as your % Complete Type. This allows us to update the Remaining Duration (via Expected Finish) independent of the percent complete used to calculate Earned Value.

 


3 Strategies for Weather in a Schedule

Categories: P6 EPPM, P6 Professional, P6 Tricks, P6 Web, Primavera P6
Comments Off on 3 Strategies for Weather in a Schedule

protectionUnless you are working indoors, weather is always a consideration when building a CPM schedule. Somehow, normal weather must be addressed for any work that can be impacted by inclement weather. Our only concern should be normal weather; unusual weather is an excusable delay. This of course raises the issue of how do we determine what exactly is normal weather? Contracts often mention that time extensions will only be granted for abnormal weather without defining normal weather. It is easy to find weather data: in the United States the best source of historical weather conditions would be the National Oceanic and Atmospheric Administration. The NOAA has records for thousands of weather stations around the country that in some cases go back a hundred years or more.

Even so, there is not a single standard for applying NOAA data. Should we take the average for the past four years to determine what is normal? Five years? Six? Federal contracts generally rely upon an average of the last ten years to determine normal weather conditions. (As a personal aside, I have lived in California for 11 years and the weather during the past four years has been radically different than what I first encountered in 2004). Most private construction contracts are unfortunately silent as to what sort of average might be considered reasonable.

The U.S. Army Corps of Engineers is probably the best example of how to specify normal weather. The USACE typically tells contractors how many days of inclement weather to include in the CPM schedule each month. NOAA data would only tell us the average temperature and precipitation, which leaves open to interpretation how a day with, say, 0.1″ of precipitation should be treated. For good or bad, the USACE specifications leave no doubt how many days should be blocked out for weather – not including weekends and holidays. Contractors can not claim they thought it would only rain or snow on weekends!

Some State agencies use a methodology similar to the USACE. Last year I was teaching a highway contractor in Minnesota how to schedule projects using Primavera P6. Someone pulled out the specifications for an upcoming project. Glancing down to the weather provisions, I was not surprised to see that the Minnesota Department of Transportation expected contractors to block out 20 days for inclement weather in January beyond weekends and holidays. In case you are wondering, that wipes out the entire month! I was there in March and it was still below zero degrees in the morning. Winter work is nearly impossible outside unless you are ice fishing.

Sometimes, the contractor does not have to address inclement weather at all. The California Department of Transportation (CalTRANS) specifies contract durations in working days. As the project moves along CalTRANS tallies only the days the contractor is able to works. Bad weather days are not counted. As you might have guessed, this means the project end date shown in the baseline schedule assumes perfect weather and therefore is unlikely to be maintained.

Once we have established some sort of standard for normal weather, we can then move on to a strategy for incorporating this weather into the CPM schedule. Below are the three basic strategies that I use, in my order of preference:

I. Add Normal Weather to the Work Calendar

If the owner has already told me how many days of normal inclement weather to anticipate, it is logical to block out this number of days as if they were holidays. While it is not possible to distinguish a weather day from a holiday in Primavera P6, I try to put my weather days on any Tuesdays, Wednesdays and Thursdays to avoid Monday holidays like Labor Day, Memorial Day and Presidents Day. Obviously Thanksgiving is always on a Thursday but otherwise this works pretty well. NOAA data can even tell us which days of the month typically have the most precipitation if we want to find the best candidates for weather days. I also have a Project Notebook Topic I created in Primavera P6 called “Weather” that I use to list the weather days included in the schedule. This removes any doubt as to why these days were blocked out.

This approach does require two work calendars, however. One work calendar will be for the weather-sensitive work while the other will not include any weather days. After all, shop drawings are not affected by weather and there are usually some field activities that take place indoors. Otherwise the two calendars will probably share the same holidays.

At the end of the month, many schedulers like to replace the planned weather days with the actual weather days. This creates a historical record of when the inclement weather occurred. But actual weather days are presumably being tracked elsewhere so I consider this step to be optional.

II. Create a Contingency Activity for Normal Weather

I started using this strategy in the 1980s as a way to show early completion. The contractor would plan to finish the project early so we needed an activity to bridge the gap between the early completion milestone and the contractual completion milestone. Not all owners would accept the contractor’s right to finish early. In some cases the owner would issue a no-cost change order to modify the contract completion date. Basically, the owner was calling the contractor’s bluff. If the contractor figured he could finish early then why not make that the new contract completion date? Otherwise, the contractor might submit a delay claim based on not being able to finish the project early even though the owner never requested the earlier completion date.

On some projects the bid documents are held in escrow; if a delay claim is submitted the bid documents can be reviewed to see if the contractor based his overhead costs on the shorter project duration. A CPM schedule that shows early completion is often viewed with suspicion unless there is further proof. But in some cases the contract documents specify that early completion is not allowed. The contract effectively becomes a professional services agreement with a fixed time frame.

Normal inclement weather can also be treated as a contingency. The number of expected weather days are added up and inserted into an activity between early completion and contract completion. In this case, however, we are not really expecting to finish early; the contingency will disappear if the total amount of normal inclement weather is realized. During each update we reduce the remaining duration of the contingency activity by the number of actual weather days incurred. In theory, there will be no more weather days once the remaining duration reaches zero days. Otherwise, the contractor is entitled to a time extension.

Both the first and second strategies require an analysis to determine how many weather days are to be expected over the life of the project. Unless the number of weather days are specified in the contract there could be disagreements as to how many days should be included. A smaller number helps the contractor with delay claims while a bigger number protects the owner against the very same claims. Activity durations should be based on perfect weather, as normal weather is accounted for by either the calendar or the contingency.

III. Add Normal Weather to the Activity Durations

This is the oldest strategy and does not require as much effort as the other strategies. The contractor simply adds additional time to the activity durations based on the expected weather. I list this strategy last because it is nearly impossible to verify how much time was added for weather unless the contractor keeps detailed notes (such as using an Activity Notebook Topic in Primavera P6 to explain where the days were added). Moreover, the contractor needs to know what time of year each activity will take place before he can add the right amount of time. For this reason schedule logic is needed first so that the start and finish dates are reasonably accurate. But the reason I list this strategy last is that if an activity is delayed the added time for weather may now be too much or too little. Constant monitoring is required to ensure that activities have not moved into a time frame with different weather conditions.

Update: a member of the Association for the Advancement of Cost Engineering took exception to this third method after my original post was published. He felt this method should never be used and referred to the AACE’s Recommended Practice for addressing weather in a schedule. But he was missing the point. I have used this third method for years without any issues. Keep in mind that if the weather days are shown on the calendar or as a contingency activity the contractor has boxed himself into a corner. He cannot later claim he expected fewer normal weather days.

The contractor may very well want to give himself some “wiggle room” to clarify his understanding of normal weather once a dispute arises. And who can blame him if the owner does not specify the number of weather days either? The owner is legally responsible for any ambiguities in the contract documents. Conversely, if the contractor feels he has been treated fairly by the owner on all other matters, he may be willing to concede a few weather days that he otherwise felt entitled to claim.

Let’s use liquidated damages as an analogy. Liquidated damages clauses have been around for decades. A contractor is put on notice that a specific amount of money will be withheld by the owner for each day he is late. Liquidated damages are an approximation of the financial impact caused by the project being delivered late. As such, liquidated damages cannot (and are not required to) be proven. The contractor may think the liquidated damages are outrageous, but this is not a matter for negotiation.

Yet the same owner has no clue how many days should be included in the schedule for normal inclement weather? There are multiple sources of historical data to help him make this decision. So perhaps the owner wants a little “wiggle room” as well. He has the information necessary to make a decision; he just decided to leave the contract ambiguous. Shame on him.

The bottom line is that most construction contracts do not adequately address the definition of normal weather. AACE’s Recommended Practice is not the solution either since it still leaves this matter open to interpretation.

What is your favorite method of addressing inclement weather? I can be reached here.