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 EPPM

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!

 


Spring is in the air, which means another release of Primavera P6 Professional Project Management (PPM) and Primavera P6 Enterprise Project Portfolio Management (EPPM).

The list of changes to Primavera P6 Professional is short, but sweet. First, after years of begging, Oracle has finally introduced a feature that has long been part of Microsoft Project: the ability to show the relationship type and lag in the Activity Table. Yes! Previously, this information was only available in a tabular Report or by exporting to Microsoft Excel. Now we can finally show this level of detail in a graphical setting. These are new columns called Predecessor Details and Successor Details, as seen below:

Primavera Scheduling

Second, Claim Digger has been moved to Visualizer and is now called Schedule Comparison. I suspect this was done to avoid the problem of running Claim Digger with the SQLite database. This type of database does not support third-party applications like Claim Digger, which is an important tool for many Primavera users. Rather than wait for SQLite to change its spots, Oracle apparently decided to take a more proactive stance.

Quite a few enhancements have been added to Primavera P6 EPPM to improve performance and to bring it more into line with Primavera P6 Professional:

  • Advanced HTML5 Activity and EPS Views
  • Basic HTML5 Resource Assignment View
  • Additional copy project options
  • Daily Timescale in Team Usage View
  • Additional Global Search & Replace functionality
  • Streamlined installation and management of the P6 Pro application with the removal of JRE

One of the new copy project options is the ability to copy projects that are linked to other projects but not copy those (external) relationships. Previously, we could only choose to not copy external relationships when copying one or more activities. Now this option can be applied to the entire project.

HTML5 pages load faster than the Java-based applets that were originally used in Primavera P6 EPPM and do not require plugins. The HTML5-based pages are referred to as Basic View, but users have the option of viewing the Java-based pages in Classic View.

Relationship types and lags can also be shown in the Activity Table in Primavera P6 EPPM.

Additional information regarding these enhancements can be found here. In addition, Oracle has created a very nifty app called the Cumulative Feature Overview Tool. It is sort of like Claim Digger for analyzing different versions of Primavera P6. You input which version you are currently using and the tool will tell you what features have been added since then, and when the changes were introduced. Click here to access the Cumulative Feature Overview Tool.

 

 


My Least Favorite Activity Type

Categories: Activity Types, Level of Effort, P6 EPPM, P6 Professional, WBS Summary
Comments Off on My Least Favorite Activity Type

Primavera SchedulingWhile 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:

Primavera Scheduling
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,

 


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

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

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

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

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

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

Primavera Scheduling

 

 

 

 

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

Primavera Scheduling

 

 

 

 

 

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

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

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

 


3 Strategies for Weather in a Schedule

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

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

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

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

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

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

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

I. Add Normal Weather to the Work Calendar

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

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

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

II. Create a Contingency Activity for Normal Weather

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

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

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

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

III. Add Normal Weather to the Activity Durations

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

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

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

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

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

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

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


Viewing Data in a Shared Database

Categories: Databases, P6 EPPM, P6 Professional, P6 Web
Comments Off on Viewing Data in a Shared Database

puzzlePrimavera P6 users who share a database with other users will not see the most current changes being made by the other users right away. The other users must commit their changes, and then the user will be able to refresh his or her screen to see these changes. We will discuss how changes to a project are committed to the database first.

Most users commit their changes to the database without realizing it. For that matter, many users are not even aware of any specific procedures for committing changes. Yet it happens on a pretty regular basis as long as the other users take one of the following actions:

  • Closing the application
  • Choose File, Commit Data (F10)
  • Choose File, Refresh (F5)
  • Summarize Projects
  • Apply Actuals
  • Schedule
  • Import/Export
  • Delete a resource
  • Delete a project
  • Change a user password
  • Open a project
  • Close a project
  • Save a project baseline
  • Save a layout in Tracking View
  • Add a resource and complete the New Resource Wizard
  • Create a new Report using the Report Wizard
  • Import or Export a report
  • Select a baseline project to use and click OK
  • Edit a calendar from Enterprise, Calendars
  • Delete a Resource Shift from Enterprise, Resource Shifts 
  • Modify a Resource Shift and click Close
  • Leveling resources


Whew! And that is not even the complete list! So if the other users are moving around the program quite a lot they will probably commit their changes to the database by “accident”. Which is fine, but if someone is adding a long list of activities and doing nothing else, other users who open the same project will not see these changes. But as seen below, switching from one of these views to another will also commit changes:

  • Projects View
  • Reports View
  • Resources View
  • Tracking View
  • WBS View
  • Work Products and Documents View
  • Activities View


Once the changes have been committed to the database then other users simply need to refresh this data on their screen. Thankfully, this list is pretty short:

  • Choose File, Refresh
  • Save a copy of the current project as the baseline
  • Choose Tools, Check Project Integrity
  • Selecting Apply on various windows within P6


The user making changes would not lose them because he or she failed to commit changes for the simple reason that closing Primavera P6 automatically commits changes. For that matter, I have never seen a situation where data was lost even when Primavera P6 crashes. So the only concern is whether other users are seeing the latest revisions.


Using Activity Steps

Categories: Activity Steps, P6 EPPM, P6 Professional, Primavera layouts
Comments Off on Using Activity Steps

note_bookActivity Steps offer several advantages. One, you can break down a complex activity into a series of, well, steps that better describe the scope of work. The activity name does not need to go into a great deal of detail because the steps offer additional explanation. Two, it becomes much easier to update a complex activity with steps because rather than trying to come up with a percent complete for the overall task, each step is updated individually, thereby generating an overall percent complete. Have you ever decided that an activity was 37.25% complete? Me neither, but Activity Steps can do that.

Third, Activity Steps do not requite logic so it is a great way to track work that cannot easily be sequenced. Let us say there are several air handling units in the building and you have been told that only one will be installed at a time due to the available manpower. But no one knows the order in which the AHUs will be installed. No problem. We can list the AHUs as Activity Steps; the work cannot proceed out-of-sequence since there is no predefined sequence.

In order to use steps we must first tell P6 that we are planning to use steps. This is done in the Projects detail window, under the Calculations tab:

Activity Steps_1

 

This box is normally unchecked by default when a new project is added to the database so it is very important to take care of this right away. Next, activities that will be using steps must have “Physical” as the % Complete Type:

Activity Steps_2

 

Note that other activities in the project can still use “Duration” or “Units” as the % Complete Type. Now we are ready to add Activity Steps. In the next screenshot I have added a series of steps for the activity Build Retaining Wall:

Activity Steps_3

 

Each step is assigned a Step Weight, which then determines the Step Weight Percent. The total of all the steps will automatically equal 100%. The columns shown above do not show up in a typical layout so it will be necessary to add them by right-clicking in the Steps tab. You will find them in the General category of columns.

When updating an activity with Steps you must first record an Actual Start date. The Step % Complete column is used for activities that have started but are not complete. Otherwise, checking the Completed box closes out the Step.

If you expect to use the same Steps on other activities (or other projects) then it is a good idea to create Activity Step Templates:

Activity Steps_5

Activity Steps_6

 

 

 

 

 

 

 

 

 

 

These templates can then be inserted into the Steps tab for activities.

Perhaps the only disadvantage of using Activity Steps is that the Step Names cannot be displayed in the Activity Table – only the number of Steps – so a printout does not convey as much information as what is visible in the Steps tab. Still, I see the Steps as something used by the scheduler to status the activity more accurately.

So the only question is, how will you use Activity Steps?

 


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.

 


Oracle released new versions of P6 Professional Project Management (PPM) and P6 Enterprise Project Portfolio Management (EPPM) in March 2015. Version 15.1 is the first new release since Version 8.4 was released last September. Why the big jump in numbering? Well, Oracle tells us that all future releases will incorporate the year it was released, so Version 15.1 is the first release of 2015. If nothing else, it will be easier to remember when you bought the software!

 

The biggest improvement is the ability to export baselines along with the current schedule. Yes! Now when you send a schedule to another party they can access the same baselines that you are using. In the past, recipients would have to convert existing schedules in order to make baseline comparisons. However, the sender can choose which, if any, baselines to export.

Note: schedules must be exported in the P6 XML format in order to take advantage of this new feature.

Other changes in Version 15.1 include:

  • Visualizer can now be run on a computer without installing P6 Professional, so users who only want to view a time-scaled logic diagram (TSLD) do not need access to the P6 module.
  • Resource bucket planning is supported. Planned and remaining units can be typed in the remaining time periods (days, weeks, etc.) for more accurate forecasting. Doing this changes the resource curve to manual, indicating that resources are being distributed manually.
  • The ability to cut, copy and paste multiple projects at the same time, which was previously not possible in the P6 Web component of EPPM.
  • The ability to customize columns in the Project, WBS and Activity detail windows, not previously possible in the P6 Web component of EPPM
  • Start, Finish and WBS can now be added as columns in the relationships detail window, also not previously possible in the P6 Web component of EPPM.
In addition, Version 15.1 improves the P6 Professional component of EPPM by restoring the following features that are available to standalone users:
  • EPS
  • OBS
  • Project Codes
  • Activity Step Templates
  • Cost Accounts
  • Funding Sources

Connecting to an EPPM database using the P6 Professional component has always been somewhat of a compromise in the past in terms of functionality so it is nice to see these “new” features.

 

The ability to export baselines and resource bucket planning are the game-changers on this new release. Having to send projects to someone else and then instruct them to convert projects as baselines on their end is a time-consuming process. Pretty much any time I update a project I want to compare progress to a baseline – typically the previous update or the original plan. So this feature is most welcome.

 

Likewise, resource bucket planning was something needed for quite some time. Some of my clients are planning projects that will last 10, 20 or even 50 (!) years. Being able to distribute resources manually as more information becomes available is very important. Funding for long-term projects is often subject to annual appropriations so the resources must be adjusted accordingly.

 

We have been teaching Version 15.1 in our live online and in-person classes for the past two months and have been very impressed with the enhancements. For additional information regarding Version 15.1 click here for P6 Professional and here for P6 EPPM.

 

Below are screenshots from P6 EPPM demonstrating the new export baselines and resource bucket planning features:

 

Copy Baselines_P6 EPPM 15.1
Resource Bucket Planning_P6 EPPM 15.1