All posts in P6 Tricks

You are here: Home / Blog / All posts in P6 Tricks

Jul

The Rookie Resource Mistake

Categories: Level of Effort, P6 Professional, P6 Tricks, Primavera P6 Baselines, Resources, Uncategorized, WBS Summary

Tags: Baselines, Earned Value, Primavera P6, Resources

Comments Off

by Bill Pepoon

In one of my favorite Gene Hackman films, Heist, there is a scene where his character is explaining how he solved a problem. His client (actually, a mobster he is planning to rip off) says, "you're a pretty smart guy." When Hackman's character declines the compliment, the mobster replies, "then how did you figure it out?" Hackman's response:

"I said to myself, 'what would a smart guy do?'"

I love that line. Unfortunately, I recently forgot that lesson. Let's set the stage. I am updating a new Primavera P6 schedule for the first time. I have a change order modification that has been added, and there is also progress on this new activity.

The client told me he is 40 percent complete with the modification. So I type in that percentage. And I move on with the update. But while checking my customized earnings report I realize there is no Earned Value for the new activity. But the activity is in fact showing 40% complete.

Okay...

Now, perhaps you are thinking I forgot to apply an actual start date. Well, no, it would not be possible to show a percent complete without first entering an actual start date. I should also mention that I am using the Physical % Complete type so that I can enter whatever percentage I want.

Hmm. Perhaps there is something wrong with the way I cost-loaded the activity. Nope, it has a budgeted total value. And I am using the same resource that all other cost-loaded activities have been assigned in this particular schedule.

What about my Earned Value settings? I almost never change them, but I verified that Performance Percent Complete = Activity % Complete (Admin > Admin Preferences > Earned Value). In the construction industry that is pretty much the setting that everyone uses. The point being that the activity percent complete determines Earned Value.

Yet here I am, still looking at zero dollars earned and 40% complete.

Aha, must be the activity type! We know that certain activity types like Level of Effort and WBS Summary behave differently than other types of activities.

Sorry - the new activity is Task Dependent. Nothing to see here folks. And if you were thinking it was a milestone, keep in mind that milestones cannot be assigned resources due to their zero durations.

What would Gene Hackman do?

He'd probably say something like, "hey buddy, if Earned Value is working on EVERY other activity in the schedule then there has to be something different about this one."

But it's not different, it's just new.

Oops...

Yes, it is a new activity! And where does Earned Value come from?

The baseline to the current schedule!

Under the Settings tab in the Project Details window there are two options for calculating Earned Value: Project baseline or User's primary baseline.

My schedule was set to Project baseline, and my Project baseline is the original plan. The new activity doesn't exist in the original plan so Earned Value is automatically zero.

I knew this, of course, but it is easy to forget when you are in a hurry. And it seems rather odd that users who never create baselines for the current project are immune to this potential problem. Because when there are no baselines the current schedule IS the baseline!

This is in my mind one of the most counter-intuitive aspects of Primavera P6. Earned Value is not always based on the current schedule. Why would I want to base my earnings on something other than the current schedule? If the budget has changed it seems logical to pay off the new budget.

Now, I prefer not to change the value of an existing activity for pretty much the same reason I don't change the original durations. I want to preserve the old values for future reference. If the duration or budget is changed by a modification I will add a new activity for that purpose.

I have had a few projects, however, where we re-balanced the activity budgets. Assigning any baseline other than the current schedule would clearly cause problems. Which brings up another concern: the Earned Value for a project can be okay one day and off the next if a different baseline is assigned. Fun!

When I mention this during training sessions I often hear someone with a little Primavera P6 experience say something like, "never happens to me". Yes, that could be true. If you don't typically create baselines then by default your baseline is the current schedule. Lucky you!

Those of us who utilize baselines on a regular basis have to be more careful. And it gets rather complicated when there is more than one baseline attached to the current schedule. Re-assigning a baseline can change Earned Value. Oh well. I'll just keep channeling Gene Hackman.

Sep

The Resource I Never Use

Categories: P6 EPPM, P6 Professional, P6 Tricks, Primavera Resources

Tags: Primavera P6, Resources

Comments Off

by Bill Pepoon

Resources add "weight" to a schedule. That is to say, resources can tell us the effort - in costs and/or hours - required to perform a task. Once resources have been added to an activity we now realize that tasks with similar durations are not so similar when the effort is considered.

Back in the early 1980s I would sometimes be asked by owner representatives to explain how many people were required each day in order to stay on schedule. I was using a proprietary scheduling program running on a mainframe computer in those days. It was a nice little program based on the Activity-on-Arrow (AOA) method of scheduling. But it was not capable of doing much with resources other than assign a cost value to each task.

In a parallel scheduling universe, however, Primavera Systems was offering the ability to budget and track both costs and units. The firm I worked threw in the towel in the face of a better product and switched over fully to Primavera in 1987. That was a good decision but at the time there were other scheduling programs to consider. Proximity might have helped. Our company's headquarters were across the Delaware River from Primavera Systems.

It might surprise schedulers who nearly always resource-load their schedules that a large percentage of companies - at least in the United States - rarely do so. The reasoning is often that it takes too much time or exposes confidential information. I know a lot of contractors do not want anyone knowing how many labor hours were figured into their projects.

Not knowing how many labor hours are required by the project once led to an awkward exchange with an opposing attorney during my testimony in a construction dispute:

Attorney: "Mr. Pepoon, how many people would have been required to perform this task that we are looking at right now?"

Me: "Enough people to perform the task within the planned duration."

Attorney: "But how many people would that be, exactly?"

Me: "The proper number to perform the task within the allotted time."

It sounded like a bad comedy skit, but of course I could not answer a perfectly relevant question because my client did not resource-load the schedule. And the reality is that when a subcontractor is responsible for the work the general contractor usually can't verify the duration either. He simply trusts that the subcontractor knows best.

The people performing the task would presumably know how long it takes. But no one else can verify this without knowing the required effort. Then why does this still happen? Well, general contractors pass on a lot of the risk (i.e. scope of work) to subcontractors and can always "sue the bastards" if they fail to meet the schedule. Of course, owners will then sue the general contractors for not controlling their subcontractors. Nobody will be happy.

Still, there is one resource I refuse to use - material. Anyone familiar with Primavera P6 understands that there are three types of resources: labor, nonlabor, and material. Nonlabor is mostly used for equipment, but I have another use for it as well. The trouble with a material resource is that Primavera P6 only tracks costs, not units. With labor and nonlabor resources the choices are to track units, costs, or both.

From my perspective, tracking material could be very useful. If I have moved 50 cubic yards of dirt and there is a total of 100 cubic yards, then certainly one-half of the work is complete. (I should also consider how long it took to complete one-half of the work, because productivity is important as well). This is production-based scheduling, but it is simply not possible with a material resource.

Thankfully, there is a workaround. Instead of using a material resource, why not use nonlabor instead? If it's not labor it can be pretty much anything, right? So nonlabor can be plumbing fixtures, dirt, gypsum board, conduit, or anything else we want to track. I have even used a nonlabor resource to track drawings being produced by the design team.

Both labor and nonlabor resources use "units" as the nominal description. Only material resources can have other labels, but we can easily create our own definitions.

For plumbing fixtures the unit can be "each", cubic yards for dirt, square feet for gypsum board, and linear feet for conduit. Each type of material will of course require its own unique nonlabor resource. I also indicate the real unit of measure in the description, such as "Dirt (Cubic Yards)" to emphasize the point.

I also do not show the unit label for these nonlabor resources because Primavera P6 would put "hours" on all of my nonlabor resources (Edit > User Preferences > Time Units). One other thing. When printing resource charts I do not lump nonlabor resources together because they are not the same materials at all, but this would be true for equipment as well.

Ultimately, we must decide what level of detail is required when adding resources. Minor amounts of material may not warrant much scrutiny. The desired output determines the level of input required. For example, do we need to track different sizes of piping or can they be lumped together? Too much detail is often as bad as not enough detail.

Jan

The P6 Omnibus File

Categories: Baselines, P6 EPPM, P6 Optional Client, P6 Professional, P6 Tricks, P6 Web, Primavera layouts

Tags: Baselines, Layouts, P6 Optional Client, P6 Web, Primavera P6, XML

Comments Off

by Bill Pepoon

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:

Export all project layouts associated with the current project
Export all (or some) baselines associated with the current project
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:

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

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.

Dec

Why Make Open-Ended Activities Critical?

Categories: Constraints, Critical Path, P6 EPPM, P6 Professional, P6 Tricks, Schedule Options

Tags: Constraints, Longest Path, open ends, Primavera P6, schedule options

Comments Off

by Bill Pepoon

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:

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.

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!

Feb

Are You a Pigeon?

Categories: Activity Steps, Critical Path, P6 EPPM, P6 Professional, P6 Tricks, P6 Web, Primavera Contractor

Tags: Activity Steps, Critical Path, Primavera P6, Retained Logic

Comments Off

by Bill Pepoon

Pigeons 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:

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.
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.
“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.
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.
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.
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.

Oct

The Snowplow Effect

Categories: P6 EPPM, P6 Professional, P6 Tricks, Primavera Contractor, Schedule Performance Index

Tags: Primavera Contractor, Primavera P6 EPPM, Primavera P6 Professional, Schedule Performance Index, SPI

Comments Off

by Bill Pepoon

During 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!

Jul

Claim Digger Limitations

Categories: Claim Digger, P6 Calendars, P6 EPPM, P6 Professional, P6 Tricks

Tags: Claim Digger, P6 Calendars, P6 EPPM, P6 Professional, Primavera P6

Comments Off

by Bill Pepoon

Claim 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:

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

Apr

Expected Finish Dates

Categories: Expected Finish, P6 EPPM, P6 Professional, P6 Tricks, Primavera Contractor

Tags: Expected Finish, Primavera Contractor, Primavera P6 EPPM, Primavera P6 Professional, Remaining Duration

Comments Off

by Bill Pepoon

Some 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:

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:

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.

Feb

Party like it’s 2050

Categories: P6 Calendars, P6 Professional, P6 Tricks

Tags: Primavera P6 calendars, Primavera P6 Professional

Comments Off

by Bill Pepoon

Recently 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!