accuracy of escalated rates in payrates table

[Bill F.]

I have a macro that assigns escalation rates and effective dates to rate
tables. It seems that the rates entered in a resource rate table are not
treated internally as a currency datatype but rather are rounded to the
nearest cent. For example, if your enter or assign a payrate of $1.036/h
it is rounded to $1.04/h and 1.04 is the number actually used by MSProject
to compute the resource cost. Does anyone know if/how to increase the
precision on the rates entered into the rate table?

 

[John]

I have a macro that assigns escalation rates and effective dates to rate
tables. It seems that the rates entered in a resource rate table are not
treated internally as a currency datatype but rather are rounded to the
nearest cent. For example, if your enter or assign a payrate of $1.036/h
it is rounded to $1.04/h and 1.04 is the number actually used by MSProject
to compute the resource cost. Does anyone know if/how to increase the
precision on the rates entered into the rate table?

Bill,
First of all, Project is not a financial application and therefore does
not have the resolution for cost information beyond two decimal places.
Second, I find it very unusual to have a pay rate that is not in whole
cents. I know it is very common for stock prices to be in fractions of a
penny but I've never heard of a pay rate with fractional pennies.
Perhaps I'm just out of touch.

The bottom line is the accuracy of the pay rate table cannot be
increased but there are some options. First, you could use a spare
number field to define pay rates and then employ formulas to calculate
cost in a spare Cost field. Not real convenient, but doable. Or, you
could export the resource hours to a spreadsheet application (e.g.
Excel) and then apply a more accurate pay rate. Again, not real
convenient, but doable.

Hope this helps.
John
Project MVP

 

[Bill F.]

Hi, John:

Thanks for the speedy reply. I was afraid that the answer to the question
was as you stated.

FYI - The reason for the fractional pennies is as follows - we are often
asked to present time-phased cost information from our schedules.
Sometimes people want to see cost profiles expressed in fixed-year dollars
and sometimes in then-year, or escalated dollars. My approach to providing
both from the schedule is to use payrate table B to contain escalated rates
with effective dates at the start of each fiscal year, while table A contains
a single rate for the base year. By running a macro that toggles the rate
table used by each resource assignment from table A to table B one gets
fixed-year or then-year costs.

The problem with the fractional pennies crops up mostly because we have some
material resources that have base rates of as little as $1.00 per unit. And
we have escalation factors that are specified with typically 3 significant
figures to the right of the decimal point, for example 1.025. or 2.5% per
year. It is not uncommon for escalation factors to be specified to this
level of precision. When you couple that level of precision in the
escalation factor to a resource with a base rate of $1.00, inaccuracy in the
resulting escalated cost occurs, potentially at the level of as much as 0.5%
in my example, due to the rounding in the payrates that occurs in MSP. For
example, if you assign 100,000 units of this one-dollar resource to a task,
the correct escalated cost would be $102,500, while Project would give
$103,000 a differenct of $500, not a gigantic difference but maybe not
negligible, and one that could be corrected with the use of higher precision
on the payrates.

Of course the potential error, expressed as a fraction of a base rate, goes
down as the base rate goes up, so it usually causes less of a problem It
seems to me that the smart thing for MSP to do would be to internally treat
the data types of the rates in the escalation tables as currency datatypes
which have 4 significant figures to the right of the decimal point and that
would solve the problem. Maybe this is something for the next version!

Bill F.

 

[Steve House [Project MVP]]

As John said, Project is a schedule and cost ESTIMATING program, not an
accounting or financial program. Even it's "actuals" are really usually
only close approximations. Your example of +/- $500 in a 100 kilobuck
estimate may not be acceptable for financial accounting but in a discipline
where +/- 10% accuracy is consdered to be spot-on and +/- 25% is more the
general the norm, such precision would have us all dumb-struck with wonder
at being witness to a true miracle. <grin> No offense intended but I have
to wonder if your organization hasn't fallen into the trap of thinking that
precision in the calculations somehow drives the real world into compliance,
confusing precision with accuracy. No matter how precise your estimate
calcaulations are today of what projected costs several years down the road
will be, I seriously doubt if their accuracy would be even within the
ballpark. You may calculate to 4 decimal precision but I'd wager the real
world accuracy when you get there and compare actuals with estimates is no
better than integer level precsion or worse. There are just too many
variable out there in that untidy real world to take them all into account.
In short, for a project estimate to be within $500 in 100 kilbucks is
incredibly small stuff and a manager who wants to remain sane shouldn't
sweat the small stuff. Even a $10,000 deviation would be close enough for
effective project managment.