Buy Primavera P6

Students who attend our Primavera P6 training classes know that we prefer to use Project Calendars rather than Global Calendars. One reason is that other users may have the ability to change Global Calendars, which means their changes are applied to any project using that Global Calendar. Obviously there are many situations where that would be a bad thing. Another reason is that when exporting a project that uses Global Calendars, those Global Calendars then wind up in the Global Calendars list of the recipient who imports the project. Frankly, the only time I want to see a project’s calendars is when I have that project open.  And today’s blog deals with a very specific problem of exporting and importing schedules that use Global Calendars.

During one of our classes a student asked me to look at a schedule he had already started on a project his company was building. When I imported the schedule I ran the schedule calculation (F9) so that I could review the Schedule Log. During my review it became apparent that the project end date that I was seeing was different from what the student was seeing. My first thought was that he had forgotten to schedule the project prior to exporting the file, but even after hitting F9 the project end dates did not match. So what the heck was happening?

As it turned out, not only was my student using a Global Calendar, he was using a Global Calendar with the exact same name as a Global Calendar in my database. This rarely happens to me because even a basic 5-day calendar can be labeled so many different ways, such as:

• 5×8
• 5 x 8
• 5-8s
• Five day calendar
• 5 day calendar

Anyway, I think you get the idea. My student had used one of the Global Calendars provided with the sample projects that are available when installing Primavera P6. I had the same Global Calendars in my database so, presto, it was easy for my student to pick a Global Calendar name that already existed in my database.

Primavera P6 will not overwrite Global Calendars when importing schedules. My version of the Global Calendar remained intact, which is probably a very good thing when you think about it. But as a result, my student and I had Global Calendars that were the same in name only. His actually had more holidays, so the project end date was later. That was the only reason we were getting different results.

Sharing schedules among databases always introduces concerns when global data is being used. Hopefully you will now understand why it is so important to use project-specific data as much as possible.

Most Primavera P6 users are familiar with setting up and modifying calendars. There is a potential problem, however, when specifying more than 8 hours per day for activities. P6 defaults to 8-hour work days, as we will see in a moment, and interprets anything more than 8 hours as overtime. This results in activity dates not calculating as expected. In the following example, I created a 5-day calendar with 10 hours per work day, Monday through Friday. The work day starts at 7:00 am and ends at 5:00 pm (this allows for no lunch break but my theoretical crew is a bunch of really hard workers!). I assigned this calendar to an activity with a 5-day duration. Notice what happens:

The 5-day task finishes in 4 days. Why? Because P6 assigned an imaginary budget of 40 hours to my task based on a normal 8-hour day. By working 10 hours per day, my crew worked 40 hours in 4 days. This can be confirmed by adding a labor resource and watching what happens to the budgeted hours. While this figure can be changed later on, the initial budget will be based on 8 hours per day regardless of the calendar settings.

Now, savvy P6 users know that the hours per day can also be modified somewhere other than in the calendars. Under Admin, Admin Preferences, Time Periods, the hours per day, week, month and year can be specified. This menu is shown below:

We can change the time units under Admin Preferences to show 10 hours per day. This solves the problem of P6 thinking that anything in excess of 8 hours per day is overtime, but it also changes the settings of every schedule in the database. These are Admin Preferences, and not User Preferences. Admin Preferences affect all projects.

Nevertheless, we are real close to a solution. Note that right under the time periods in the Admin Preferences there is a box with the following phrase:

“Use assigned calendar to specify the number of work hours for each time period.”

Checking this box is real important because it allows us to use the hours per day in our calendars rather than the global hours per day under Admin Preferences. But we need to make one last adjustment.

Under Enterprise, Calendars, there is an option to specify time periods. These time periods are calendar-specific. In the screenshot below we can see the time period settings for just one calendar:

By making the hours per day in the time periods for this calendar match the hours per day in the calendar itself then P6 will properly understand what is considered to be a normal work day.

Your thoughts? Please email me with any comments or questions.