Actual Cost Calculation - different in table and task usage view

• Question

• The task has a duration of 12 days and a fixed cost of \$20000 only (no resources, no work), and the 10th day is the last day of January 2013. The status date is end of the last day of January. The task is all on schedule so mark on track, making 10 days actual duration and 2 day remaining duration so the % Complete is 10/12 or 83.33333333333333333.....%, except we know MSP has no decimals in % Complete and rounds to 83%. In the tracking table the actual cost is calculated by 0.83 x \$20000 = \$16600.00. But we know it should be \$16666.67, and that's what it shows in the task usage view (display cumulative cost and actual cost). So the task usage view is reliable but the actual cost field in the tracking table is not. OK, I put up with MSP foibles and I like it despite its faults, and I can live with that. But try explaining or showing it to someone and not leaving a bad impression about the software. Maybe MS development team should have spent some attention on this instead of those klunky pivot tables and eye candy in the visual reports.
Monday, January 7, 2013 10:32 AM

All replies

• Fractions have never truely been managed well in computers and project is not really an accounting system, so costs will not be accurate to pennies.  Keep in mind that project management is a system of estimates and project professional is a tool to help monitor the schedule and cost, but isn't going to be exact to the penny or the day.

Cheers!

Michael Wharton, MVP, MBA, PMP, MCT, MCTS, MCSD, MCSE+I, MCDBA
Website http://www.WhartonComputer.com
Blog http://MyProjectExpert.com contains my field notes and SQL queries

• Proposed as answer by Wednesday, January 16, 2013 12:29 PM
Tuesday, January 15, 2013 5:50 AM
• Except Trevor does have a point: The tool should be consistent. Rounding is OK provided the same result is used everywhere.

Rod Gill

Rod Gill Project Management

Tuesday, January 15, 2013 9:27 PM
• Hey Rod, thanks for the support.
Wednesday, January 16, 2013 5:51 AM
• The problem here is in setting fixed cost's accrual to prorated and in comparing the sum of the timephased prorated actual cost to totals on the left. Why don't you do the same test with a single resource assigned to the task at a standard rate of \$1666.67/day.

The precision is consistent in both displaying the numbers and calculating on the background. This behavior is
exactly what I would expect from MS Project. MS Project is excellent when it comes to consistency unless we treat it as a calculator.

This is just my own opinion...

Wednesday, January 16, 2013 12:28 PM
• Yeah this is really sort of a problem.

This problem of calculating (rounding I guess) percentages differently than decimals also affects timephased task work, not just costs. This makes vertical integration of task data (columnar data) not match up with the totals on the timephased cells. And you will find yet different results when comparing to PWA and visual reports too. To be really fun, it also changes depending on the timescale you choosse for the timephased data also. I did this experiement and posted here the oddness in an earlier post. It is the management SW that we use to report to the government our plan, progress, EV, etc. The government does not like loose ends or discrepencies and having to explain "its the SW" is not fun for the customer or the PMO.

I am with Trevor, let's get this nailed down and handle the data consistently.

If you do not have such stringent requirements that is fine. And while I may not care if the timecard feature does not total data accurately, I would not chime in and suggest that this is not a SAP application, so it does not matter, or you are expecting the SW to do too much. If it does not tie-up data totals (in this case vertical versus horizontal) then that's a problem. If the vertical dates on the summary bar (ie, start and finish columns) did not match the Gantt bars (horizontal) roll-up dates of the tasks under it, maybe by only a day, would this be considered ok?

I am not wanting to cause an argument among users. But I would like MS to address this.

Tuesday, January 29, 2013 8:53 PM