Lots of people have told me that they need to figure out how to make their technicians as "billable" as possible. Somehow in our heads, we think we can get a perfect technician to bill 40 hours a week. Unless the tech works 60 hours, you're not going to get 40 hours billable out of him!
Assuming a full time tech is working 40 hours/week . . . the best you can hope for is about 70% billable on a consistent basis. Technicians check email, sit in on company meetings, do training, watch webinars, etc. If you don't charge for travel both ways, then they spend time driving around unbillable.
I've heard people say their techs are 80% or 90% billable. But every time I hear that, I ask about how rigorous they are at tracking time. Does every technician account for every minute between 8:00 AM and 5:00 PM? The answer is invariably NO. So these folks have an impression that their technicians are super-billable, but they don't even know how much time they are logging on the job every week!
If you track this very carefully, you will discover that it is extremely uncommon for a tech to be more than 65% billable. Now, as we move to doing more and more work remotely, this number increases. As a tech's job moves from little jobs to big jobs, he becomes more billable.
Please see the following posts:
SOP Friday: Running Regular Financial Reports (This covers the ideas and expectations of billability).
SOP Friday: Time Tracking for Employees
SOP Friday: Should You Do Billable Work First?
SOP Friday: Working in Real Time
What Does "Billable" Mean?
Let's begin by defining Billable Work. If you are in the world of break/fix, the definition is easy: Billable work is labor for which you will invoice the client. In this world, there are really only two kinds of work. There is work you give away for free and work you bill for. (Free labor includes rework or other work you intentionally do not charge for. There's a completely separate discussion about all the labor you give away for free because you don't properly track your time.)
In Managed Services, the discussion can be a little more complicated. "Project work" is just like break/fix above. You either bill for it or give it away. But with Managed Services, you have work that is covered by the service agreement. For example, all work to maintain the server might be covered. So checking the logs, applying fixes, and verifying that there's plenty of disc space is all covered work.
For our purposes, productive labor covered by a service agreement is considered billable. Rework and floundering around unproductively trying to figure something out should be considered un-billable here as well, but it's very hard to track. The key point here is that "billable work" under a MSA (managed service agreement) includes work to fulfill the agreement. It is "time on task" and you will not invoice the client for it separately.
See the pie chart. Of course your numbers will vary.
The chart represents an example of how time can be divided in a week. We start with 40 hours. Fifteen hours is "overhead" time (light blue). This represents meetings, training, driving, etc. as discussed above. This number will be larger for managers and smaller for dedicated technicians. Just remember that it can only get so small. So be realistic.
Another fifteen hours is work on covered machines (purple). This includes whatever you have in your MSA. Two hours are rework (red). Another three hours are otherwise unproductive (orange). This unproductive work includes things like standing around waiting for another technician. Most commonly, it represents working on a problem and making no headway. This happens when you (your tech) bang your head against a problem for an hour or more and make no progress toward the solution.
Finally, we have five hours of truly billable labor. These are hours spend on Add-Move-Change tickets and billable project labor. For MSA clients, this is work not covered by the MSA.
When I say we want to maximize billability, I mean we want to increase the time spent on Covered Labor and Billable Labor. These are at about 50% of hours for the week. This is a very realistic number.
The Overhead time might be different for different roles in your company, as mentioned above. But it probably doesn't vary much for an individual over time. So if Joe spends 15 hours a week on Overhead, you cannot expect to squeeze much time out of this area.
That leaves two key areas for increasing billability: Reduce Rework and Reduce Unproductive Labor.
Reducing Rework and Reducing Unproductive Labor
So our culprits boil down to these two categories. You might be tempted to lump them both together under Unproductive Labor, but Rework really needs to be separate. Unproductive labor may not be related to competence. Rework means you (your tech) did something wrong and then they (or someone else) had to go do the work again. This is very often related to training, competence, and experience. You absolutely have to minimize rework.
Here are six things you can do to minimize these categories and increase billable hours.
1. Work from Highest Priority to Lowest
This starts with assigning a priority to every single ticket or task. Everything in your company needs to be prioritized. Low priority tasks might be easy or even fun. But you have to be disciplined to work based on priority level. Search this blog for "priority" and you'll see lots of articles about why priorities are so important.
A lot of the low priority items fall into the category of Urgent but Not Important. Clearing up high priority tasks often clears up some smaller tasks that were related to the issue. It also guarantees that techs are working on the most important things. It is rare that high priority tasks are not covered under an MSA or truly billable.
2. Schedule Work, but Schedule it Loosely
The most productive work is planned. Time and time again I have to coach people that it's okay to tell a client that you schedule work two or three days out. Projects might be two or three weeks out. If you can plan to tackle specific jobs on specific days, you can organize the work and prepare for it. You can have the right tools and research.
Reactive work is always less effective. You jump off one task and onto another. That action automatically reduces the effectiveness of your work on the task you are abandoning. And because your work on the new problem is completely unplanned, you are less productive on that as well.
Here's what happens to the task you abandoned: When you go back to it, you have to figure out where you left off. It will take some time to come up to speed. Remember, you WERE up to speed on the problem when you abandoned it. The time spent coming back up to speed is not rework, but it is certainly unproductive labor - and unnecessary.
I say to schedule loosely because it gives you flexibility. Tell clients you'll be there on a specific day. If you need to, say morning or evening. As a general rule, that's much better than agreeing on a specific time. Specific time slots mean that you might have to stop doing one job to go do the scheduled job. See previous paragraph. It also means that you might have a time gap between jobs. Totally unproductive time.
In a perfect world, you won't rush from one emergency to another. You'll plan things out a day or two in advance. For each task, you'll complete it or come to a natural stopping point. Then you'll move on to the next task, minimizing the unproductive gap between jobs.
3. Develop and Encourage Specialization
For any given hardware or software, you will have a specific level of knowledge. Ideally, your team will include a variety of people with a variety of skills. If there are any products you consider critical to your success, you should have someone who specializes in the product. If this person is not on your team, then you should make sure you have access to them when you need them.
It is pretty obvious that someone with specialized knowledge will fix things faster. This reduces time spent floundering around trying to figure things out. Of course, once you solve a problem, you should take time to put notes in the ticket so you can replicate your success.
4. Call for Help
You should have a policy in your company that no one is allowed to work on a problem for very long without making progress. You might decide the limit is 15 minutes, 30 minutes, or even an hour. But at some point, they MUST call for help. They might call their manager, another technician, a friend at another company (if appropriate), the vendor's tech support line, or anyone else who can help.
In addition to a "fresh pair of eyes," calling for help immediately limits the amount of unproductive time that can accumulate in your company. You might even have lower limits for newer techs. Of course everyone should be using a Troubleshoot and Repair Log (TSR) to keep track of what they've done.
A TSR Log will allow other team members, or third party tech support, to come up to speed very quickly when you call for help. Many young techs refuse to call for help. Then they end up spending countless hours on something that another person might have fixed right away. Or perhaps the problem was known but undocumented, so no amount of research would reveal the fix. It takes a certain maturity and self confidence to say that you don't see the answer and need help.
Interestingly enough, more experienced technicians tend to ask for "help" all the time. It is often the fastest path to success. We all have different experiences and perspectives.
5. Make Minimizing Rework a High Priority
There are many causes to rework. Making it a company-wide priority to minimize rework will have a dramatic effect. First, it makes everyone aware of the need. So team members can enforce the goal of minimizing rework and help each other out. Second, it will make it easier for technicians to ask for help.
Third, making this a priority will lead to other actions that are good for your company overall. Without knowing anything about the specific rework, you can guarantee that it is related to either poor planning or lack of training/experience. So you need to make sure you have adequate training programs. These can be internal. In fact, sometimes internal training is the best because you can go at the student's pace, and you know the training is on YOUR way of doing something.
Planning is obviously good for any project. It is particularly good for avoiding rework. If you slow down and plan your work, you are much more likely to proceed from start to finish without retracing your steps.
6. Documentation is Your Friend
You knew I had to throw this in the mix. Documentation includes procedures and planning. It includes TSR Logs. It includes putting all of your notes and hours in the PSA. It includes using checklists - and only checking each box after the task is complete.
When you know exactly what you have done and not done, troubleshooting becomes a lot easier. Ideally, you should be able to read through the notes on a ticket and come up to speed very quickly on the problem and what has been tried so far.
If the client has a similar problem in the future, you'll have the answer at your fingertips. If other clients have a similar problem, you'll still have the answer at your fingertips.
Final Thoughts
What do we do for a living? We implement, maintain, and troubleshoot. Implementation can be very efficient with proper planning. But it's not perfect. Maintenance should be very easy, but it's not perfect. And troubleshooting is certainly not a perfect science.
So it is impossible to totally eliminate rework or unproductive labor. You can minimize it. But you can't eliminate it.
Maximizing billability, therefore, is also not a science. It takes constant attention and effort. It takes proper training and a company-wide ethic of reducing unproductive labor. (Note that training is time spent in the "overhead labor" category.) This is not something you can implement and walk away from. Maximizing billability is a never-ending job.
It relies on excellent time tracking, excellent documentation, excellent planning, excellent training, and excellent teamwork to support each other to eliminate rework and unproductive labor.
Comments welcome.
- - - - -
About this Series
SOP Friday - or Standard Operating System Friday - is a series dedicated to helping small computer consulting firms develop the right processes and procedures to create a successful and profitable consulting business.
Find out more about the series, and view the complete "table of contents" for SOP Friday at SmallBizThoughts.com.
- - - - -
Next week's topic: Voicemail Passwords, etc.
:-)
No comments:
Post a Comment
Feedback Welcome
Please note, however, that spam will be deleted, as will abusive posts.
Disagreements welcome!