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 in P6 Tricks

Omnibus (adjective)

Comprising several items.

The most common Primavera export file is “XER” which harks back to the company that developed this enterprise scheduling software in the first place: Eagle Ray. Primavera Systems bought Eagle Ray, and then Oracle bought Primavera Systems. The very familiar “XER” file format in fact stands for “eXport Eagle Ray”.

XER files can only export project data associated with the current project, or all resources or all roles. For someone who needs to transfer all resources or roles from one database to another the XER file can be very useful, but I find this to be a rather esoteric function for the vast majority of users.

But there is another Primavera export file (XML) that can do so much more:

  1. Export all project layouts associated with the current project
  2. Export all (or some) baselines associated with the current project
  3. Import into any other version of Primavera P6

This might also encourage you to create project layouts. By default, new layouts are user-specific and can therefore be applied to any schedule to which the user has access. Project layouts are only available to the associated project (or a copy of that project) which is desirable when the layout has specific features (such as a grouping or filter) that would not be applicable to other projects. The header or footer might likewise contain wording that is specific to one project.


Primavera P6 EPPM users are more accustomed to this method of importing files because the P6 Web interface only supports XML file imports and exports. However, P6 Professional Client (sometimes referred to as P6 Optional Client) can be used to import XER files into a P6 EPPM database. Confusing, yes, but P6 EPPM databases can be accessed via a Web or desktop interface.


The following screenshots show the process for exporting P6 XML files. Keep in mind, you are not required to export any baselines and can also choose which ones to export. Likewise, you do not have to export project layouts:

Primavera Scheduling

Primavera Scheduling

Primavera SchedulingPrimavera Scheduling

 

 

 

 

 

Here is the sequence for importing P6 files. Notice that we can choose which baselines should be imported:

Primavera Scheduling

Primavera Scheduling

Primavera Scheduling

Primavera Scheduling

 

 

 

 

 

 

Pretty simple!

Hopefully you will not think of me as a hypocrite if I admit to sending XER files on a regular basis. But as a consultant I do not need to keep sending baselines to clients if they have already received those files previously. For example, if I sent my client the third update last month it is somewhat redundant to send them the fourth update this month with the third update as a baseline. I also do not need to keep sending project layouts unless I have recently created new ones.

Nevertheless, for the recipient, the XML file has everything needed to view the current schedule and make comparisons to previous versions of the schedule. I find that for my construction claims work it is a great way to transmit my entire analysis of a delay to the client. The only downside might be that XML files are not nearly as compact as the text-based XER files. Roughly speaking, XML files tend to be about ten times larger, which in some cases might exceed the maximum file size for email attachments. Not surprisingly, it also takes longer to export and import XML files.


Why Make Open-Ended Activities Critical?

Categories: Constraints, Critical Path, P6 EPPM, P6 Professional, P6 Tricks, Schedule Options
Comments Off on Why Make Open-Ended Activities Critical?

Primavera P6 Professional is obviously a very powerful scheduling program so naturally some of its features exceed the needs of the typical project. I have consulted on projects that span as little as 35 hours to as many as 50 years. Different industries have unique requirements for their schedules as well. Primavera P6 is designed to handle a wide variety of projects. Today I would like to address my reasons for using a feature in Primavera P6 that is rarely used by the typical scheduler: Make Open-Ended Activities Critical. You will find this feature under Schedule Options (Tools > Schedule > Options).

The concept of making open-ended activities critical was introduced many years ago in Primavera P3. And for the longest time I dismissed it as a quirky feature surely not applicable to me. After all, why would I promote an activity to critical status solely because it is missing a successor? That seems akin to me declaring myself the winner of a contest that no one else entered.

Some of my colleagues back in the 1980s figured it was an en easy way to identify activities that should not be critical. Okay, that seems backwards, but the idea was that if some task showed up as critical that did not seem “right” the scheduler would investigate further. But Primavera P3 had a report similar to what we call the Schedule Log in Primavera P6 that was a more definitive (and easier) way of identifying open ends in the schedule. With this in mind, making activities that are missing a successor critical did not seem like the best approach to finding open ends.

I started my scheduling career working solely on construction projects so my viewpoints towards Primavera P3 were based on a single industry. Years later, when I began consulting on a wide-variety of projects I realized another purpose for Make Open-Ended Activities Critical. For example, let’s say I am a manufacturer trying to track progress on several production lines. I would like each production line to have its own critical path, or what Primavera P6 refers to as Longest Path. But this would entail making each production line a separate schedule.

It would be a lot easier to track progress, however, if I incorporated all of the production lines into one schedule. That way I would not have to keep opening up another schedule to track progress. And P3 only allowed four schedules to be opened simultaneously. (Some of you P3 users undoubtedly remember the master and sub-project concept from P3 which was another alternative to what I am describing). But how could each production line have its own critical path without creating separate projects?

Yep. Make Open-Ended Activities Critical. See, by not linking the production lines to each other they would all have an open end at the end of their sequence. So every production line now has critical activities. The float values are not based on the longest of all the production lines. Each production line has activities with zero Total Float. Problem solved!

The concept I just described works the same in Primavera P6 as in Primavera P3. You might be thinking that each production line could have a constraint on the final activity to create zero Total Float and then link the final activity in each production line to some final milestone. Yes, that will work too, smarty pants! It also means that additional open ends do not need to be introduced into the schedule.

Another reason for Make Open-Ended Activities Critical is relevant to projects in any industry. One of my clients currently expects his project to finish early. Owners often don’t allow the original plan to show an early completion date because it might become the basis of a claim (“I planned to finish early and you stopped me”). In this situation the owner allowed early completion. So my client inserted two finish milestones in his schedule: “Projected Finish” and “Final Completion”. The latter milestone matched the contractual finish date.

The “Projected Finish” milestone had no constraint since the date could obviously slip without any ramifications. The “Final Completion” milestone had a Finish On constraint (Mandatory Finish also works) so the date could not move at all. But as you might have guessed, this meant that only the “Final Completion” activity appeared as critical in the schedule. The earlier milestone and all of the activities linked to it (directly or indirectly) carried Total Float values based on the later milestone.

A critical path consisting of just one (the last) activity) would obviously be acceptable to no one. But the solution was quite clear to me. While my client had linked the “Projected Finish” milestone to the “Final Completion” milestone (to avoid unnecessary open ends) we need the “Projected Finish” milestone to have no successor. Then, by choosing Make Open-Ended Activities Critical in the Schedule Options the Longest Path of activities leading up to “Final Completion” all had zero Total Float. Bingo.

Below is how the schedule looked with “Projected Finish” linked to “Contractual Finish”. Not having open ends means there is no logical critical path. Also, the “Projected Finish” milestone is a non-driving predecessor to the “Contractual Finish” milestone, as evidenced by the dotted relationship line:

Primavera Scheduling

By deleting the relationship between “Projected Completion” and “Final Completion” and choosing to Make Open-Ended Activities Critical under Schedule Options, the activities leading up to “Projected Completion” are now critical:

Make Open-Ended Activities Critical is not always a necessary feature, but as you can see, it certainly does have a purpose.

 


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 SchedulingPigeons mystified Charles Darwin. He mentions them in the very first chapter of On the Origin of Species:

“The diversity of breeds of pigeons is truly astonishing. If one compares the English Messenger with the short-faced Culbutant, one is struck by the enormous difference of their beak, resulting in corresponding differences in the skull.”

There are as many species of pigeons as there are of dogs or cats. But today we are focusing on carrier pigeons and their cousins, homing pigeons. And what a noble history! Noah was the first to recognize a pigeon’s ability to carry a message. The Romans used pigeons to transmit the results of chariot races. Genghis Kahn and Charlemagne relied upon pigeons to carry messages to troops, as did the French in the Vietnam War.

Even today, pigeons are used to carry blood samples in remote parts of England and France. Not surprisingly, pigeons have also been dragged into nefarious duties. Drug traffickers in Afghanistan and Pakistan have utilized flocks of pigeons to deliver heroin, each one carrying 10 grams.

But let’s be honest. If rats could fly we might have used them instead. Pigeons deliver a message – right or wrong – from one party to another. They don’t (can’t) read the message or vouch for its accuracy.

Don’t be a pigeon. Too many schedulers are simply delivering information that is incorrect or incomplete. They fail to consider whether the current critical path makes sense, ignore activities that clearly should have had progress by now, and fail to analyze the potential impact of unforeseen events.

Not all information can be easily verified, of course. Unless the scheduler is posted to the field he or she can not independently verify actual dates, installed quantities, percent completes and the like. Still, there are times when the reported progress makes little sense, like my client who said he had started plumbing fixtures on the third floor of the building at a time when the structural steel to the second floor was being erected (he was taking credit for plumbing fixtures that had been delivered to the jobsite, but we had a procurement activity for that scenario).

That story involving the plumbing fixtures happened more than 25 years ago. Schedulers have long memories! More recently, I have been reviewing schedules on a 34-story apartment tower in the midwest for the owner. Ironically, plumbing is once again the issue.

A couple of months ago, installation of water heaters on nearly every floor showed up on the critical path. And with one week scheduled for installation per floor, we had water heaters occupying about seven months of the remaining critical path.

I understood how the water heaters wound up on the critical path. The contractor had added activity relationships between water heaters on each floor – something we were calling “crew restraints” way back in the early 1980s.

Here is the funny part. When I filed my report with the owner, the contractor accused me of modifying his schedule update! He had no idea these crew restraints existed or why they had been added. The reality is that the crew restraints had always been in the schedule but due to better progress on other paths, this water heater path had now been exposed.

If you are wondering why water heaters were such a concern, the fact is that most of the interior work (drywall, painting, etc.) had similar crew restraints. But only the water heaters assumed one floor at a time. I have no idea why. It is clearly a very conservative assumption, and as many of you who read my blog on a regular basis already know, I prefer The Schedule That Can be Beat.

Nevertheless, this project is behind schedule and letting the water heaters control the project completion date is not acceptable. Yet this trend continued for another month. Finally, the contractor revised the logic so that water heaters overlapped on some floors. The critical path is now starting to make a lot more sense.

That’s just it. A good scheduler should know what belongs on the critical path. Even when I am still building the baseline schedule I have an idea of what will be critical. During the monthly updates I believe I know what should be critical as well if my logic is still valid and the contractor makes sufficient progress.

Submittals tend to be ignored by the contractor because so many of them have large float values. Whenever a submittal pops up on the critical path after I make a preliminary run of the monthly update I get very suspicious. Most of the time, the contractor’s memory improves dramatically when I tell him a submittal is on the critical path (“oh yeah, we submitted those shop drawings weeks ago!”).

Schedulers cannot afford to be gullible. People gives us bad data all the time and expect a good result. Not going to happen! The guy who told me he was 75 percent complete last month will report that he is 60 percent complete this month. Which number is the truth? The reality is that we tend to get better information on the most critical activities because everyone more or less understands what “critical” means (fingers crossed).

So how do we avoid becoming pigeons? Here are a few things to consider:

  1. Never publish a schedule until the draft version has been reviewed by the project stakeholders. We do not want someone coming back and saying the logic is wrong, the durations are a fantasy, etc. after the schedule has been submitted to the owner.
  2. Use Activity Steps on complex tasks to make it easier to report progress. I think Activity Steps are one of the best features in Primavera P6 ignored by most casual users.
  3. “Gut check” the critical path. Even if the critical path seems acceptable to other project stakeholders, they are probably not scheduling experts and they certainly do not understand the details of the schedule nearly as well.
  4. Always use Retained Logic as the scheduling method in Primavera P6 for activities with progress. Nothing keeps you, and everyone else, honest like being confronted with out-of-sequence work.
  5. Avoid unnecessary logic changes. If the project is not going according to plan, why? If the owner is causing work to be performed out-of-sequence we need to preserve the logic to show the delay. But if the contractor has simply changed his mind, by all means modify the logic to keep it realistic.
  6. Educate yourself. If scheduling is not something you really understand, you need training or guidance. I studied CPM in college, but I really did not know how to apply it correctly until I started working side-by-side with professional schedulers.

There you have it. Spread your wings and fly! Okay, so perhaps that is not really the best metaphor.

 

 

 

 

 


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!

 


Claim Digger Limitations

Categories: Claim Digger, P6 Calendars, P6 EPPM, P6 Professional, P6 Tricks
Comments Off on Claim Digger Limitations

Primavera SchedulingClaim Digger is a convenient tool inside Primavera P6 for comparing schedule files to determine what changes have been made. But there are limitations to what Claim Digger can tell us about a revised file. Experienced Primavera users will recall that Claim Digger used to be a third-party program used to analyze Primavera P3 files. When Claim Digger was incorporated into Primavera P6 several years ago the functionality changed in ways that were both good and bad. Being able to export to HTML format is nice, but having the durations (including float and lags) displayed in hours is inconvenient on schedules with durations that are shown in days.

There are third-party software programs that can do much more than Claim Digger. Still, if you think that Primavera P6 costs as much as having a baby then anything that is “free” will be the most desirable option. So most of us will have to get by with Claim Digger until money starts growing on trees.


Note: in Version 16.1 of Primavera P6 Claim Digger is now called Schedule Comparison and is accessed from the Visualizer program. You will find Scheduler Comparison in the same location (Tools) as Claim Digger but clicking on this button will launch the Visualizer program.


The biggest limitation in Claim Digger has to do with calendars. Here are two scenarios where Claim Diggers will let you down:

  1. Changes made to a calendar, such as revisions to the number of hours per day, days per week, holidays, etc. are not picked up by Claim Digger
  2. Changing the calendar on an activity from Global to Project (or vice versa) is not picked up if both calendars have the same exact name

Indeed, Claim Digger will tell us nothing about calendars other than whether the name of the calendar is different. To demonstrate this for myself I created a Project calendar called “Standard” that is a copy of a Global calendar with the same name. I assigned the Global calendar to all of the activities in a sample project. After creating a baseline (copy) of this project I switched the calendar on the activities in the current project to the Project calendar. Claim Digger did not report any changes to calendars.

I then changed the name of my Project calendar in the current project to “Standard Days” and re-ran Claim Digger. As I expected, Claim Digger reported that I had changed the calendar. Yet other than the name, it was still the same Project calendar. I hadn’t changed anything else. In other words, a false positive.

Owners often run Claim Digger (or ask for the results) so anything that suggests a change when in fact no change was made creates unnecessary confusion. Conversely, a sneaky scheduler could block out additional days in the calendar to coincide with an owner-caused delay in order to exaggerate the impact. An experienced scheduler should be able to figure out if there are any shenanigans going on, but the reality is that P6 is chock-full of hidden traps for the uninitiated.

While we are on the subject, I often refer to myself as a “Primavera P6 Scheduler” because there are in fact specific techniques to scheduling projects with Primavera P6. Case in point: Microsoft Project does not allow two relationships between the same two activities, while in Primavera P6 this is perfectly acceptable. A good scheduler with poor Primavera P6 skills can still make a lot of mistakes because of their unfamiliarity with the program. For the same reason, I tend to be very cautious in Microsoft Project because it is not my bread and butter.

I started using Primavera software in 1987 so in my mind the rules that I observe have almost always been specific to one particular program. Prior to 1987 the software I used was proprietary and followed basic Critical Path Method rules. But CPM does not teach you about Activity Codes, Resource Leveling, and so many other things that are now possible because of software any more than an accountant would automatically know how to create a macro in Microsoft Excel.

“Old-school” schedulers who refuse to stay current on scheduling software get no sympathy from me. I started with proprietary scheduling software, learned Primavera P3, followed by Primavera SureTrak, Primavera Primavera P6, Primavera Contractor, and Primavera P6 EPPM. Not to mention all of the other programs like Microsoft Office that I have had to learn over the years. I had to learn WordPress just to type this silly blog!

 


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.

 


Party like it’s 2050

Categories: P6 Calendars, P6 Professional, P6 Tricks
Comments Off on Party like it’s 2050

DeLoreanRecently we noticed several people asking about the “2050 problem” with Primavera P6 on Linkedin. Here is the issue. When Primavera P6 users try to input dates starting in 2050 the calendar reverts to 1950. Holy Marty McFly! (As an aside, my brother Steve owned a DeLorean for more than 20 years and his mechanic did all of the work on the “Back to the Future” cars). For those of you with access to My Oracle Support, a solution was posted in Doc ID 905558.1 without much explanation as to the root cause. This problem does not occur in the P6 Web component of P6 EPPM.

While 2050 may seem like a rather esoteric concern the reality is that some of our clients are planning projects right now that are expected to last decades. For example, we trained project managers from the Southwest Research Institute Planetary Science Directorate. SwRI is an independent, nonprofit, applied engineering and physical science research and development organization with over 3000 employees. One of their projects is NASA’s New Horizons Mission to Pluto.

The New Horizons spacecraft left Earth on January 19, 2006 and did not reach Pluto until July 14, 2015. That’s nearly nine years just traveling in space. But before that there were the many years spent planning this mission. We have also trained several NASA contractors at Cape Kennedy and it really makes you appreciate what long-range planning is all about, in terms of both time and distance!

Personally, I expect to be either dead or cryogenically frozen by 2050, but for the younger Primavera P6 users out there who expect to be around then there is a solution right now. First, we need a DeLorean…

Just kidding. The solution is actually quite simple. The “2050 problem” only occurs in Primavera P6 when the date format is set to two digits for the year. Inputting 01/01/50 in a date field is interpreted as January 1, 1950. Who knows why this suddenly starts happening in 2050. Dates in 2049 are fine! But if the date format is set to four digits before the dates, P6 is ready to party on past 2049.

The date format is a user preference. Go to Edit > User Preferences > Dates to change the date format. Keep in mind that changing a user preference changes the appearance of all projects accessed by that user. Going back to two digits for the year later on could cause issues with the projects that extend past 2049. I am certain that Oracle will fix this issue eventually. And perhaps we will see a real hoverboard by then!

 


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.

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.


Dissolving vs Deleting P6 Activities

Categories: P6 EPPM, P6 Professional, P6 Tricks, P6 Web
Comments Off on Dissolving vs Deleting P6 Activities

We all make mistakes, or perhaps the scope of work has changed, which leads to activities being deleted in the schedule. And most users will simply delete the unnecessary activities. This, however, often leads to open ends in the logic. After all, you might be deleting the only successor to another activity in the schedule, or deleting the only predecessor to another activity. To avoid this problem, I dissolve activities instead.

All of the current versions of Primavera scheduling software have the ability to dissolve activities: Primavera Contractor, Primavera P6 Professional, and Primavera P6 EPPM. But dissolving activities is nothing new, as Primavera P3 incorporated this feature many years ago. Regardless, many P3 users ignored the feature and continue to do so in the current programs.

So what exactly does “dissolve” do? Well, when you dissolve an activity its predecessors are linked to the successors of the dissolved activity. Say for example that Activity A precedes Activity B, which in turn precedes Activity C. Dissolving Activity B would result in Activity A becoming a predecessor to Activity C. In theory this should be an acceptable change to the logic, since Activity A was already an indirect predecessor to Activity C.

Here is an example of how the dissolving process works. In the screenshot below I have three activities, each with a duration of 5 days, linked together using Finish to Start relationships. So the total amount of time required for these three tasks in 15 days:

Dissolve Activity_1

 

In the next screenshot, I have highlighted Activity B and then right-clicked to select dissolve from the menu:

Dissolve Activity_2

 

Now that Activity B has been dissolved, Activity A is a predecessor to Activity C and the total amount of time has been reduced to 10 days:

Dissolve Activity_3

 

Easy as pie, unless I’m the one baking it. While it is always a good idea to check the Schedule Log for possible open ends elsewhere in the schedule, there should be no open ends as a result of dissolving activities.

Any questions? Feel free to contact me.