If you’re like most application development managers, you live and die by your weekly project status reports. While there are lots of ways to track progress, most managers and team leaders concentrate on how their staff is doing against previously defined project deadlines.

In other words, will the project be done on time?

That is certainly an important metric. However, it’s not the only measurement of developer productivity. In fact, looking exclusively at deadline performance can give you a misleading view of how your staff is doing. In this column, I’m going to borrow a concept from consulting firms and suggest that you use another metric to balance your focus on project deadlines.

The intricacies of being billable
I know a guy who used to run a decent-size (100+ employees) consulting firm specializing in Microsoft technologies. One day at lunch, as we were talking about his business, I asked him to name the single most important metric he used to judge the health of his business. Was it the previous 30 days’ billings, I wondered, or perhaps the future value of projected billings?

He shook his head. “The most important statistic for me is the average percentage of my staff’s time that is billable.”

At first, I thought he meant that he took the total amount of outstanding work (expressed in hours) and divided it by the total number of hours that his staff worked in a month. To my mind, that was an interesting way to look at it, but it wasn’t really that different from looking at the aggregate projected billings.

Turns out I was wrong. A lot more goes into calculating a person’s percentage of billable time than just client demand.

For openers, consider the skills an employee brings to the table. For a consulting company, matching staff skill sets against client demand is a huge job. To take just one obvious example, think back to the early 1990s, when Novell still owned the networking market. In that environment, a consulting firm could keep its CNEs (Certified Novell Engineers) working all day every day, due to market demand. However, over the course of the decade, Microsoft started taking more and more market share from Novell. There was still plenty of networking consulting work available, but more and more of it was based on Windows NT and Exchange. A CNE who hadn’t bothered to upgrade his or her skills to include Microsoft networking technology suddenly was no longer billable, regardless of how much work the consulting firm had.

That is why my friend placed such an emphasis on keeping his people current in the latest technologies. (Of course, the fact that his firm was also a Microsoft ATEC [Authorized Technical Education Center] meant that training was easier and cheaper for his firm.) This regard for training meant that he allocated a certain percentage of what would otherwise be billable hours for training. He considered it a good tradeoff—taking a short-term hit to billable hours in exchange for more sustainable billings down the road.

Experience also played a role in determining a person’s billable percentage. Take that CNE again. If he or she was learning Windows NT, then he or she could become billable, albeit at a reduced rate.

Another factor my friend had to consider was location. Since he had engineers working in four cities, mapping the people on staff to the client locations was a big deal, and it affected the staff’s billable-hours ratio.

What does this mean for you?
While you might not be running a consultancy, looking at your team’s percentage of billable hours is a useful metric, even if you don’t charge developer activity to external and internal clients. Here are some points to consider:

  • Workload: Development shops that look at project completion dates without reference to developer workloads are only seeing half the story. How many hours a week do you expect your developers to work? Is hitting your deadline worth forcing your team to work 60 hours a week? In the short term, you might think so—and you might be right. Over time, however, a project schedule that requires developers to work at 150 percent of billable hours (another way of saying 60 hours a week) is simply not sustainable.
  • Skills: Are some of your developers swamped while others languish on documentation or maintenance projects? Looking at your staff’s billable percentages can indicate gaps in important skill sets.
  • Training: Most organizations say they have a commitment to employee training. Do you back up that commitment by actually devoting billable hours to employee development? Of course, not all of that has to be formal training. Allocating some time to developers for self-taught learning can also be valuable.
  • Meetings: How much billable time does your team spend in meetings each week? Now, meetings can be useful—better to spend an hour in a client meeting and really understand the project specification than to guess what the client wants and waste two days of coding the wrong thing. That notwithstanding, calculate the amount of billable time your team spends in meetings each week; it will probably surprise (and depress) you.

As you can see, complementing your emphasis on deadlines with a view toward developer workload and time management can give you a better perspective on your team’s efficiency. Of course, some developers don’t like having to account for all their time—but that’s a topic for another column.

Racking up those hours?

How much of your staff’s time is billable? Post a comment to the discussion below or drop us an e-mail.