I’ve recently been working at a client where they implemented Stored Period Performance using Primavera P6 Professional. It has not gone as smoothly as we would have liked, but there are some valuable insights from the experience should prove useful to others.
Stored Period Performance forms part of the project update each financial period. It stores the current period values for Planned Value (PV or BCWS), Earned Value (EV or BCWP) and Actual Cost (AC or ACWP). These values are then available in P6 and can be displayed as columns in views, graphically in profiles and the usual places.
It is very easy to run, simply go to “Tools > Store Period Performance…” in Primavera P6 Professional to display the Stored Period Performance dialog.The dialog will display all the currently open projects and the “Selected” checkbox can be removed so Stored Period Performance isn’t ran on them.
It is tempting to click the “Store Now” button and then “Yes” on the confirmation dialog to save the period performance values, but the most important lesson is to pause and make two vital checks before doing so.
The first is to review the “Financial Period” and change it to the correct Financial Period for the current period update if it is set to something else. Not doing so can lead to huge problems, as it is very easy to post over the top of a previous period. Primavera P6 has no concept of opening and closing financial periods for posting.
The second is to review the “Data Date” and if it is not the correct date, cancel Stored Period Performance and schedule the project with the correct date. I would advise making it the first day of the following Financial Period. The August Financial Period in the screenshot finishes on the last Sunday in August 2018 so the Data Date is set to the next day, which is Monday 27th August 2018.
Once satisfied both the “Financial Period” and the “Data Date” are correct, you can go ahead and click the “Store Now” button to display a confirmation dialog, after which Primavera P6 will do the calculations and store values in a Financial period bucket.
That’s all there is to it.
Following the advice above will keep users out of trouble so long as all the other project settings and project data is correct. Unfortunately, life isn’t always that kind to us and when mistakes are made, it is helpful to know what Stored Period Performance really does.
What does Stored Period Performance do?
In a nutshell, it calculates what to store in the specified Financial Period by adding up what has already been stored in all the other periods and then subtracting that number from the total.
Consider an activity with two periods of Stored Period Performance and updated to the point when it is time to store period 3. The values are as follows:
Each value for a period is calculated as:
Total Value – (Period 1 Value + Period 2 Value)
For Earned Value it will be:
Total Value for EV – (Period 1 Value for EV + Period 2 Value for EV)
2,150 – (690 + 810)
= 2,150 – 1,500
Making the same calculation for the other values allows the Period 3 column to be completed as follows:One of the two major problems I came across when using Stored Period Performance was the ease in which it is possible to overwrite another Period. Primavera P6 does not prevent this from happening and when it does, it is very difficult to repair.Imagine the scenario where the person using Primavera P6 doesn’t check the “Financial Period” before posting and ends up posting to Period 1 again instead of Period 3. Unfortunately, there is no way in Primavera P6 to stop this from happening. This time the calculation will be:
Total Value for EV – (Period 2 Value for EV)
2,150 – (690)
Performing the same calculation for the other values changes the original table as follows:
Fixing this issue is a lot of work and the subject for a whole other article. The point to illustrate here is, to be very cautious about the choice of “Financial Period” and “Data Date” before clicking the “Store Now” button.
What does Stored Period Performance save?
So far, we have covered the theory behind Stored Period Performance, but not described exactly what is being stored and where. Let’s look at that now.
Here is a table showing the 2 values stored against the resource assignment along with the 10 held against the activity.
Actual Units and Actual Cost values for Stored Period Performance are stored against the resource assignment. The Actual Costs are rolled up to the activity and stored there as well, but this is not the case for Actual Units. Labor and Nonlabor Actual Units are rolled up to the activity, but Actual Units for Material resources are not. This is because Material resources can have different units and mixing a unit for length, such as metres and one for mass such as kilograms is not useful.
Actual Units for expenses are not rolled up to the activity for the same reason.
Stored Period Performance saves Planned Value Cost, Earned Value Cost and Actual Cost against the activity. The Actual Cost is saved in separate buckets for Labor, Nonlabor, Material and Expense costs. There is no column available which holds the sum of these individual Actual Costs in one place. This is a pity, especially if you do not have a reporting tool such as BI Publisher to add them up into a single Actual Cost value.
In another twist, there is a column for Planned Value Labor Units and Earned Value Labor Units but not for Non labor Units. The Labor Units are not much help as there is no associated Planned Value or Earned Value costs for them. The Planned Value Cost and Earned Value Cost is sum of those costs associated with Labor, Non labor and Material resources as well as Expenses.
How to select the Stored Period Performance columns
Stored Period Performance relies on Financial Periods being setup so there is a bucket to store the values each period. It is why we need to select a “Financial Period” in the dialog. A number of years of Financial Periods can be setup in Primavera P6, and if they were all available in the column list we’d be swamped. When you want to display columns holding Stored Period Performance the first step is to tell P6 what the range of columns are.
In P6 go to “Edit > User Preferences…” to display the “User Preferences” dialog. Once there, select the “Application” tab. Click on the buttons in the Columns section to specify the range of Financial Periods you wish to be made available.
I have chosen the three periods from January 2018 to March 2018 in the screenshot below, but the number of periods is a matter of personal choice.
Here is the Financial Period Value column selection for the Activity Layout. Each period has 10 values to choose.
Updating the Project when using Stored Period Performance can be exactly the same as updating a project when not using Stored Period Performance. However, Primavera P6 provides two fields on the Resource Assignment designed to help. One is “This Period Actual Units” and the other is “This Period Actual Costs”. These columns show the difference between total values and the stored values and are intended to show what will be stored next time Stored Period Performance is ran.
Let’s assume we are about to start updating our activity for Period 4. We enter a new Percent Complete, which calculates the new Earned Value, the new Planned Value is based on the new Data Date. We can now enter the Actual Units and Actual Costs in one of two ways.
The screenshot shows the “This Period” columns next to their total counterparts available for resource assignments.
If I know 690 days were actually spent during this period I can enter that figure into the “Actual This Period Units” column and Primavera P6 will automatically change the “Actual Units” column by adding 690 to it resulting in 2940 days. This is shown in the screenshot below. The example has the “Calculate costs from units” flag set so the Actual Cost columns are the same as I specified a rate of £1 per day.
If instead of knowing the period Actual Units, the Actual Units to date was known to be 2950 days then by entering it into the “Actual Units” column it would update the “Actual This Period Units” column automatically.
As soon as Stored Period Performance has completed on the Project, all the “Actual This Period Units” and “Actual This Period Costs” return to zero. This all works well so long as all the right information is gathered and correctly entered before storing the period performance.
The “This Period” values are not so helpful after storing 690 days only to be told after the event it should have been 700 days. To correct this, we have to either enter 2950 days in the “Actual Units” column or 10 in the “Actual This Period Units” column. Choose either one and P6 will be good enough to calculate the other.
This most important point to take from this tale of “Actual This Period” values is Primavera P6 does not prevent the storing of period performance over and over again into the same Financial Period. This is great when iterating through a single period update cycle, but awful if the wrong period is selected and a previous period is overwritten with new values.
I can’t emphasise enough how important it is to check the Financial Period and Data Date before clicking the “Store Now” button.
There are two Project Security Profiles associated with Stored Period Performance.
The “Edit Period Performance” privilege allows the changing of values after they have been stored. For the sake of data integrity, it is a privilege I would only recommend giving to responsible people who would rarely need to use it, such as an administrator. Changing stored period performance values is only required when a mistake has been made.
The “Store Period Performance” privilege allows the user to run Stored Period Performance as its name suggests.
With the appropriate care and attention to detail, Stored Period Performance can work well for saving Planned Value, Earned Value and Actual Costs, and knowing they will not be spread differently as time moves on. This is a common complaint with Actual values.
It is also very useful to be able to iterate through a period update and keep storing over the same period. The downside being there is no concept of opening and closing a period. If it did exist then there would be fewer problems with storing over the wrong period. This was the biggest problem which, depending on the situation, may not be able to properly fix it.
The most disappointing aspect of Stored Period Performance is the decision not to store the Budget At Completion (BAC). A change to the BAC due to a Baseline Change Request (BCR) means it is not possible to calculate variance correctly for periods stored before the most recent BCR.
Stored Period Performance can provide stable Financial Period values for PV, EV and AC but it is no substitute for a dedicated cost management application.