What is Sticky with Cost Rates?
Recently I have heard a story about a rather large digital transformation project.
As those types of projects are mostly people, let the number of resources used to speak for its size: 120.
Around 1/3 of the people on a project were contractors and the remaining 2/3 were own resources.
Preparing any cost outlook with this monster was a challenge on its own.
But the biggest challenge was that for own resources cos rates were classified information.
And I don’t mean there was a small group of people who knew it. No, it was simply not available to anybody on a project.
There was some logic in it.
The main argument was cost rates too much resemble salaries to be disclosed per person.
How the project managed its financials, later on, this post.
This whole story was bringing me to rethink completely the 'cost rate' topic.
Me, spending most of my carrier working in project delivery – cost rates are fundamental project information, which drives outlook, schedule, billing, …
So, let’s put some subjective perspective on a topic.
Where the Cost Rates Information Comes From
The easy case is contractors, as they always provide time and rate, the financial information is given and visible.
Regardless of if contractors are employed by the end customer or supplier company the topic is the same.
Even if the contractor is changing on a project the transparency of its cost rate remains. We exactly know what it will cost us.
Talking about own resources there is a completely different story.
The cost rate has to be calculated somehow.
In principle there are 2 methods:
Fully Loaded Cost – where cost rate is all cost of the given person, incl. salary, bonus, benefits, admin overhead, IT/Office cost.
More complex calculation more accuracy and less resemblance to salary information.
I could see companies that have 1 flat rate of all internal resources regardless of seniority.
And it is fine as all processes use that cost rate: cost outlooking, purchase orders, billing.
Blended Rate - this is in principle a fully loaded cost of all people in a unit and calculated average rate based on this.
There are also all the flavors in between. If you define a blended rate for different roles like junior, professional, senior, executive. And this is most commonly used in my experience. In this case, the cost rate is not much related to somebody's salary. But rather indicate seniority in the organization.
Each way to go there is some accounting exercise to be done to define cost rates.
For any project supplier type of company, this is “bread and butter” as they live out of it.
But if the company's main profile is something else than projects – defining rates is a real challenge.
"For any project supplier company defining cost rates are “bread and butter” as they live out of it.
But if the company's main profile is something else than projects – defining rates is a real challenge "
Coming back to our case from the beginning. What was a method used there?
People's rates were calculated as fully loaded cost.
And the component of the fully-loaded rate was mainly salary, bonus, and benefits plus some uplift as this was the easiest method.
No wonder there was resistance to show it on resource level.
But those rates were not visible to the project. Each department/unit (from where resources were coming) providing the resources at the same time provided a total sum for all people as of financial year.
I would say very accounting, but not necessarily project friendly approach.
The result was, it was very hard to manage costs outlooking.
Only simply by the fact that a number of people and names of people changed on the project every week.
And the number provided by the organizational accounting unit was relevant for no longer than a month.
The other issue was defining purchase orders for those resources. But this is another story.
How to Manage Cost Rates Securely
The lesson from this case is there is no way to manage properly project costs if this is not done on the resource level.
It is even more challenging in large projects where people change all the time.
Coming to the main question: Can or cannot we have a cost rate?
The more appropriate question is how to store it securely so only those who need this information to run the project can access it.
Many organizations do it in the office shared environment where worksheets are used to maintain the information. And this expensive solution.
Additionally, any shared files are prone to be corrupted or broken formulas. Sometimes it could be a nightmare.
Certainly, risk buffer and process to execute it are not needed anymore. And funny enough never used at the same time.
Final Conclusion
Cost rates are not easy topics, but they must be defined if we run a large project or program regardless of, we use our own or external resources.
If cost rates are sensitive information as they resemble salaries, they have to be stored in a controlled environment.
Pricell.io is a perfect solution for projects and programs which can store and manage rates globally for projects and programs. The access is defined by the group owner, and it is a very controllable environment.
Not to mention that it does not break under a shared environment.
