PM-Clinic: Week 7 Summary
Topic: Tracking programmer’s work
Compiled: 11/8/2004
The Situation:
Dear PM-clinic:
I’m a new manager of a team of programmers and testers. An argument we’re having now is over the best way to track programmer work. Since the team is newly formed (many folks haven’t worked together before) each programmer comes from a different school of thought about how to document their estimates, track them, and update. Some folks who’ve used XP (Xtreme programming) before want a non-frills, super light weight solution (e.g. a whiteboard in the hall), while others have good experiences with custom webtools or other development tools.
I don’t want overkill, but I also don’t want something that requires a ton of work everyday. How can I track engineering assignments, track estimates, and mark track progress, without driving myself and everyone else crazy?
– Tracking programming work (TPW) in San Jose, CA
Know why you’re tracking
Stellman wrote that the three most important reasons to track projects are
- See where we are with respect to the project plan .
- to have historical data so that we can estimate when building future project plans.
- Making each individual more aware of his or her contribution to the project.
More specifically, consider how information your tracking will be used to make decisions. Each thing you track consumes more of your time and more of your programmer’s time: it costs time to track time. So before you ask for hourly status reports, ask yourself what decisions that data will help you to make. If you can’t think of any, don’t track that particular kind of data.
Common Tools
Whiteboard in hallway: Pros: lightweight. informal. visible. Cons: not digital (no backups, remote viewing, hard to do bulk updates, etc.)
Excel: Pros: Easy to work with, flexible, lightweight. Cons: Doesn’t scale. Everything from scratch. Single use.
MS Project: Pros: Great for big monolithic work, small # of users. Cons: High overhead if you’re a small team/small project/frequent direction changes.
BasecampHQ: Mentioned but no one offered a review.
(There are certainly other tools, but these were the ones mentioned this week).
General advice about tools
The magic isn’t in the tools. It’s in 3 questions:
- Does everyone care about the schedule?
- Do they understand the system being used to track?
- Are they willing to help the team track the schedule?
If the general answer is yes to all 3, the team will help you figure out the best way to do the tracking, and can you to overcome any deficiencies you find in tools. If the answer is NO to one or more of these questions, you’ll have problems no matter how great the tools are.
Also, consider what format the initial project plan was created in. Tracking work should fall out of the planning work (And part of the planning effort should be thinking about how to run the project and track progress in a way that increases the odds of the plan being fulfilled on time).
Tracking
There is no way around some kind of regular and repeating process. Consider what the heart rate of the schedule needs to be: are daily schedule checks really needed? hourly? Most of the time once a week is sufficient to catch most major problems early. Pick a Wednesday or Friday and have a team schedule check in meeting. Whatever tool is used should be updated before the meeting, and then team leads can review progress, ask questions, respond to issues, etc. If this is kept short (Focus on 3 questions: what’s gone better than expected? What’s gone worse than expected? What should we do to respond to things that have gone worse?)
Meeting-averse teams can do this without the meeting: a set time every week where every programmer agrees to update their piece of the schedule. Managers and pointy-hats can than meet on their own to discuss progress or project strategy.
References
Delphi estimation, a tool for group based estimations.
This week’s contributors
Neil Enns, Andrew Stellman, Gareth Howell, and Scott Berkun.
PM Clinic discussion group