Last week I got this message from Rebekah:
Jurgen,
I've been following your blog and really enjoy it. I work for a small web development firm that has grown a good bit over the last few years. We've recently transitioned from charging hourly rates to fixed-price projects. Because we once billed by the hour, we're still recording all of our time. We'd like to get away from this, but aren't sure how to proceed.
I'm curious how your teams handle this. Do team members record time per task? Do they record their time at all? If not, how do you measure profitability on a project?
Yes, we record time per project for every team member. This is indeed essential for measuring profitability per project. Of course, there are some people, like Jeff Sutherland, who think that time sheets are among the greatest evils, right in line with task-switching, big-upfront-design, and Windows Vista. However, such people usually have the luxury of working on only one project for a considerable length of time. And I envy them, despite their apparent ignorance of how other organizations need to do their business. Because, as in our case, when you're paid by different customers to work on several "projects" in a span of just a few weeks, then yes, time sheets are essential! (How else are we supposed to know whose heels to lick, and which projects to throw out?) Of course, it's also possible that Jeff is so amazingly rich that he doesn't care about the profitability of his projects.
However, I do agree that tracking time per task within one project is not needed. The customer is not interested in those details, and neither are we, since they are fixed price projects anyway. In this I disagree with Joel Spolsky's take on tracking time, as I believe tracking time on a task level can never be made a) reliable; b) profitable; or c) enjoyable.
If you don't schedule someone a certain number of tasks (with a certain number of hours) how do you know if they're overbooked?
In Scrum, a team estimates the tasks for the next sprint in the sprint planning meeting. The ScrumMaster knows for how long the team has been allocated to this project, with issue days, academy days, holidays, quality days, sick days, and baby days deducted from the week. In the rare case that there's still some actual productivity time left, the team then estimates how much work they can do, according to their (historical) average velocity (the amount of estimated work they finished in the previous sprints).
The whole point here is that the actual unit of estimation doesn't matter, as long as it's constant throughout the project. They can use ideal hours, but they can just as well use story points, oranges, toilet visits or CPU cycles. (In fact, some people suggest using Fibonacci numbers, which is even more ridiculous, as nobody can tell what those numbers are.) The actual time the team spends on tasks is irrelevant. Yes, Joel Spolsky thinks it's important, because historical data can improve the quality of new estimates. But I suspect this has more to do with memory faults among Joel's own team members. After all, when real hours differ significantly from people's estimates, our team members usually know and remember that. They talk about it every day in their stand-ups! Of course, people's memories are never precise, but neither are the estimates. I don't believe there's a need to adopt a bureaucratic process of documenting all deviations.
So yes, you must track time in order to track project profitability.
And no, you should not track time in order to improve task estimability.
And with this opinion it seems I'm squashed right between heavyweights Jeff Sutherland and Joel Spolsky. And I haven't met either of these guys, so I don't know if that's a comfortable position to be in.
Thanks for your time.
Rebekah
No problem, and thanks for your email!
(picture by michel filion)
Subscribe to this blog with a reader or by email!
Latest, greatest and favoritest posts:
How to Do Many Projects (Part 4): Resource Planning
How to Do Many Projects (Part 3): Maintenance
How to Do Many Projects (Part 2): Matrix Management
How to Do Many Projects with Few People (Part 1)
