How Not to Do Time Tracking for Software Developers
The crux of the story is this sentence:<p>&quot;They’ve taken a tool that could give people more ownership over their own work and distorted it into a mechanism for managers to exert control over their team.&quot;<p>This is true for every company, no matter the tool. This could equally apply to a Methodology, meetings, deliverables, timelines, or any other top-down approach designed around coercion.<p>I&#x27;m reminded on Tom DeMarco&#x27;s thoughts about Control and what kind of projects need such controls [1]:<p>To understand control’s real role, you need to distinguish between two drastically different kinds of projects:<p>- Project A will eventually cost about a million dollars and produce value of around $1.1 million.<p>- Project B will eventually cost about a million dollars and produce value of more than $50 million.<p>What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.<p>Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost. I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to control them, no matter how assiduously we apply ourselves to control.<p>[1]: <a href="https:&#x2F;&#x2F;www.computer.org&#x2F;cms&#x2F;Computer.org&#x2F;ComputingNow&#x2F;homepage&#x2F;2009&#x2F;0709&#x2F;rW_SO_Viewpoints.pdf" rel="nofollow">https:&#x2F;&#x2F;www.computer.org&#x2F;cms&#x2F;Computer.org&#x2F;ComputingNow&#x2F;homep...</a>