Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
My company recently introduced time sheet logging for each individual in the development team. To be honest, it is quite time consuming. Each member needs to log what they have done each day.
They mentioned that the purpose of this is to provided a history of a project plan for later reference, but sometimes they will say "Let's check what you have done recently." It feels like we are not being trusted.
In general, logging is a symptom of a non-agile development process that proxies for a project manager's active engagement and situational awareness. It is also often a sign that the project is measuring the wrong thing, since "time consumed" is rarely a valid measure or predictor of results. When not used solely for contractual billing purposes, it is most often improperly-used as an accountability or root-cause analysis tool.
Results-based tracking is generally more effective. For example, in Scrum a story is either "done" or "not done" at the end of a Sprint. How much time was spent doing what task inside the Sprint is largely irrelevant, although blockers and queuing issues are certainly valid topics for a Sprint Retrospective.
Tracking time is useful for billing purposes, and ostensibly for future estimates. In reality, though, time sheets are either a work of fiction or needless overhead.
In manufacturing, it can certainly be worthwhile to document that it takes x minutes to produce y widgets on an assembly line. However, in knowledge work like programming, work rarely breaks down neatly into measurable increments. In addition, programming in particular is often about thinking about the right problem to solve, so overly-granular record keeping that isn't a complete work of fiction might look like:
If the log is kept meticulously and honestly, at the end of the day the time simply won't add up to 8 hours due to task switching, overhead, and (of course) the time spent time-tracking at a granular level. That makes the log less useful than managers might like to think.
Sensible time-keeping tends to be less granular. A sane log entry might say: "I spent 6 hours today working on the foo project, and 2 hours in meetings, time-keeping, and other project overhead." However, this type of high-level logging is often imperfect due to cognitive bias, errors of omission, social filtering, and other factors that make it largely useless as a valid measurement.
Agile frameworks like Scrum implicitly support a results-only work environment. While ROWE itself is a buzzword and marketing term, the concept of measuring results (e.g. Was a target met or not?) is generally more useful than measuring minutes-per-task. Again, sectors like manufacturing that need to measure throughput may actually need timing data, but rarely do they need timing data of the sort collected by the time sheets you're describing.
Focusing on whether tasks are "done" or "not done" is a significant culture shift in many organizations. It requires trust between upper management and the development team, and a commitment by the team to be transparent about estimates, impediments, and missed targets. Without that trust, and without that culture shift, most organizations simply fall back on useless metrics like time accounting.
If your organization isn't willing to make that cultural shift, and if you find granular logging disruptive or burdensome, then you can try to evangelize a more agile approach. More likely, though, it's simply time to brush up your resume and look for an organization that is less steeped in failure.
I have worked in organizations that track time to 15 minute increments and those that don't track time at all.
From a PM perspective I greatly prefer the former, because it is next to impossible to objectively estimate future effort if you don't have history of actual time spent. In my current organization we have to go through all sorts of contortions to figure out how many projects can be implemented, how these are to be prioritized, etc etc. It would be much easier to start a conversation on project prioritization if we could go to our leadership and say "We have XX warm bodies, in our experience we can successfully execute YY projects with that level of staff".
I second David's thoughts on this one. I had to do time logging for 8 years - first down to half an hour then to an hour - and the only time when it was "painful" when I helped somebody else on a matter I had nothing to do with, therefore I was unable to log any hours there.
From the project's perspective it has some benefits, because the team/PM will know how much effort has been put into the project, and see whether they are still on the budget or not.
This can be also a helpful data for leads to see who are involved in many things and help to reduce the pain context switching causes.
Team mates argued a lot that it took them too much time fill out, and when we actually measured it was about 10 minutes on a Friday to do for the whole week. The second argument was about trust as you've already mentioned. I have met only one PM that used the time sheets for figuring out what the people were doing - instead of going there and see by herself -, others tried to fix problems. There weren't that interested in the details either. Engineers spent a lot of time on filling the sheets out very precisely, which they were never asked to do. The PM was interested in the rough numbers just to see where the project is.
Like others here, I had to track my time to the 1/4 hour level for years as a consultant. I hated it at first but learned to embrace the effort because of the information it provides down the road. Don't neglect the comments!
As as developer I have to say I agree that this can be a pain in the arse. It's fine if you are assigned to a single project, or the chunks are large, say a day on this a day on that.
The problem occurs when you have to work on multiple random things in a single day and they just don't fit into the nice ordered time keeping system that's been set-up.
Say for example I'm on a BAU team, implementing features from a scrum board. I have my task for the day and I can assign time to it no prob. so I'm working away and manager Bob comes up to ask me about a possible bug a user has reported. Its probably nothing but can I investigate? Then developer Jim wants to ask me about some code I programmed last week, Sales Jane ask, can I goto a meeting to discuss the interface for new customer Z? HR Sam can't upload his spreadsheet to internal tool Y, can I run off a quick report on something from the database? etc etc
"But!" you say, we are doing scrum/kanban/agile of the week! you should say "No!" to all these things and and the Scrum master to intervene writing up tasks and prioritising them!
Unfortunately the practical effect of this is forces developers to choose between being 'scrum police', working overtime, having hours which don't add up on the system or 'rounding up' those hours.
Additionally business tend to rely on this "Shadow IT" pushing devs into being 'unit of work style, only do tasks on the board' machines puts a huge pressure on project managers and BAs to correctly spec those tasks, leading to a waterfall style approach. exactly the opposite of what the business wanted.
I would venture to say that those who think they're not being trusted likely have something to hide.
Collecting data on a daily basis is important in both measuring performance against your cost and schedule baselines as well as inputs into future projects that are similar. It is done daily in order to increase accuracy and precision because, if done weekly, then most likely the data is a best guess, which makes the data useless. Workers should capture as accurately and precisely as possible the hours worked against a particular work package.
We all capture our time, from laborers who clock in to professionals who log hours to bill their clients.
It is absolutely necessary to manage projects and business. If this offends you, take a long hard look at what you might be hiding from your boss.
