Alternatives to time tracking methodologies [closed]

Question

Question first: What are some feasible alternatives to time tracking for employees in a web/software development company, and why are they better options

Explanation:

I work at a company where we work like this. Everybody is paid salary. We have 3 types of work, Contract, Adhoc and Internal (Non billable). Adhoc is just small changes that take a few hours and we just bill the client at the end of the month. Contracts are signed and we have this big long process, the usual.

We figure out how much to charge by getting an estimation of the time involved (From the design and the developers), multiplying it by our hourly rate and that's it. So say we estimate 50 hours for a website. We have time tracking software and have to record the time in 15 we spend on it (7:00 to 7:15 for example), the project name, and give it some comments.

Now if we go over the 50 hours, we are both losing money and are inefficient.

Now that I've explained how the system works, my question is how else can it be done if a better method exists (Which I'm sure one must). Nobody here likes the current system, we just can't find an alternative. I'd be more than willing to work after hours longer hours on a project to get it done in time, but I'm much inclined to do so with the current system. I'd love to be able to sum up (Or link) to this post for my manager to show them why we should use abc system instead of this system.

Answer 1

Software estimates are always difficult. Software is a creative business, and creativity waxes and wanes. I'm just starting to bounce back after a week of severe exhaustion--the other night it took me hours to do a task that should have been 15-30 minutes...

Also consider that each developer has different estimating abilities. More disciplined or senior developers will tend to be more accurate and more junior or undisciplined developers are less accurate. Also, their accuracy changes over time (not always for the better).

In my personal consulting experience I try to blend a realistic estimate with a ceiling. Basically saying "I expect this feature to take 7-10 hours, but could reach 18--at most, even if it takes 40 hours, you will be billed for 18". Usually this type of approach is new to clients and some flat-out reject it with "give me a firm price"--those clients get the ceiling estimate (or I politely decline their business). For clients that accept this approach, they understand that I'll honestly track time, and their actual final bill will reflect my time-spent (but won't exceed my ceiling). Essentially this is a lean-approach with a guarantee added; and the customer is aware that any changes to requirements introduces changes to the estimates.

Overall that approach has worked well for clients willing to accept it. My personal goal is to gain their trust and repeat business, so it's in my interest to be honest and try to come in well under the ceiling--and it's in their interest to be helpful in keeping me under my estimates (by avoiding uncertainty, late changes, etc--I revise estimates if changes are anything beyond minor).

If you haven't, I would suggest reading The Mythical Man Month

Answer 2

Take a look at evidence based scheduling. Can really help you see how accurate your estimates are likely to be.

Over the last year or so at Fog Creek we’ve been developing a system that’s so easy even our grouchiest developers are willing to go along with it. And as far as we can tell, it produces extremely reliable schedules. It’s called Evidence-Based Scheduling, or EBS. You gather evidence, mostly from historical timesheet data, that you feed back into your schedules. What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date. It looks like this:

The steeper the curve, the more confident you are that the ship date is real.

Here’s how you do it...

Answer 3

The problem with this method is that it takes no account of the inherent risk in estimates. A best practice for any estimates is to express it as a range of times, e.g. 50 hours ± 15 hours, or something similar. The error term is tough to come up with, but nobody believes it will take exactly 50 hours anyway.

There are other approaches aside from the fixed price model; you could use a lower rate, and bill straight hours, but these days, your clients will probably want to transfer the risk to you. That's fine, but it means you need to charge a reasonable risk premium based on the range of time estimates you come up with.

Answer 4

We do estimates with an "uncertainty" factor, rather than trying to estimate with "+/-" factors. Programmers can easily tell you how long something will take "assuming nothing goes wrong". What they can't easily tell you is how much longer it will take if something DOES go wrong. So we add an uncertainty factor - "L" means "add 25%" - "M" means "add 50%", and "H" means "add 100%- could double". The real time tends to be between the estimated time and the estimate plus uncertainty time.

As far as TRACKING your time, the most accurate method is to write a program that pops up a dialog box every minute and asks you "what are you doing?", with a drop down list box of possible tasks. The only entry you really need in that drop down list box is "tracking time", because if you're interrupted every minute, you'll never actually get anything else done. The same principle applies to 15 minute intervals too, just not as bad.

What we do is run a little program that lets us add tasks to a list, and select which one we're working on, letting it add up the time. If we forget to move the selector to the right task, the totals are editable. Anything not in one of the rows goes to "misc". It's not totally accurate, but total accuracy is less important than getting flow time.