Schedule Risk Analysis Framework
Know What to Expect
- Documentation Required
- Key Participants
- Software Utilized
- Timeline
- Workshop Process
- Deliverable Reporting
The purpose of plan validation is to create ownership in the plan within the organization. Plan validation establishes the mentality that the job plan is “our plan” instead of “your plan”. Another function the plan validation serves is to vet the plan prior to being added to the schedule. Often times this does not happen and causes serious delays in schedule development. Ideally, the plans should go through the proper validation during the planning phase so that when the job is entered in the schedule, the focus can be on tying logic and optimization.
The lead planner is the first checkpoint in the validation process; he has the most responsibility of any participant involved. He is responsible for validating all aspects of the work package. He reviews the activities and their role assignments, durations and sequence. The lead planner also assures the scope, documentation, material, and specifications are correct.
The internal team validation is the second checkpoint in the validation process. The team is generally made up of representatives from operations, reliability, safety, and inspections. When internal team validation is complete, the job can be added to the turnaround schedule. Below are some examples of the responsibilities each person has on the internal team:
Contractor validation is the final checkpoint in the validation process. Core individuals from each contractor should be brought in early to allow sufficient time to validate all jobs prior to the execution of pre-turnaround activities. Any contractor with direct field labor work should validate that all activities have been captured as well as assure their durations, roles, and sequencing are correct.
There will be discrepancies during the validation process; when this happens, it needs to be reviewed with the lead planner to determine the correct course of action. If the discrepancy is legitimate, the corrections should be made and communicated to the scheduler to make the changes in the schedule. Contractor validation is a critical piece to a successful turnaround. It directly affects the development of a quality turnaround schedule and a sound budget.
Scope development is the process of describing, in sufficient detail, the turnaround’s deliverables and the work required to accomplish those deliverables. All scope items should have at least one, direct connection to the turnaround business objectives.
Scope Development Life Cycle
Prior to developing scope, there needs to be a structure in place to group the different jobs into categories. These categories are generally broke down based off of the turnaround’s business objectives.
Sample Categories
Tiers – Categorize the scope into business objectives categories.
Drivers – Further define the scope within the Tier it is associated with.
The development of the preliminary work list is the first stage in the scope development life cycle. It starts by collecting all known turnaround related items; these will come in the form of different lists from different parts of the organization. For example:
Once the lists have been collected, they need to be consolidated in the turnaround work log. The work log could be in the form of an Excel document or a computerized planning database. The work log should contain the appropriate amount of information to effectively manage the scope.
With the different scope lists consolidated, there should be scope development meetings to review each item individually to ensure all needed information has been identified. It’s recommended to obtain a copy of the latest version of the P&ID’s and mark up each item as they are reviewed to prevent duplicating scope items. Often, different operators or maintenance personnel enter the same items in the CMMS software with different descriptions. By marking the scope items up on the P&ID’s, it prevents planning duplicate work, thus saving you time and money.
Scope is developed utilizing a risk matrix to identify the probability and consequence of doing, or not doing, a specific item in relation to the turnaround’s business objectives. The matrix is made
up of a 5 X 5 scale with the horizontal axis representing the probability and the vertical axis representing the consequence. The probability ranges from 1 thru 5, with 1 representing the least likely to occur and 5 being the most likely to occur. The consequence ranges from A through E, with A being the most severe and E being the least severe.
Utilizing (RBWS) Risk Based Work Selection provides a foundation for the organization to make decisions on whether a particular scope item should be included in the turnaround’s scope. Utilizing this process will help eliminate unnecessary scope items that could impact your overall budget and duration.
When the preliminary work list is complete, there needs to be a scope challenge session. This session is where we determine whether an item meets the requirements to be turnaround scope. Each scope item must meet at least one of the turnaround’s business objectives, and determined if the scope can be performed online or if it requires the unit to be down (offline) to execute. You want to avoid as much of the opportunity work as you can, as this impacts the overall budget.
The amount of time that scope is frozen prior to execution could vary based on the size and complexity of the turnaround. The date should allow sufficient time for detailed planning, scheduling, and budget development. Freezing the scope initiates the change management process; from that point on, any item being added or removed must go through the change management process.
This paper provides key insights into the changes that have occurred in Primavera P6 with the transition of the product into a web-centric environment and with the introduction of Primavera P6 Release 8.x.
After Primavera was acquired by Oracle in January 2009, Primavera P6 was eventually ‘assimilated’ into the Oracle Red StackTM solution (all Oracle products suite) with the release of P6 8.0. Prior to the release of P6 R8.0, there was one flavor of a Primavera P6 database (PMDB aka Project Management Database) to administer (not including Methodology Manager aka MMDB), and if the P6 Web was required to run alongside of the P6 Professional Client, it was just a matter of installing a web application server and attaching it to the same database that the P6 Professional Client was attached.
When P6 R8.0 was released around Oct. 2010, it introduced the concept of the ‘Optional Client’ which had to be connected to a P6 R8.0 database and forced all administration to be relegated to the P6 Web interface. This caused a large Primavera community backlash concerning the lack of administration capability in an ‘optional’ client and in part caused the subsequent release of P6 R8.1 and the introduction of the Professional Project management (PPM) and Enterprise Project Portfolio Management (EPPM) databases.
Primavera P6 can now be purchased in two distinct flavors; P6 Professional (PPM) and P6 Enterprise (EPPM). P6 PPM is also known as the ‘standalone’ application but there seems to be confusion over whether it can also be used in an EPPM environment. The answer is yes and no.
The P6 Professional Client application can be used in either environment regardless if it was bought with a PPM license or an EPPM license. The caveat is that when the client is connected to a PPM database the administration is accomplished from within the P6 Professional Client application just as it has for many years and versions prior to R8.x. But if the P6 Professional Client application is connected to a P6 EPPM database then a flag within the application can sense this connection and the administration capability transfers to the P6 Web interface.
Now this brings us to another issue that is not insurmountable but can be complex and time consuming. Let’s assume you have purchased several P6 licenses and went down the P6 PPM path. You’ve implemented P6 and have set up your structures in the database and are happily marching along with your project management and scheduling. Now a year or so down the road a new version of P6 is released (P6 R8.4 is slated to be released Fall 2014) and you want to upgrade. If you decide that all the P6 Web enhancements are something you may want to incorporate into your project controls you’ll have to implement an EPPM environment which will include a web application server. The primary issue is you’ve been running your projects in the PPM database and all the global data cannot be readily ported into the new EPPM database without some sort of mechanism to port the global structures (SDK, API, etc.) and exporting and importing all the P6 projects from one database to the other.
Key takeaways for administering and working in an EPPM environment are:
A Level of Effort activity duration is dependent on its predecessor and/or successor assignments. It basically contracts and expands based on what it is linked to. They can be useful for applying hours for overhead type of activities to a project or turnaround. A common use is to assign a safety watch or crane for the duration of a job, rather than assigning the safety watch or crane to each individual activity.
Things to note about a Level of Effort:
A level of effort activity is similar to, but different from a hammock activity:
Some schedulers tend to avoid the use of LOEs because of the inability to control their durations or update them properly. The intent of this document is to clarify all aspects of using Level of Effort activity types.
Level of Effort Duration Type
Although you can assign a Duration Type such as Fixed Duration and Units/Time or Fixed Duration and Units, the duration is actually never fixed, since its duration is controlled by the activities the LOE is linked to.
Since the duration is never fixed, you must have a clear understanding of how the Budgeted Units/Time and Total Units will react when the duration changes:
Be aware that the Remaining Units/Time will now fluctuate (even to decimals or fractions) during execution when the duration of the LOE changes. This is okay, with the understanding that you do not want the total hours of the LOE to change. Typically any required changes to the LOE total hours should be managed through a change process. An example of this is provided at the end of this document.
Fixed Duration & Units vs. Fixed Units Example:
Here is an example containing two LOE activities. One is set to Fixed Duration & Units and the other is set to Fixed Units. Although the Duration % Complete automatically updated on both due to their predecessor activity being progressed, the LOE set with Fixed Units did not update the Units % Complete, Earned Value Labor Units, or the Actual Labor Units. As stated earlier, use Fixed Duration & Units/Time on LOEs during planning. Use Fixed Duration and Units on LOEs during execution.
LOE Percent Complete Type
Although both the Duration % Complete and Units % Complete should automatically update on LOE (provided you are following the parameters noted above), it’s best to use a units percent complete type on Level of Effort activities. Doing so ensures that the actual and earned hours on the LOE are calculated properly.
LOE Relationship Links
Since a LOE duration is determined by the activities it is linked to, both the LOE start relationship link and the LOE finish relationship link are technically supposed to be predecessors, since realistically both the LOE start and finish are supposed to be driven by other activities. We are noting this because you may encounter other P6 users that will argue this point.
So technically the links for both the start and finish should be drawn up to the LOE, as shown in this example, indicating that the LOE duration is always driven by other activities:
The problem is that both links are predecessors to the LOE. That being said, there is not a successor assigned, which causes the P6 log file to flag the LOE as being open-ended:
Regardless of the technical concept that LOE’s must be driven by predecessor links to define both the start and finish dates of the LOE, we at TEPCO recommend a simplistic approach to ensure there is both a predecessor and successor on the LOE:
This resolves the LOE being flagged as not having a successor in the schedule log, and does not adversely affect the LOE duration in any way:
Updating Progress on LOEs
Updating an LOE tends to cause the greatest confusion. An LOE is NOT a summary activity, although many schedulers like to call it one. The only summarizing attribute of the LOE is the start and finish date. Nothing else summarizes to it.
The Duration % Complete and Units % Complete should automatically update on the LOE. This should not be considered summarization either. It is simply updating the percent based on its own duration, although since it is linked and driven by other activities, it can appear to look like a summary. Some environments use them to simply summarize durations, similar to what WBS (or activity code) grouping bands can do.
So when the driving activities are updated, the LOE start date will automatically update to follow its earliest started predecessor.
In this example, activity A1010 has been updated to 100% and the data date has been moved forward 1 day. Both the Duration and Units % Complete on the LOE have updated.
Earned vs. Actual Hours
Since we typically do not enter true actual hours into P6 based on timesheets, we ensure the project setting is activated to Recalculate Actual Units and Cost when duration % complete changes within the projects details Calculations tab. This ensures the Actual Units automatically update when we enter Duration % Complete or Remaining Duration. This gives us the ability to pulled Earned Hours from resource assignments by utilizing the Actual Units fields as earned units. (A separate white paper has been written on this.)
As a precaution, it’s always good to compare the Actual Units field to the Earned Units field prior to running management reports. If the two fields are not the same, something is out of sync. Your S-Curve reports will most likely be skewed as well.
9 times out of 10 it’s a Level of Effort activity causing the problem. This can happen when the Duration % Complete and Units % Complete fields are not the same on the LOE. This can be very apparent when you have LOE’s with a high amount of manhours.
The cause of the two percent fields becoming out of sync is not always clear. It could be the manner in which activities are updated. Or it could be when there are multiple resource assignments on a single LOE. P6 Version 8 seems to calculate the fields in this aspect better than previous versions. This issue is very common in P6 Version 6.2.
Here is an example of what you might encounter. Notice how the Units % Complete does not match the Duration % Complete. Also, the Actual Hours do not match the Earned Hours.
This is a simple example, so we could just manually change the Units % Complete field to 33.33%. However, if you have an LOE with numerous resources and high hours, this may be more difficult to make them match exactly. The P6 percent fields only show 2 decimal places, so it’s quite possible that the Duration % Complete is rounding in the background.
Fortunately there is a very easy fix that can be used at any time and does not take any manual calculations. The Update Progress tool in P6 will automatically resolved the problem for us, and should fix it right down to a fraction of a percent.
Make Update Progress tool in P6 Part of your Standard Update Process for LOEs:
Since the Update Progress tool resolves the issue, you could add this procedure into your normal updating routine. Simply update your activities as normal, move the data date ahead, ensure no actuals are ahead of the data date, and then use the Update Progress tool on all LOEs. Re- updating an already progressed LOE via Update Progress does not hurt anything. So you could apply a LOE filter and just update them all!
Change Requests and LOEs
If a job containing an LOE increases in duration, this causes the duration of the LOE to increase. The total hours will not increase since the LOE is set to Fixed Duration & Units. An increase in job duration could be due to:
Another situation that may result in added hours for the Safety Watch is a basic overrun of job duration. In this case, the turnaround manager may want to submit a change request towards the end of the turnaround to compensate for the increased usage of the Safety Watch resources.
A major part of turnaround and project scheduling is understanding resource requirements and resource availability.
• Understanding resource limits is necessary for P6 leveling.
Here is a basic process flow:
When you level a project in P6, activities are moved to the right on the Gantt chart in an attempt to remove over-allocation.
Prior to using the leveling functionality in P6, consider the following:
NOTE! Leveling is not rocket science. Many P6 users try to use the leveling functionality to draw a very detailed picture that they want to see. P6 runs numerous algorithms during leveling at a complexity that few people could easily understand.
Some tend to over-use leveling priority codes or level only specific resources. Keep it simple and do not overcomplicate it. Leveling should only come after a well built and scheduled plan has been developed. It should be applied towards the end of the planning phase. Good leveling relies on activity attributes, including priority coding, resource assignments and limits, logic, constraints, and float. Ensure all of these attributes are in place prior to leveling.
There are two primary approaches to resource-leveling:
Pre-defined Start and Finish (Most Common):
Scope and Resource Availability Determines Duration:
Pre-Defined Start and Finish: Work must be completed within the duration.
Pre-Defined Resources: Work must be completed with the number of resources.
Duration is not of concern.
In this example, the hard finish constraint is removed. P6 is allowed to level past the finish milestone, resulting in a longer duration, but no over-allocation.
P6 Basic Leveling Examples:
The following examples explain how the P6 leveler will react based on how the option Level Resources Only Within Activity Total Float is set in the P6 leveling options.
The examples are based on three activities, each set with the Activity Leveling Priority 1, 2, and 3 respectively. The fourth activity is a finish milestone that all three activities are linked to, which will used be to describe the difference between leveling within float vs. leveling without float.
Example #1 – Scheduled, but Not Leveled:
This example contains three activities with 10 hours duration each on a 4×10 calendar, each linked to a finish milestone. The finish milestone has a Finish On constraint set to the end of the third day.
The activities are not linked to each other.
A scaffold resource is assigned to each task as a single headcount. Since the three tasks are scheduled to work at the same time, the graph in the lower right indicates that we need three Brand Scaffold resources during the first day to complete the work.
Our limit line in the graph indicates that we only have one Brand Scaffold resource available. The red on the bar indicates our over-allocation.
Example #2 – Leveled within Total Float:
The option Level Resources Only Within Activity Total Float is selected, with both the preserve minimum float and max percent to over-allocate set to zero.
Go to the Level Resources window by pressing Shift+F9 on your keyboard, or click the Level
Resources button in the toolbar.
Example #2 (cont.) – Leveled within Total Float:
This example has been P6 leveled. There was enough float available to level all three tasks based on their Activity Leveling Priorities. Activities #2 and #3 leveled out based on their priority assignments.
Now P6 shows that the single resource can achieve the work over the next three days.
Example #3 – Leveled regardless of Total Float, but with an earlier constraint date on the Finish Milestone:
The option Level Resources Only Within Activity Total Float is de-selected.
Also, the milestone has a finish constraint imposed on it indicating all tasks must be complete by
the end of the second day.
Example #3 (cont.) – Leveled regardless of Total Float, but with an earlier constraint date on the Finish Milestone:
This example has been P6 leveled. Since we de-selected the option to level within total float, P6 ignores the fact that there is a constraint on the finish milestone, so it leveled the tasks and pushed the milestone.
Activities #2 and #3 are again leveled out based on their priority assignments.
The P6 leveler also pushed out the finish milestone, even though it is assigned a Finish On constraint set to the end of the second day.
Example #4 – Leveled within Total Float, but with an earlier constraint on the Finish Milestone:
The option Level Resources Only Within Activity Total Float is selected, with both the preserve minimum float and max percent to over-allocate set to zero.
However, the milestone still has a finish constraint imposed on it indicating all tasks must be complete by the end of the second day.
Example #4 (cont.) – Leveled within Total Float, but with an earlier constraint on the Finish Milestone:
This example has been P6 leveled. The schedule does not contain enough float to level out all three tasks.
P6 determined (based on the activity leveling priority) that Activity #2 can push out, but there is not enough float available to push out Activity #3.
So Activity #3 remains scheduled on Monday, leaving the resource over-allocated.
Example #5 – Leveled within Total Float, finish milestone reset to day 3, but lag imposed:
The option Level Resources Only Within Activity Total Float is selected, with both the preserve minimum float and max percent to over-allocate set to zero.
Example #5 (cont.) – Leveled within Total Float, finish milestone reset to day 3, but lag imposed:
This example has been P6 leveled. Since the milestone constraint has been reset to the end of the 3rd day, there should be enough float to level the tasks just like Example #2 above. However, in this example we have imposed relationship lag between Activity #3 and the Finish Milestone.
Lag is considered NON-WORK time. It is not float. Since lag was imposed on the relationship link between Activity #3 and the Finish Milestone, Activity #3 will not level out. Activity #3’s available float has been reduced due to the lag that was imposed.
P6 Leveling Settings
Prior to leveling any project in P6, the leveling settings must be configured. Settings are saved with each individual project, so they must be set up for each P6 project the scheduler works with.
To view and modify the P6 leveling settings:
Level Resources Dialog Box Definitions:
Leveling Priorities:
Now that we have discussed the different leveling options, here is an example of what you may typically use for turnaround and project leveling:
Leveling All Resources VS. Leveling Selected Resources
The leveling window has an option to level all resources, or you can select to level specific resources. Some schedulers insist on selecting only those resources that they want to level.
Before you make this choice, ask yourself what the benefit is in selecting specific resources versus leveling them all. What does it buy you? In most cases, there is no harm in leveling all resources, even if you have an abundance of a particular craft on hand. Leveling all resources will provide a more gradual S-Curve Planned Value in the baseline. Just because a plan is leveled does not mean that you can’t aggressively work activities sooner than the leveled dates, if you have the capability to do so.
So don’t be afraid to level them all. If the planned value (baseline hours) in the S-Curve is fully leveled, you will find that setting and meeting upper-level management expectations of planned hours per day (SPI) is much easier to manage.
Activity Leveling Priorities
P6 contains a built-in code field called Activity Leveling Priority. By default, all activities are assigned the value 3 – Normal. If you intend on using the leveling functionality in P6 for the TAR, and intend on using the built-in Activity Leveling Priority code values, these value must be set on each activity.
There are five activity leveling priorities in P6:
1 – Top
2 – High
3 – Normal
4 – Low
5 – Lowest
You are not limited to using the Activity Leveling Priority field in P6 for leveling. If you have priority standards in your organization that require more than the five code values, you can create them as an activity code and then use the activity code for leveling priorities.
Define your priorities! Your organization should define what each priority means. Typically high- risk equipment with unknown inspection results or historical data showing a low level of confidence in the equipment will get coded with “1 – TOP”. This would also include all critical path jobs.
Secondary risk and near critical jobs should get coded as “2 – HIGH”, and so on. Only extremely low risk work with a high amount of float will get assigned the low or lowest values.
Float Analysis When Leveling
It is recommended that you do not perform float analysis on a leveled schedule. With this in mind, it is also recommended that you do not set P6 to automatically level when scheduling. Keep the two functions separate. HINT: Press F9 to schedule, and then press SHIFT-F9 to level.
It is also recommended that you apply the leveling setting “Preserve Schedule Early and Late Dates”. This will ensure that the early and late date fields are reflecting the Scheduled dates, not the Leveled dates.
The Start date and Finish date fields in P6 will show the leveled dates.
Total Float and Remaining Float
P6 provides an additional float field called Remaining Float. You can analyze float using this field when a project is leveled.
NOTE: Remaining Float equals the Total Float when the schedule is NOT leveled.
So if you review the two columns side-by-side, the Total Float is the Scheduled float, and the Remaining Float is the Leveled float.
Cross-Linking Jobs or Equipment
Many schedulers tend to link from one job to another in order to push jobs out for the sake of leveling. (For example, tying piping Job A, to Job B, to Job C, and so on…) The problem is that the jobs have absolutely no relationship to each other. “Chaining” jobs together for this purpose is not a good practice, although there could be exceptions depending on the situation.
Also, when linking jobs together in this manner, float is reduced for each job. The more that are chained together, the more the float is reduced. Eventually, the combination of a bunch of small jobs linked together could turn into the primary critical path.
Cross-linking jobs should only be done when it logistically makes sense, not for the sake of leveling manpower. Doing so only prevents the P6 leveler from functioning properly.
An example of when you might cross-link jobs is when you must remove Exchanger A before you can get at Exchanger B. Exchanger A must be out of the way first. Another example is when you have valves on a column. If the column must be decommissioned, opened, cleaned, and approved for entry before working on the valves, then it’s a good idea to link the start of the valve work to the entry activity of the column.
Using Secondary Leveling Priority Codes
As another example, let’s say you have five columns that are all considered a high priority. They are all independent of each other, so there is not any cross-linking between them. Although they are all considered a high priority, one is high risk for discovery work. In this situation you may want to set up a secondary priority code for equipment. You could create an activity code called Equipment Leveling Priority and assign that priority code for secondary leveling criteria.
Changing Leveling Priorities During Execution
You can change your leveling priorities during execution. Using the previous five columns as an example, let’s say the first column is inspected and it’s discovered that no repairs are required. It might be best to change the remaining activities for the first column to a lower leveling priority, releasing the manpower urgency to the other four columns.
System Leveling Priorities
For turnaround scheduling, as equipment inspection starts to get near completion, you could change your leveling priorities to be based on system turnover priority. Operations have most likely identified the priority of the systems and when they would like them returned. You could set up another activity code called System Turnover Leveling Priority. Once you are to the point in execution where the team is nearing the turnover of equipment back to operations, the leveling parameters can be changed to level based on System Turnover Leveling Priority.
Setting the Resource Limits (Max Units/Time)
Resource allocation analysis must be conducted throughout the planning and scheduling process. Understanding resource limits is necessary for resource management and P6 leveling.
Each resource in P6 contains a Max Units/Time field to impose a limit line when viewing resource profile views.
Although activities should be configured as Task Dependent to ensure the activity calendar is used during scheduling, the Resource Calendar may need to be modified as well, as it also affects how the resource limit lines are displayed in a resource profile.
Adjusting Resource Max Units/Time is an iterative process. You will most likely review a specific resource profile allocation while jumping back and forth to the resource breakdown structure until the Max Units/Time have been sufficiently adjusted to accommodate resource limitations and P6 leveling.
Resource Max Units/Time (Limit) Line Example:
Steps for Adjusting the Resource Limit Line
1) Select the Resource Usage Profile button.
2) In the lower left pane, select the Display drop-down and ensure the view is filtered to display Current Project’s Resources.
3) In the lower right pane, select the Display drop-down and ensure Show All Projects is NOT selected.
4) Schedule (F9) the project.
5) Select a resource in the lower left pane and review their profile in the right pane. Adjust your timescale as needed to show the profile. Notice how the limit line is too low to accommodate the amount of work in this example.
6) Go to the Resources view and select the resource.
7) Adjust the Resource Max Units/Time under the Units & Prices tab
8) Return to the Activities view and look at the resource profile again. The limit line has now increased.
9) Level the project to see the results of leveling the resource. Notice that the resource is still over-allocated.
10) Return to the Resources view and set the Max Units/Time for the resource a little higher.
11) Return to the activities view, level again, and review the profile.
12) If your top activities table is collapsed, right-click and select Expand All
13) In the lower left pane, turn on the filter option checkbox for Time Period.
14) In the resource profile, click on the time periods in the timescale that are over-allocated. The activities table at the top will filter to show the activities that are part of the over- allocation.
Continue the same procedure for all the other resources. Continue to re-schedule and re-level as you go through the iterations.
Keep the following in mind:
Level of Effort Calculations When Leveling
Although LOEs are not included in the resource profile analysis when leveling, when an LOE activity is linked to other activities, the LOE duration can increase when the other activities are leveled. Depending on your Duration Type assigned to the LOE, the total resource hours on the LOE can increase when the duration increases due to leveling.
In the following example, the LOE is linked to Activity #1 and Activity #3. Note the difference in the Budgeted Labor Units field before and after leveling. Note: the resource assigned to the LOE is not the same as the resource assigned to the other activities.
Since the manhours on an LOE could increase due to leveling, you will want to analyze your LOEs after leveling to ensure the increase in manhours is justified. An extreme increase may not be feasible. If so, you could change the LOE to Fixed Duration & Units before leveling to lock the total hours down. Keep in mind that the Units/Time will change instead when the duration changes.
If you’re a current Primavera user and would like advanced training on managing resource allocation and leveling, visit AdvancedP6Training and view TEPCO’s 1022 Primavera Advanced course. You may also contact TEPCO’s training department at (832) 514-4482.
This article is written for schedulers who are using the Resource Assignment functionality in Primavera P6 and performing the following functions as schedules are developed:
One of the key benefits of using Primavera P6 is the ability to add two or more resources that perform work for two or more companies and then have the ability to look at the resource budgeted hours or cost at a company or resource level in a consolidated resource assignment view. Another added option is the summary resource reporting.
Note: Given the reporting capability defined above; company management and cost controllers will recognize and realize the benefit of the reports. In order to make the reports usable, however, cost accounts and a rigid company/resource reporting structure needs to be in place.
However, after stating the added benefit of resource budget reporting, Primavera P6 does not have the capability to further breakdown and report either earned or planned value at the resource level. All earned value calculations are performed and reported at a level no lower than the activity. One would think that given the ability to split a single activity at the resource assignment would have also led to the ability to report either earned or planned value at the resource assignment level. This deficiency has led schedulers to either perform manually intensive workarounds or simply assign one resource to one activity giving up one of the key benefits of Primavera P6.
Keep in mind however that in order to report any meaningful planned or earned values in Primavera P6, baseline management must take place to calculate Schedule Performance Index
the key benefits of using Primavera P6 is the ability to add two or more resources that (SPI). This should be done using both an Original baseline and a Working baseline which is used to manage approved changes.
As has been stated; as an activity is added to a schedule, multiple resources can be assigned to that activity as shown below:
An added benefit of the multi-company/multi-resource capability in Primavera P6 is the ability to map the Cost Breakdown Structure (CBS) to the resource performing that work. Even without storing actual cost in Primavera P6, performance could be reported back to the cost controller to help in the tracking of cost. This is generally accomplished by utilizing fields in Primavera P6 such as:
The benefit does come with limitations. The fields noted above are not available at all levels in Primavera P6. Some are available at the activity level only while others are available at the resource level and viewable in the resource assignments view. Herein lies the issue; if there is one activity and two or more resources working for two or more different companies, you cannot report earned or planned values for those companies without going through multiple, time consuming steps. This is one of the main reasons so many schedulers today are seen moving data from Primavera to Excel during a projects lifecycle and as project change occurs.
The views shown below show the disconnect between the resource and activity level in Primavera P6.
Resource Assignments View – note there isn’t a field available for planned or earned units.
Activities View – several available options, but no ability to group by resource assignment in order to split units, cost account, company, or resource code.
The remainder of this paper describes the process to obtain the data, maintain the changes, and retain accurate variance and budgeted units reporting utilizing data derived from Primavera P6.
Step One:
Add two baselines – once data has been time distributed, reviewed and approved, and the
budgeted units are in alignment with the estimate.
From the resource assignment screen you can obtain the budgeted units by copying and pasting or generating a report (this practice is recommended to minimize copy/paste errors) in a time- distributed format. This report will be summarized to the company (generally) and used as the Original Baseline hours in Excel.
If using the “copy/paste” function be aware that your time distribution will be limited to a 24 hour midnight to midnight “shift.” If reports are based on a custom shift calendar you must generate a report to reflect this.
The original hours for the first plot line are now available for Excel graph.
Step Two:
Set actuals in Primavera P6 as the earned so the actual and earned are equal values.
Since there isn’t the capability in the resource assignments view to see earned units or cost, enabling this option gives the scheduler earned hours based on progress % complete.
The same report as above can be built or copied/pasted, then modified to remove the budgeted units and replaced with the actual (earned) units. This will become the earned units which will be reported each period and plotted. This report is generally easy to maintain and run at the end of each progress update to be provided to the cost controllers.
The earned units for the second plot line are now available for Excel graph.
Step Three:
Changes occur and approvals take place (additions or deletions) and they must be: