If you read the first three parts of this series, you’ll see that I talked about the three options to control how Actual Cost is tracked within a Microsoft Project schedule.
- Actual Costs are always calculated by Project – Covered in parts I through III of this series.
- Edits to Total Cost Will Be Spread to the Status Date – Today’s topic. See below for more information.
- Default Fixed Cost Accrual – Covered in Part I, but to recap: This field sets the default for all new tasks, i.e. if I set the Default Fixed Cost Accrual to Start, then all new tasks created will default to the Start setting. Existing tasks will not be impacted.
Let’s close out this series with a review of the effects of checking or unchecking Edits to Total Cost will be Spread to the Status Date on our schedule. As I see it, there are at least two scenarios that we will need to examine:
- Updating Actual Cost for the first time on a task.
- Updating Actual Cost for the second (or third or fourth) time on a task.
What I want to investigate with the latter scenario is whether or not Project is sophisticated enough to handle differences in tracking timephased Actual Cost, i.e. if I book X in reporting period 1 and Y in reporting period 2, will that be tracked as X and Y, or would it average out the two over the period of both reporting periods. (The answer: yes, it that sophisticated.)
Revisiting the first post, my goal in examining this functionality is to assess suitability of leveraging it to support an integration with a LOB accounting system.
The Initial Update
For this scenario, we’re going to create a new project. The project will have a single task that will be four weeks in duration. We will report on the task weekly. Generally, this would violate my own rule of thumb on the maximum duration of a planned activity, but since this is for demonstration purposes, I’ll waive that restriction.
In case you’re wondering what that rule of thumb is, I generally try to follow the principle not to make a single task exceed the length of a single reporting period. If I report weekly, then typically I would try to avoid making a task longer than a week or so.
Other rules you could apply:
- The 8/80 rule which says no task should be smaller than 8 hours of duration, or larger than 80 hours in duration.
- The 1/10 rule, which I believe I learned from Eric Uyttewaal, which states that no task should be less than 1% of the overall project duration, or greater than 10% of the overall project duration.
…but I digress. To this 4 week long task, I add a resource with a rate of $1,000/day, translating into a total cost for the task of $20,000.
For the first test, I will leave the Edits to Total Actual Cost will be Spread to the Status Date option unchecked.
I enter the $4,000 cost in the Task Actual Cost field, and display the results in a split view with the Task Usage view at the bottom:
See how the Actual Cost is accrued in the first day of the task?
Now, I check the Edits to Total Actual Cost will be Spread to the Status Date option, and try the same experiment:
See how the Actual Cost is spread over the first week of the project? In the Usage View at the bottom, I see an Actual Cost of $800/day for the first week.
Ok, so that was simple. Toggling that option on or off will result in the cost being booked to the first time period of the project or spread using what’s been referred to as the “peanut butter approach” across the duration of the first reporting period.
The Second Update
For the second update, we set the status date to one week later and try the same experiment. This time, for the second week, I book $10,000, bringing the total Actual Cost for the task to $14,000.
With the option unchecked…
…the total Actual Cost is booked to the first day of the task. In fact, the update overwrites the value that was there before and simply resets the value on the first day. Simple enough.
…and with the option checked….
Project allocated the additional $10,000 to the second week of the task, i.e. $2,000 per day. Nothing was changed on the days from the first week.
So the moral of the story? The option actually does pretty much what it says it does. Even better, if I set up my integration to dump the actual cost from a LOB application on a weekly basis, then, assuming the status date is configured properly, the cost will be allocated to each of the timephased periods correctly.