In this post I provide an excerpt from my members-only post, Create a Culture of Excellence With Compensation Plans.
Engineers are great at fixing problems, but they are notoriously bad at tracking their time, which ends up costing thousands of dollars in lost revenue, along with a whole host of undesirable consequences.
The solution to that is implementation of time tracking PSA (Professional Services Automation) applications (I have my favorites, if you ask me in the forum I’ll tell you what they are) that capture engineering time, and allow for more accurate billing.
Because engineers typically hate tracking their time, many service providers resort to building a compensation plan that requires a minimum amount of billable time to be entered into the tracking system, and rewards the engineer for billing more than the minimum hours.
On the surface, this seems like a great solution to the problem – your engineers now enter their time, you capture more billable revenue, and they make a little extra money.
There are several problems with this method, however:
- Your engineers have no control over whether they will have hours to bill
- It pits engineers against one another
- It’s 100% contrary to the goal of managed services
- Billable Time” is extremely difficult to track accurately
- Your engineers are focused on a one-to-one ratio of hours worked/hours billed
Focusing on the number of billable hours worked is difficult because your engineers really don’t have control over whether they have hours to bill. They don’t know when a customer is going to call with a problem, and they don’t have the ability to directly bring in new business.
This leads to engineers taking as much time as they can to get a job done, just to meet their hourly quota.
For example, if an engineer is required to account for 30 hours of billable time each week, and he is assigned to work on a fixed-price project that could be finished in 3 days, but was estimated (and priced) to take 5 days – he’s more likely to take 5 days to do the job, exceed his number for the week, and take the bonus as opposed to finishing in 3 days and risk not meeting his number.
This strategy pits engineers against each other, and leads to fighting over who gets assigned to projects, who does the quick jobs, and who gets stuck doing “customer service” work, to name a few.
Tracking by billable hours is 100% contrary to the goal of managed services – you don’t want your engineers spending unnecessary time on your managed services clients. Imagine the problems you’ll have when you mix an “unlimited” support contract with a compensation plan that rewards employees for the number of “billable” (i.e. customer-facing) hours they have.
It’s extremely difficult to track “billable” time accurately. Your PSA can give a report of the number of billable hours worked, but you have to manually keep track of who did what, and when. For example, if Joe goes to a customer, bills a few hours, and leaves, he’ll get credit for his hours. But what happens if Joe screwed something up, and Karen has to go back and fix it? Karen’s time isn’t billable, so you have to remember to take the hours away from Joe, and apply them to Karen. But what if it wasn’t Joe’s fault, and it turns out the customer caused the problem? Or what if the customer complained after bonuses were paid, and you have to write off the service – do you take the bonus back from Joe and Karen? – it’s enough to make your head spin, especially as your service team grows.
Tracking by billable hours gets your engineers (and you) focused on a set number of hours, which significantly limits your potential to earn revenue.
In the fixed-price project case above, the engineer benefits more when he works one hour for every hour billed – profitable, yes, but not as profitable as billing 5 days for 3 days of work.
Worse, when you focus on a one-to-one ratio of hours worked/hours billed, you need more staff to increase service revenue.
In my post Create a Culture of Excellence With Compensation Plans I talk about compensation plans, and I offer an alternative suggestion to this problem.