Project Time Reporting
Project Time Reporting
Stop Whining and Do It
Project time reporting evokes a passionate response from most team members--consensus is they hate it. Notable software management experts have argued that time reporting is counterproductive, needlessly consumes resources, and encourages behavior inconsistent with good practice. While Payson Hall worries about supporting something so unpopular, he offers some benefits of effective project time reporting and explores some of the common implementation issues that undermine its value.
Consistent and accurate time reporting is a daunting speed bump on the road to better project management for most organizations. If there is one thing that everyone agrees on, it's that they hate time reporting. The passion this subject elicits is amazing. "Do you want us to do work, or spend so much time writing about it that it doesn't get done?" people will snipe. Truth be told, time reporting is not my favorite thing to do either, but I think things are getting a little shrill and silly when people begin treating time reporting as if it were the most time-consuming and unpleasant task of the day. What I'm trying to say is: I empathize, but I don't sympathize.
Let's be clear, time reporting isn't fun-particularly when you have put off doing your time sheets for a few weeks and it becomes a content-free creative writing assignment. This is the worst kind of administrative drill-no use to you or the project manager. I won't justify that silliness, but I will point out that it is a self-inflicted wound.
Tracking the time spent on tasks is necessary for effective project management. If it took an hour per team member each day, we would appropriately worry about the return on our investment. Instead, time reporting should take about ten minutes per person each week. It's hard for me to believe that civilization is going to crumble because we ask people to take ten minutes a week to let us know how they spent their time.
My lack of sympathy for the sniveling may stem from having had to do time reporting to the nearest fifteen minutes for most of the past twenty-five years as a condition of employment. Consulting clients like to know how the time you bill them was spent on their projects. As a result, I spend almost ten minutes each week making marks in my day planner so that I know where my time goes. This doesn't actually add ten minutes to my workweek; I typically make notes in my planner when I'm waiting for meetings to start, or while I'm in the elevator, or when I'm clearing out for the day. It does mean that I invest a minute or two each day in the task, and I must say that it is worth it, both for my projects and for me.
What can you do with reasonably accurate time reporting data? Here is a short list of benefits I've experienced in the real world:
- Improve estimates. Not only does comparing actual hours expended with estimates help me understand when the estimates are wrong, but also keeping track of why they are wrong helps improve estimation models and assumptions for next time.
- Anticipate resource variances. If we track the actual hours spent on a task and compare that to progress toward getting the work done, we get early insights into whether or not a task is likely to finish under or over budget. This gives the project manager a chance to take advantage of opportunities or respond to problems before they are surprises.
- Justify adjustments to resources, schedule, or scope. If a project is having trouble matching its expected pace with the resources available and I can show that the resources are focused and spending quality time on the project, it gives me the data that I need to support discussions with senior management about either getting more resources, modifying the schedule, or reducing project scope.
- Clarifying a problem's priority. When infrastructure issues or policies are consuming a lot of staff time without apparent benefit, I can establish ways to capture the true cost, which helps me build a business case for change.
- Explain the cost of distractions. When organizational distractions are cutting into work time (for example, moving all of the offices from the west side of the building to the east side), it is helpful if I can explain in concrete terms the costs and effect on the project.
- Keeps us honest. I would like to believe I'm a machine that is always focused on the right priority, but I'm not. I sometimes become distracted by shiny objects or fun diversions and avoid things I don't want to do. Promptly recording how I spend my time discourages me from straying too far from what should be happening. Seeing it in black and white encourages me to get back on track
With all of these potential benefits, why is there so much resistance to time reporting? In my experience, it is often the implementation-both how data is collected and how it is used-that leads to problems. Common issues include:
- Time-keeping systems that do not enable/allow tracking at the task level. The time-tracking mechanism (it doesn't have to be a software package-it might be a simple spreadsheet) needs to model work at the level it is planned and performed to be meaningful. This implies that there are credible plans for a project that identify meaningful tasks that were estimated. If this isn't the case, time reporting is not your issue. If you have those plans but your time-tracking system doesn't match it, time tracking is not very meaningful.
- Time-keeping systems that codify unrealistic ideas about how people work. Some organizations have a belief that people work exactly eight hours per day, five days per week and reporting any variation on that theme is a difficult special case or is disallowed altogether. I'm not qualified to argue the finer points of labor law or union rules, but in the real world there are often informal agreements that someone leaving early today for a parent-teacher conference will make it up later this week.
- Organizations that can't handle the truth Some organizations assume that since employees are being paid for an eight-hour day, there must be eight productive project hours logged each day. Logging time to "admin" is not allowed. There is no way to report time spent attending all-hands meetings that aren't related to the project. There is no way to report time spent interviewing potential staff or mentoring them once they are hired. If you insist that people allocate time spent doing non-project work to project-related tasks, you are asking them to falsify data, which communicates that no one is interested in accuracy and that time reporting is "administrivia" rather than a means of gathering useful data.
- Rewards and punishment. If time tracking-data is used to administer praise or punishment then this is a discouragement from accurate time reporting. Organizations that reward people who perform closely to their estimates will discover that people perform more closely to their estimates-by padding their estimates to assure there is more than enough time and padding the task to fit the estimate. Organizations that reward people who log extra hours may get longer hours, but they aren't necessarily productive.
- Dual book keeping. Some organizations have a time-tracking system for the nice folks in personnel/payroll that is not designed to track the details of daily work. Asking people to keep two sets of books (one for payroll and one for the project) is a hard sell.
Project managers (and the organizations they manage projects for) need to know how much resource a project will need, how much it is consuming, and whether or not resources are available as expected. To support this, we estimate the effort required for various tasks. This estimate is the foundation of the business case for the project. If we never track the actuals, how can we report costs and their variance from the original business case and how can we get better at estimation? If we don't know how much time the project is getting from its resources, how can we influence resource allocation and priority?
Time reporting isn't fun. Neither are flossing your teeth or changing the oil in your car. But these things are necessary, so let's quit sniveling and take care of business.



Comments
#1 Submitted by Wayne Mack on Sat, 10/24/2009 - 11:21am.
Although I agree time reporting is a necessary evil to track benefits accrual and leave, and to accurately bill customers, I do not find it is the best way to track project status. The problem is that to accurately track down to the task level, the charge codes are too fine grained and too numerous. Often times, the clear distinctions among tasks and phases on a schedule are actually much muddier during execution and the workers are actually multi-tasking among several line items. The worker's challenge is to be aware of, find, and understand the set of charge numbers on which he may be working (and correctly enter them into the system). Then the worker must try to align the work he is doing at any point in time with the charge codes, try to keep track of task switches, and determine how to map ambiguous or overlooked tasks. The end result is that using low-level charge codes to track tasks and validate estimates does not produce accurate numbers. I find it much more effective to assign charge codes at the highest feasible level and ensure all tasks on the schedule have an identifiable deliverable. Schedule tracking is simply a matter of noting task start and end date and this information is best captured through project status meetings or reporting. Cost information is best tracked at a project level, rather than a task level, allowing the normal ebb and flow and mixture of high and low estimates to take care of themselves. Track EVM at a project level and don't try to use a micro-EVM at the task level. Fine level charge codes do not result in more or better information, they only result in frustration and repeated time card corrections.
#2 Submitted by Bret Pettichord on Wed, 10/21/2009 - 4:23am.
I think some of the resistance comes from ambiguity about how to account for time, and also not really knowing what level of detail to record it to. I'm mostly working on Project A, but attend a status meeting with my manager where I report what I'm doing on Project A, but also hear what projects other people are working on. Do I log the time against Project A or overhead or what?It's an accounting system. If i'm simply reporting what client i will bill my time against that's one thing. (Something that I learned to do with little effort -- like you -- when i was a consultant.) But it gets harder and more arbitrary when the categories get more detailed. Was that last hour testing or debugging or planning or what? Well, some of each.The problem is that a time categorization system that is too detailed will force you to draw distinctions that are really too fine. But it also needs to be consistent or else different people will use it differently and the data collected can't really be used as a source of information for decision making.
#3 Submitted by Kenneth Katz on Tue, 10/13/2009 - 1:58pm.
It turns out that there is a valid reason for two timekeeping systems. Payroll needs to have more detailed information about time off, for example doctors appointments, vacations, sick days, etc. Project management systems do not need that level of detail, and in fact if that sort of information is stored on the system then it will have to be HIPAA compliant, with role-based access and other complexities. So in practices, it is often just easier to have two different systems.
#4 Submitted by Peter Hawkins on Tue, 10/13/2009 - 5:08am.
aaaargggh,Only thing worse than time reporting is chasing your staff that have not done theirs. This article hits the nail on the head. But the advice is like cod liver oil... good for your health but equally unpalatable.