Tracking Actual Costs in Microsoft Project 2010 (Part II)

Continuing in the thread of documenting more on Actual Cost calculations than you ever wanted to know, let’s look at what happens when we manually edit the Actual Cost for a task on which a resource is actually assigned.

For Those of You Just Joining Us…

For review, what we identified in the last post is that each task appears to come by default with two assignments (even when no resource has been assigned), i.e the assignment when there is no assignment – perhaps demonstrating another of those peculiar intersections of Zen and Microsoft Project. 

One of those non-assignments tracks the task Fixed Cost, and one of those non-assignments tracks variable costs.  When there are no variable costs, that second assignment appears to do double duty by tracking adjustments associated with manually editing the Actual Cost field.

Below is an Access query against an MDB file derived from an MPP file with a single task and no assignments. See the two non-assignments, one not assigned to a resource called “Task’s Fixed Cost” and the other not assigned to “Unassigned?”

Tasks with Single Assignments

Now let’s take a look at what happens when we actually do add assignments.  Again we’re using my basic project schedule for illustration purposes.

For comparison purposes, here’s what my Access query looks like against that project.

Now let’s assign a work resource to the task.  I will set the resource cost to $1,000/day.  I also set the resource name as “Work Resource.”

Going back into Access, that looks like this:

Note that I now have a new unassigned assignment against the project summary task.  Not quite sure what’s happening there, but maybe I’ll come back and take a look at that in a later post.

Going back into Project, I make sure that the Actual Costs Are Always Calculated by Project option is unchecked.

Now I manually set the Task Actual Cost to $5,000.  Let’s take a look at what that does in Project.

First off, we see that the Actual Cost was allocated to the Work Resource.  I now see an Actual Cost of $5,000 on the resource – although the amount was not decremented against the Remaining Cost, so now I have a Total Cost of $15,000.  Fixed cost is still $10,000, so we can see that Fixed Cost + Variable Cost = Cost, or $10,000 + $15,000 = $25,000.

But let’s say that I don’t want the Total Cost to go up.  I want the Total Cost to remain the same.  Perhaps work was performed ahead of schedule.  Perhaps my resource incurred extra costs.  For whatever reason, I want to manually adjust my Actual Cost, but keep my Total Cost at the original $20,000 estimate.  So I change Total Cost to $20,000.  Interestingly enough, the Fixed Cost was decremented to $5,000, and the resource Cost remains at $15,000.

This means that any adjustment to the Task Actual Cost gets applied to the Resource Cost, whereas an adjustment to the Task Total Cost gets applied to the Task Fixed Cost.

Drop it into Access and here’s what I see.

This is where things get interesting.  Let’s try this on a task with no Fixed Cost.  I again assign my $1,000/d resource.

I set the Actual Cost to equal $5,000 and reset the Total Cost to equal the original $10,000.  That yields this:

See how the Fixed Cost is now suddenly showing a negative number?  That’s a bit weird.  The numbers all kind of work out, although now my resource is showing with a cost of $15,000 whereas before he only had $10,000.

Going back into Access, we see this:

So again the Actual Cost is added to the Remaining Cost for the resource.  When we modify Task Total Cost back to the original value, the offset is booked to the Task Fixed Cost, i.e. the reduced Task Total Cost appears as a negative value in the Task Fixed Cost.

Preliminary Conclusions

Based on these experiments, I might draw the following conclusions about projects where the setting Actual Costs Are Always Calculated by Project is unchecked.  The following assumptions are made based on a process where the user manually enters (or imports) Actual Cost data and then manually enters (or imports) Cost data to correct for the offset, i.e. a two step process.

1. The Task Cost field will be accurate.
2. The Task Actual Cost will be accurate.
3. The Task Remaining Cost will be accurate.
4. The Task Fixed Cost field will be incorrect, as it is adjusting for the Actual Cost number that was manually entered.
5. The Resource Cost field may be incorrect, as it will include the Actual Cost manually entered plus the Remaining Cost.
6. The Resource Remaining Cost field may be incorrect, as it will include the Actual Cost manually entered plus the Assignment Total Cost.

EVMS Implications

Thinking through the implications of this phenomenon on EVMS calculations, I find that it looks like EVMS will no be impacted.  Here’s a quick rundown:

 

1. BCWS (PV) – is calculated based on the baseline cost values.  Presuming that the project is in fact baselined prior to manually editing Actual Cost fields, this value should still be valid.
2. BCWP (EV) – is also calculated based on the baseline cost values.  Presuming that the project is in fact baselined prior to manually editing Actual Cost fields, this value should still be valid.
3. ACWP (AC) – In theory this could be impacted by these values, insofar as the negative value in the Fixed Cost field may offset the Actual Cost incurred during the performance of the task.  In reality, this does not seem to be the case.  When I plot the projects out using the EVM Over Time Report, the ACWP appears to work fine.  I don’t see any of the negative values appear in the report.  It would appear that there is some logic built into the tool to preserve the ACWP values on tasks marked complete with negative Fixed Costs.  If needs must, I may revisit that specific mechanism in a future post.

Next up….how does this phenomenon impact tasks with multiple resource assignments?