Time tracking by developers promises a strong return

Question: Why report internal development time?
My company recently implemented time reporting for the internal development staff. I used to work for a consulting company, and we did time reporting to bill the customers accurately. But what sense does it make to report time for internal development? I’m afraid this is some accountant’s idea of a good thing to do, but no one is going to use the information.

Barry T.

Answer: To efficiently allocate internal resources and services
Barry,

Every company that has a consulting or professional services organization is familiar with time reporting. It only makes sense that if you provide services to customers on a time and materials basis, you need to accurately track and allocate your time for them. Some organizations also require time reporting for their internal development staff. It makes sense for the same reasons it does for external customers.

First of all, IT development and support tend to be focused on specific business units. For instance, implementing an Accounts Receivable application is usually done on behalf of the Finance Department. An application to track ad campaigns is usually done for the Marketing Department. Contrast this with an IT infrastructure project to upgrade the communication lines. Solutions like that usually help the entire company, not just one business division, and are not nearly as easy to allocate effectively.

Benefits of time reporting
Since it’s normal to align business units with IT development and support, time reporting has a number of benefits:

• You will know exactly where money is spent, and management can determine if the allocation is appropriate. For instance, you may find that too many of your IT development dollars are spent supporting internal parts of the business, like finance and accounting, and not enough on revenue-generating business units.
• You can gather more factual information on what developers are working on. For instance, on a support team, you can define time-reporting categories for fixing abends, correcting bugs, answering user questions, working on enhancements, and so on. On a development team, you can report time by phases, such as planning, analysis, or design. Knowledge is power. If you know how your developers are spending their time, you have the power to make changes if necessary.
• You can hold a fact-based discussion with your business units on the development and support effort hours (and labor costs) allocated to each of them. Business units will have a clearer idea of the time demanded for development and support of their application. For example, you can tell them you spent 1,500 hours supporting their applications, 2,500 hours working on their requested enhancements, 500 hours on project #1, and so on. If their budgets are reduced, you’ll know exactly what the consequences will be and what they can expect for their budgeted dollars.

Expect cultural resistance from the developers
The biggest drawback is a cultural one, but you shouldn’t ignore it. From my perspective, developers hate to report their time, especially if they’re not used to it. You must be clear about the value of time reporting and how it justifies the additional effort to track and report their time. The process shouldn’t require heavy administration. There should be some level of accuracy, but it doesn’t have to be exact for an internal allocation. If you receive 90 percent accurate information, you should be ecstatic.

I’ve seen time reporting at a couple of extremes. In one company, the internal business units were actually charged back based on the work performed for them. Detailed time reporting was entered into a tool and interfaced with the financial applications to support an internal chargeback. In another organization, each developer reported his or her time on a monthly basis at a high level for each business unit. This was less burdensome on the developers, consuming maybe 10 minutes per month, while still providing a means to allocate and measure the resources applied to each business unit. Of course, it was less accurate, but it was close enough for internal reporting purposes.

Time reporting adds value, knowledge, and efficiency
Many companies ask their internal IT staff to report how they spend their time. If your company is one of them, hopefully it’s putting the information to good use. IT development and support can be aligned to internal business units because the internal organization receiving the benefit is easily identified. It’s more difficult with IT infrastructure or enterprise projects since such work benefits multiple business units or the entire company.

Even if you don’t allocate an internal chargeback to your clients, time reporting gives you the facts you need to get a handle on exactly where your IT labor hours are being allocated. Perhaps the biggest problem with time reporting is cultural—developers don’t like to do it. The CIO or Head of Development should sponsor the change. Don’t overdo it, though. High-level time reporting can add tremendous value, but the more accuracy and detail you require, the more you’ll encounter resistance from the developers—and encounter the law of diminishing returns as well.