For example, this month is December, most of activity they update start and finish within December but there are always some activities which is updated in November or even in October. (They said they forget to update those activities in November so now they update it this month).

In this case P6 will add some more units to November and make your November report wrong. You have sent November report to other parties and it can not be edited. So, the only solution is you move all November "mistake" unit to December.

You can use Excel to save figure of November and December. Then we can have Actual this month by taking December minus November.

However, we can do this right in Primavera.

First in November you need to run Tool -> Store period performance, to storage Actual Units (in fact this is the cumulative actual unit) to November period.

In December you just update as normal. Now you can show the "Actual This Period Units" column. And that's the data we need.

We are often asked about what are criteria for building Risk schedule. In other words, what factors needs to be taken into consideration while building a risk schedule on which risk analysis will be performed. Here is the plan check list which you may find it helpful - Be between 50 and 200 activities (the smaller the better).·         Have only finish to start relationships. If not possible then start-to-start orfinish-to-finish should be kept to the very minimum but never on the critical or near/sub critical paths.·         The plan must have no constraints e.g. Must Start On Date, Cannot Finish Later Than Date etc. The only acceptable constraint is the start date for the first activity.

 However, if there is some doubt about when the project will start then it is recommended that an activity prior to start is put into the plan, this can be constrained to say current date. Another activity called something like duration to start of project then follows and the actual start of the project links to this. This will allow a variation in the actual start of the project to be considered in the analysis.The plan should only contain future and current (remaining scope) activities. Completed activities are not required. No progress should be shown against an activity only the remaining work for that task.·         Lags and leads should also be avoided. If you want to start an activity say three weeks after 'Design' starts then it is better to split the Design activity into two calling the first part something like Design to requisition stage, this would then become the finish to start to the activity that you wanted to delay.Ideally the plan should have one start and one finish. However, if the plan has more than one end then multiple ends are possible. If this is the case then thought must be given to structuring the plan so that activities can be deleted to review each end separately, if required. This may be needed as the analysis will show the critical path for the last/longest activity/path and therefore, shorter paths (to the other ends) will not show up as critical. To show these as critical the other ends and their associated activities can be deleted and separate runs carried out.

        Titles should be self-explanatory and not reliant on summary level descriptions e.g. the plan may have various sections the first called Design. The activities within Design relying on the reader to see the Design section heading. This is required as the risk analysis will likely sort the activities in a different order and therefore, the descriptions must stand alone. Summary level titles should be avoided.Ideally the plan should be developed using a single calendar. Weather modelling and non-productive time will be modelled within Primavera Risk Analysis (PRA).

We are often asked about what are criteria for building Risk schedule. In other words, what factors needs to be taken into consideration while building a risk schedule on which risk analysis will be performed. Here is the plan check list which you may find it helpful - Be between 50 and 200 activities (the smaller the better).·         Have only finish to start relationships. If not possible then start-to-start orfinish-to-finish should be kept to the very minimum but never on the critical or near/sub critical paths.·         The plan must have no constraints e.g. Must Start On Date, Cannot Finish Later Than Date etc. The only acceptable constraint is the start date for the first activity.

 However, if there is some doubt about when the project will start then it is recommended that an activity prior to start is put into the plan, this can be constrained to say current date. Another activity called something like duration to start of project then follows and the actual start of the project links to this. This will allow a variation in the actual start of the project to be considered in the analysis.The plan should only contain future and current (remaining scope) activities. Completed activities are not required. No progress should be shown against an activity only the remaining work for that task.·         Lags and leads should also be avoided. If you want to start an activity say three weeks after 'Design' starts then it is better to split the Design activity into two calling the first part something like Design to requisition stage, this would then become the finish to start to the activity that you wanted to delay.Ideally the plan should have one start and one finish. However, if the plan has more than one end then multiple ends are possible. If this is the case then thought must be given to structuring the plan so that activities can be deleted to review each end separately, if required. This may be needed as the analysis will show the critical path for the last/longest activity/path and therefore, shorter paths (to the other ends) will not show up as critical. To show these as critical the other ends and their associated activities can be deleted and separate runs carried out.

        Titles should be self-explanatory and not reliant on summary level descriptions e.g. the plan may have various sections the first called Design. The activities within Design relying on the reader to see the Design section heading. This is required as the risk analysis will likely sort the activities in a different order and therefore, the descriptions must stand alone. Summary level titles should be avoided.Ideally the plan should be developed using a single calendar. Weather modelling and non-productive time will be modelled within Primavera Risk Analysis (PRA).

<p