Tracking Developer Hours and Team Capacity: A Practical Guide for Outsourcing Teams
Most outsourcing teams track hours. Few use the data. The timesheet gets exported at month-end, the project is over budget, and everyone says the estimate was off. The problem is not whether people log hours. It is what gets logged and what happens next.
Separate hours, capacity, and utilization
They are not the same thing.
- Hours: time a person spent on a task.
- Capacity: deliverable hours the team can realistically produce in the next two weeks.
- Utilization: billable hours divided by available hours.
For an outsourcing shop, capacity tells you what you can promise. Utilization tells you whether the promise makes money.
Keep time tracking simple
Do not track by the minute. Development is not a factory line. Too much detail forces people to invent clean numbers. Ask for three fields: project, task type, hours. Keep task types to five or six: feature work, bug fixing, integration, meetings, pre-sales support, internal work. Two minutes at the end of the day, or a Friday catch-up. Do not let it slide past the next week.
Consistency matters more than precision. If “copy changes” count as development this week and support next week, the data stops being comparable. The PM should spend five minutes in the weekly meeting checking outliers: someone logged 60 hours, someone logged 20. Ask why before drawing conclusions.
Capacity is not headcount
Three people for two weeks is not 3 × 10 × 8 = 240 hours. Subtract leave, meetings, code reviews, production support. We usually plan around 6 billable hours per person-day. For a new team or a new domain, take another 20% off. Roll the plan forward two weeks at a time. Half-year forecasts are guesswork in outsourcing.
A simple capacity table helps:
| Project | Role | People available | Billable days | Billable hours/day | Capacity hours |
|---|---|---|---|---|---|
| Project A | Backend | 2 | 8 | 6 | 96 |
| Project A | Frontend | 1 | 8 | 6 | 48 |
| Project B | QA | 1 | 5 | 5.5 | 27.5 |
This table beats “everyone is busy.” Check capacity before you check the wishlist.
Estimate from your own history
Stop guessing. Log estimated hours and actual hours per task. Review every two weeks. Look for two kinds of drift: by task type, e.g. integration always runs 50% over; by person, e.g. new hires estimate conservatively, senior devs estimate optimistically. Feed that back into quotes. Use a range, not a single number. “80–110 hours” is closer to reality than “95 hours.”
Common traps
- Using timesheets as surveillance. People learn to log what you want to see.
- Tracking only billable hours. Pre-sales, support, and internal tools still consume capacity. If they are invisible, your plan is wrong.
- Planning at 100% utilization. People are not machines. A full schedule guarantees delays.
- Letting hours and quotes live in separate worlds. If you do not review actuals against estimates, you keep repeating the same mistake.
- Skipping task types. Everything gets dumped into “project,” and you cannot tell development from firefighting.
A 20-minute weekly rhythm
Monday morning: the PM pulls a two-week capacity view, marks leave, support duty, and part-time allocations. Friday afternoon: the team fills timesheets. The PM checks three numbers: billable ratio, estimate variance, and tasks over budget. Any task with more than 20% variance gets five minutes in the next weekly meeting. No long report. No fancy dashboard.
Stepwise attaches hours to tasks and projects. The capacity view shows people, roles, and weeks. Hours flow into project margin, and the client portal shows progress without another status email. That removes the month-end Excel reconciliation.
Time tracking is not about watching people. It is about quoting better and scheduling with fewer surprises. Run it on one project for one month. When the data starts to smell like reality, expand.
