This topic describes what happens when the live project calendar is advanced before completing the change request.
Often the calendar is advanced for a project between the time a change request is entered and when it is approved. If this happens, then the final step (complete step) of the workflow needs to correct any changes so that the history budget isn’t changed.
There are two processes that occur when the calendar is advanced:
The calendar is advanced.
At month end, the rolling wave data is expanded.
There are also two different types of budget changes:
Changes that come from activities in the schedule.
Changes that are manually entered in the Change Details view.
When changes come from activities in the schedule, the history budget isn’t changed because the Integration Wizard is run on the live project during the complete step.
Changes are manually entered on the cost tab when there are no resource assignments on activities that relate to work packages. These changes are evaluated by PM Compass when the change is applied to the live project. When the changes are loaded or entered, they are applied to periods after the status date.
If the calendar is advanced before the change request is approved, any changes that would have applied to periods before the current period must be applied as adjusting entries in the current period.
In addition to the adjusting entry, if the live project has advanced the calendar past a month end, the monthly data needs to be expanded into weekly periods.
When there is no resource assignment for an activity in the schedule, the budget is loaded directly into the Cost tab in the Change Details View. The Change Details view prevents a change from being entered into the past.
For example, assume the data is configured as follows:
The status date is March 29, 2013.
The work package baseline dates are February 15, 2013 to June 3, 2013.
|
February |
March |
April |
May |
June |
Existing Budget |
10 |
10 |
10 |
10 |
10 |
Change Amount |
|
|
10 |
10 |
10 |
The change amount is entered in this subsequent period after the status date. This is the same process used by Cobra when manually editing budget in the Project View and the project preference Prevent editing of historical time phased values is selected.
Before completing (on the last step of the workflow) a change request, the status date of the sandbox project is checked to see if it is the same as the status date of the main project. If these dates are not the same, it means that the calendar was advanced on the live project after the change request was started and the sandbox project was created. When this occurs, two checks are made to the sandbox data on the complete step:
Is there change data before the current period?
Was the rolling wave data expanded?
If either of the above is true, the work package finish dates are checked to see if any are before the status date. If the work package includes change class data, and the finish date is before the status date, an error message is sent to the user and the change is not applied.
The status date of the live project is checked with the sandbox to see if the calendar has been advanced two times. The validation is for 2 calendar advances because Cobra uses a slightly different rule when applying an adjusting entry when loading data from the schedule than it does for manually changing something in the view. The adjusting entry used by the Integration Wizard is performed in the current period when the Apply historical changes as an adjusting entry in the current status period option is selected in the Integration Wizard file settings.
For example, assume the data is configured as follows:
The status date is March 29, 2013.
The activity has a budget of 50 spread linearly across the baseline dates February 15, 2013 to June 3, 2013.
The change request loads a change budget class from the activity into the work package using the Integration Wizard configuration option Apply historical changes as an adjusting entry in the current status period.
The table below shows the budget on the activity and how the adjusting entry is applied in the current period when it is loaded into the work package.
|
February |
March |
April |
May |
June |
Existing Budget |
10 |
10 |
10 |
10 |
10 |
Change Amount |
|
20 |
10 |
10 |
10 |
The complete step follows the same rule and does not change the budget spread until the calendar has been advanced two times. This reduces the frequency of having to change the budget spread after approval.
For example:
The status date is March 29, 2013 in the sandbox.
The work package baseline dates are February 15, 2013 to June 3, 2013.
A change amount is entered in the Change Details view, spreading a change amount of 30.
|
February |
March |
April |
May |
June |
Existing Budget |
10 |
10 |
10 |
10 |
10 |
Change Amount |
|
|
10 |
10 |
10 |
If the calendar is advanced to April 29, the change amount is not changed because any adjusting amount would occur in April. However, if the calendar in the live project is May 27 at the time the change is completed, that is two status periods (calendar has been advanced two times) and an adjusting entry is performed.
The table below shows the adjusting entry in the new current period of May 27.
|
February |
March |
April |
May |
June |
Existing Budget |
10 |
10 |
10 |
10 |
10 |
The Change Being Applied |
|
|
|
20 |
10 |
Budget After the Change is Applied |
10 |
10 |
10 |
30 |
20 |
If an adjusting entry is required, recalculate is called on the change class to correct the derived costs in the event of a rate change.
Most projects that perform weekly earned value analysis implement a process called rolling wave. This process expands the data to weekly periods for a window; typically one month prior and three months forward. This reduces the time phased budget data compared to what would be stored if the entire project were stored weekly.
When changes are manually entered (as they are with material work packages), the time phased data is spread according to the main calendar which includes any weekly periods in the three-month window.
The expansion of monthly data only occurs on a month-end period; not each week. When the change is completed, the status date of the sandbox project is compared to the status date of the live project. If these two dates are not the same, the monthly calendar set (01) is analyzed to see if a month-end period changed since the sandbox project was created. If a month-end period occurred, then the calendar is advanced on the sandbox project (by creating a calendar file for the sandbox project) to "roll the wave" or expand the periods of the sandbox project data for the material (no activity) work packages.
Create a Change Request Type for Cobra-Only Changes
Creating Assignments from the Costs tab