The UX of Time Tracking

Project management is hard work.  I feel for anyone who has to do it in the software industry.  The problem is simple.  To do any kind of prediction in project management, you need to be able to guess how long something will take.  Let’s say you want to build a web page.  How long will it take?  Over the last decade of doing just that, I know that a page takes about 1-2 days to produce from a JPEG or PSD.  I know I can make a Marketo landing page template in about 1-2 hours.  I can make a home page in about 1-2 days.  SOunds like a project manager could get that information out of me easily.

But what if he asked me to debug some javascript that was non-trivial.  It might take 5 minutes.  It might take 3 days.  Programming is notoriously hard to predict.  Multiply this by hundreds of bugs and features that really take a variable amount of time to produce.  One programmer might know something out in a day, while another does it in a week.  So what does the project manager do when the boss says, “When will this feature be ready for customers?”

Most project management systems force programmers to track their estimates and then track the amount of actual time spent.  I have been looking at these systems for work. The problem is a UX one.  Who wants to track their hours?? No one, that’s who.  Designers don’t track their hours.  Marketers don’t track their hours.  Why do programmers need to?  Programming is perceived as “magic” by myself and other non-engineers.  This is why we try to force the developer to become robots who can be predictable.  We try to put logic around something we don’t understand.  I have never been in an organization where time-tracking worked.  Maybe someone else has.

So why does every single PM tool out there hinge on time tracking to do it’s thing? Are there no alternatives?

Why am I awake at 6am thinking about this?  Ok, I’m going to cut this short.

%d bloggers like this: