It's open source! https://github.com/entp/xtt
We used it extensively when we were mainly a widely distributed consulting company (4 countries, 4 US states, 20 devs) and continued using it after we dropped the clients. It's useful to see the hard costs of building certain features and even entire apps; there's also a ton of useful data about how many hours people are pulling a week, what time we show up for work, as well as the basic "what are you working on?"
However, the dev team is pretty small right now so we have ditched the time tracking. We are moving to a new tool that we're building which focuses more on how you feel about what you're working on.
Far better in my opinion to focus on end results (feature X will be ready by date Y) than micromanaging progress by tracking time and assuming that this linearly corresponds to progress made.
Knowing how long things took vs estimates is useful for determining the accuracy future estimates.
Having an absolute sense of numbers for types of projects is useful for estimating future projects of similar scope; where by absolute I mean, not, "I think it took two weeks last time we did this".
Of course, it's a good idea to investigate why expected timescales differed from expectations - but IMHO detailed time recording isn't the way to do that.
Of course, YMMV.
Also, if you're measuring and refining your estimates, they stop being 'estimates' and become something far less useful. If you have problems with estimates being inaccurate, try not estimating.
There are far more interesting metrics to measure rather than flogging a dead horse.
Unless your billing on an hourly basis, chances are that counting hours is too much micromanagement.
Time tracking is required for any company that bills clients by some unit of time (or bills another department within the same company for services, which is fairly common for large companies). Even if part of your workday is not related to external customers, once you are "tainted" by the time-tracking clause, you have to track all your work hours. For example, I myself work on a product as a developer, and only a small part of my time is spent directly servicing customers. Even so, all my work hours have to be logged.
I am allowed to log all my internal hours as one block if I want, but the manager guys like seeing how/where our time is spent, so they want us to log our work hours as finely grained as possible. We are a small 15-person company, so it feels a bit weird, but it's not a huge bother. We currently use Harvest, which is not a good app for managing a project, but is a very good app for invoicing.
The whole law is probably related to some EU directive, but I don't know the specifics.
Of course, a lot of people simply opt out!
1) Make it as frictionless as possible for the people tracking their time, or you will inevitably have people not doing it, and then someone has to hound them, and then they just put in junk data just to stop the hounding. Your "to the hour" metrics end up just being junk.
2) If you aren't actually using the data, don't make people track their time "just in case". Or at least assign it a real cost, and say, "Is this data worth 2% of my payroll to me?" In poorly run companies, this tends to be a classic example of management wasting the employees time for no reason, just because someone said they were supposed to do time tracking but management never gets around to using the data for anything.
It's complicated by a couple of factors:
* nobody else at work would be using the same system (but we don't use anything anyway)
* I don't use emacs for mail, and haven't yet got it to talk to google calendar in a sensible fashion
* my elisp is about as good as any of my other lisps, which is practically nothing.
On the plus side:
* Evidence based scheduling - I'm a crap planner, and being able to compare estimates with reality would be the first step towards fixing it.
* I could stop making up arbitrary numbers of hours worked on a given project, and actually provide some evidence.[2]
* Formalising a workflow would help keep me on track when I'm not sure what needs doing next.
* Having a tracker/agenda/scheduler/outliner all together makes for some interesting integration potential.
[1] http://orgmode.org/ - outliner with all sorts of extra shineys for Emacs.
[2] Less unethical than it sounds - I'm basically subtracting out the time I spend faffing around on the internet. But I suspect I'm sometimes too generous with my subtractions.
I spent a lot of time (pun intended), i.e. about half a day, on searching a time tracker that would fit my needs. I was not interested in features related to billing clients, and thus I found too expensive the services that seem to be most popular, like Harvest, whose pricing starts at $12 per month if one works on more than 2 projects. I would not pay more than $1 per month for a simple time tracking service. I needed a web application / service, as opposed to client software, since I work on multiple computers. Also, the ideal service that I was looking for would have an Android app such that I could track time when I'm not using a computer.
Toggl does all of these within the free plan, however it is somehow buggy - the Android app, the desktop app and the web service do not synchronize well and I am kind of forced to use just the web service through a browser.
I would be interested to find out about other apps that would do the job.
Company of three web developers clocking time and billing clients. Punch runs in a little Chrome window on the side of our second monitors. I can keep track of what the other guys have been, or are, working on; check our general productivity; it handles invoicing, and can give me hints on which clients are strong earners and which are a waste of time.
I don't need crazy CRM features, but have been thinking about quickly adding in a list showing neglected clients (so we can contact them and see if they have any maintenance needing to be done).
Why? In most cases you are using time tracking as a way to provide metrics for productivity or compensation. Once employees are incentivized to do a task within a certain time frame (i.e. average ticket close less than 2 hours) they will focus more on the end result (closing the ticket) rather than the actual task at hand (fixing the issue). For example in software development this can lead to developers who take shortcuts to simply fix the problem, but not necessarily fix the problem effectively (i.e. bad code).