All posts in Level of Effort

You are here: Home / Blog / All posts in Level of Effort

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.

Apr

My Least Favorite Activity Type

Categories: Activity Types, Level of Effort, P6 EPPM, P6 Professional, WBS Summary

Tags: Activity Types, Level of Effort, Primavera P6, WBS Summary

Comments Off

by Bill Pepoon

While I consider my self pretty adventurous when it comes to Primavera P6, I admittedly have little use for one particular activity type, the WBS Summary. To review, the WBS Summary calculates its Start and Finish date (and therefore, duration) from all other activities that have the same WBS code. On the surface, this seems like a great idea because logic is not required. The WBS Summary is the only activity type in Primavera P6 that works sans logic. And this is what I do not like about it.

I always check the Schedule Log before I publish a schedule. As you should know, the Schedule Log has a topic called “Warnings” that discusses, among other concerns, the number of activities that are missing predecessors or successors. The correct number of “open ends” would of course be two; the first activity will not have a predecessor and the last one will not have a successor. No other answer is acceptable. Owners will also be checking the Schedule Logs during their reviews. Open ends are an easy way to get a schedule rejected.

Because the WBS Summary does not want or need logic, it creates what appears to be a de facto mistake in the schedule. If the person reviewing the schedule figures out that the open ends are due to this particular activity type, then perhaps they would accept the schedule regardless. But it has been my experience that owners do not want to hear any excuses as to why some activities have logic and others do not. Open ends are an unnecessary distraction from other items (sequences, durations, coding, etc.) that need to be checked.

It is possible to add relationships to a WBS Summary to make the open ends disappear, but this basically defeats the purpose of having them in the schedule in the first place. Why not use the Level of Effort instead? The Level of Effort also calculates its dates and duration automatically, but requires logic. Therefore, the Level of Effort does not create any concerns in the Schedule Log. Both of these activity types can also have resources assigned, so nothing is lost by switching to the Level of Effort.

Logic can be added to a WBS Summary without affecting the way it calculates its dates and duration, but again, why not use the Level of Effort instead? While they may seem interchangeable, the Level of Effort demands logic, and therefore forces us to add proper relationships. The WBS Summary is a little too accommodating. I want my activity types to enforce good habits!

Better still, the Level of Effort can transcend more than one WBS code which makes it far more flexible than the WBS summary. If I really need to see the dates and durations for WBS codes I can Group by WBS and choose to Show Group Totals. This saves me the trouble of adding a bunch of WBS Summary activities to my schedule for no other purpose than seeing summary dates and durations.

In the screenshot below, the WBS Summary activity is purple. Yes, this activity tells me the Foundations start on May 17 and finish on June 28, 2016 and have an overall duration of 30 days. Yet the same information appears in the Group Totals:

So there is no additional benefit to adding the WBS Summary activity if the only information being provided are the summary dates and duration.

I know some users are adding WBS Summary activities as a simplified way of cost loading a schedule from the top down. They put all of the costs in the WBS Summary activities rather than the actual work tasks. But Primavera P6 has a tool called Top Down Estimation that is better suited for that purpose. While it is possible to specify a non-linear distribution curve for resources, the reality is that you are still treating every day as having the same value. That is simply unrealistic.

A Primavera P6 compatriot did mention to me a reason why he uses the WBS Summary activity on a temporary basis. When Microsoft Project schedules are imported into Primavera P6, the summary bars are imported as activities. He uses the Microsoft Project summaries as temporary placeholders for checking logic and durations. Similarly, I will use the descriptions of the Microsoft Project summary activities to build my WBS codes before deleting these superfluous tasks,

Aug

Weird Negative Float

Categories: Level of Effort, Primavera P6, Total Float

Comments Off

by Bill Pepoon

There are several settings in Primavera P6 that can have unintended consequences, but perhaps none is worse than what I am about to describe. Primavera P6 users know that negative float can be induced by putting a constraint into a schedule. A Finish On or Before constraint, for example, will generate negative float if the activity is now scheduled to finish beyond the chosen constraint date.

But can a schedule with no constraints generate negative float? A reasonable person would say “no”. After all, if there are no constraints in the schedule the project can extend to any date. So negative float is simply not possible. Who could possibly argue otherwise?

Well, I can! Because I have seen it in action. Let me set the scene. I was at the Kennedy Space Center teaching a Primavera P6 class to a NASA contractor last year when one of the class participants presented an unusual problem. His schedule had negative float but no constraints.

I was quite sure he had forgotten about the Must Finish By constraint. It does not show up in the Schedule Log and no asterisk will appear in the date columns. Nope. My client truly had no constraints in his schedule. Yet some activities had negative Total Float.

The contractor commented that all of the negative Total Float seemed to be on Level of Effort activities and nowhere else. Yet the predecessors and successors to the Level of Efforts had positive float. Huh?

This is one of those situations when I wish I still had some hair to pull. I use Level of Efforts in pretty much every schedule and have never had any problems – regardless of whether any constraints were being used. Some setting or calculation in Primavera P6 was clearly off. After some research in the Oracle Knowledge Base (Document ID 988077.1) the culprit was located.

In Primavera P6, Total Float can be calculated by one of three methods:

Start Float = Late Start – Early Start
Finish Float = Late Finish – Early Finish
Smallest of Start Float and Finish Float

These options are found under the Schedule Options, as seen below:

Right out of the box, Primavera P6 always calculates float using the middle option, Finish Float = Late Finish – Early Finish. And most users would probably not consider changing the calculation method if for no other reason than not understanding why it would make a difference. The NASA contractor had likewise always used this method of calculating float until someone decided to play with the settings. By shear luck, this happened between our training sessions at Cape Kennedy.

There are of course a lot of settings in Primavera P6 that could change the way a schedule behaves. In this situation, no one remembered changing the Schedule Options. The schedule had just been updated, but not for the first time and previously there was never a problem with the float. Seemingly overnight, the float had just gotten weird.

The NASA contractor had switched the calculation to float = Late Start – Early Start. Primavera P6 calculates float values for both the beginning and end of each activity because the values can be different whenever the relationship type is not Finish-to-Start. You probably did not know this (or even care!) but it can make a difference. But any float calculation method other than the one using late dates results in erroneous float being displayed on Level of Efforts.

In the next screenshot I am displaying a Level of Effort activity with negative float.

As you can see in the Activity Details, the predecessor and successor tasks do not have negative float. But why negative float? I have an answer but not an explanation. The negative float is being calculated as the difference between the actual start date of the Level of Effort and the Data Date.

Think about it. Primavera P6 considers the Level of Effort as being behind schedule because it has an actual start date that is before the Data Date. Where else should the actual start be?

In the schedule above the Level of Effort started the day before the Data Date so it is theoretically a day behind schedule. Ridiculous, but that is how Primavera P6 is calculating the float for Level of Effort activities.

Choosing the third method of calculation, Smallest of Start Float and Finish Float is still a bad idea because a negative number would still appear on the Level of Effort. According to Oracle, Start Float and Finish Float is usually the same, but can be different on both Level of Effort and WBS Summary activities.

Why? Who knows, but it keeps me on my toes!

Dec

Weird Negative Float Situations – Part 1

Categories: Level of Effort, Primavera P6, Schedule Options

Tags: Level of Effort, negative float, Primavera P6, schedule options

Comments Off

by Bill Pepoon

Most of us understand that negative float is generated by a constraint that is not being “satisfied” and indeed, we cannot have negative float without a constraint. Or so it would seem. But during a recent training session at the Kennedy Space Center my client showed me several Level of Effort activities that had negative float. In fact, all of the Level of Efforts had negative float yet no other activity showed any negative float whatsoever. Imagine that; the activities linked to the Level of Efforts have positive float but the Level of Efforts have negative float!

In the first figure I am showing a typical setup with a Level of Effort activity linked to one predecessor and one successor. The Activity Type is shown in the Activity Table to make it easier to see which activity is the Level of Effort:

Okay, so far nothing is amiss. The Level of Effort is linked to activities on the critical path and therefore shares the same zero (0) float. But watch what happens when the predecessor to the Level of Effort is updated with progress:

The Level of Effort activity – and only the Level of Effort – has negative float! Keep in mind that no constraints are being used in this schedule. And while all of the Task Dependent activities are on the critical path I can assure you this has nothing to do with the negative float on the Level of Effort activity.

So how is this possible?

The answer has to do with the ability in Primavera P6 to calculate float three (3) different ways. These settings appear under Schedule Options:

I typically calculate float as the difference between the Late Finish and the Early Finish dates. But my client had selected Late Start – Early Start. (The third option is to take the smallest value of the two calculations). Choosing any setting other than Late Finish – Early Finish will generate negative float once the predecessor to the Level of Effort has started. Moreover, astute viewers will notice that the negative float matches the number of days that have elapsed since the predecessor started. The predecessor started five work days before the Data Date and the float is -5 work days.

Why this is happening is a little hard to explain, but Primavera P6 calculates float for both the start and finish of every task. Normally this results in the same value. Level of Effort activities, however, are another matter. Primavera P6 calculates the float on this type of activity as the difference between the Actual Start Date and the Data Date and perceives the activity as being “late” because the Data Date is later than the Actual Start Date.

Thankfully this weird float issue can be easily avoided by using Late Finish – Early Finish for the float calculations. And while this has always been my personal preference I have a whole new appreciation of this setting now.