Timesheets: The Pain In The Ass, That Could Save Your Ass

Posted by Mike Brown on 1/12/17 4:21 PM

Find me on:

As you may or may not know, I love data and track just about everything.  Most of the time I don’t know what I’ll do with the data while I’m tracking it, but figuring it out after the fact is half the fun.  Over the last 7 years I’ve religiously tracked every hour I’ve worked, what I was doing, if I was interrupted, and a variety of other data points.  Here is 7 years of data summed up in one graph:

Blog-20161219-1.png

Great… so what was the point?  Other than seeing I work WAY too much, I can correlate this data with other data to see what we can learn, but before I do that let me state my hypothesis: I think an employee’s time worked will directly correlate with the health of a project.  Okay, with that out of the way, let’s isolate a project so we can focus on that:

Blog-20161219-2.png

As yes, my current project; 2 years and counting.  The format of this graph is great for comparing hours across years, but it’s not the right format to analyze a specific project.  I also think there are better ways to slice this data if I’m aiming to predict project health.

Salaried employees that care, tend to work extra to hit deadlines; they personally absorb project overrun and render many issues invisible to those not attuned to the state of the project.  As a result, I think the best indicator will be a combination of a rolling 7-day total of hours worked and the number of contiguous days worked; these should highlight an employee absorbing more work than a project timeline allows.  Let’s look at this project through that lens:

Blog-20161219-3.png

Okay, what are we looking at?  Well, apparently I worked for 26 days straight and topped out at 111.5 hours for a 7-day period in October 2015.  I had raised the red flag several weeks before this and we ended up hiring a dedicated BA to help with the project as a result.  On the surface, it looks like this graph is highlighting the issues I want to see.  Let’s get rid of anything that looks like normal activity and layer in more data, like project milestones to see if all of these spikes line up:

Blog-20161219-4.png

Looks about right; the spikes in contiguous days worked lead directly into important dates.  I’ll skip the detailed breakdown of this since this is one of the most complicated projects you will ever encounter; instead, let me layer on project phases:

Blog-20161219-5.png

Green is requirements/design, blue is build, and red is training/UAT.

After the first phase of this project you can see we learned a few things, namely that delivering monthly milestones was not appropriate for the audience we were dealing with.  Not only did these milestones result in scope being introduced to the project that we were forced to absorb without moving the delivery date, the audience actually had trouble consuming the milestones and didn’t raise the biggest scope item until the very end, causing a second phase of development to be required.  For the second phase of development, we switched to a more traditional waterfall approach since the audience was more comfortable with that style.  This resulted in a more manageable draw on our resources and kept scope better contained, but still used far more of our resources than it should due to external pressures on the timeline.

That was a lot of data, but what was the point?

Since I was running this project and playing an active role on the team executing it, I was aware of all the extra hours going into it.  I was working extra and could see everyone else doing the same.  I was very aware of all the problems and could manage them early or raise them to someone who could, but this is not typical of many projects.  Many people manage projects from afar and have people providing status updates that may not be reflective of the real situation.  From past experience, this could either be because that person is blind to the problem or is scrambling trying to catch up because they know they are behind and don’t want to get in trouble; in either case, the project is in trouble and the person managing it should be aware of the problem.

I know it’s a huge pain in the ass, especially if you are a salaried employee, but please track your time accurately using whatever time tracking tool your company uses.  It can provide an early warning to your manager that a project is about to go sideways and your manager can do something about it before it becomes a bigger problem.  If they don’t know until it’s too late, everyone loses.


Topics: Article



Leave a Comment

Monthly Newsletter Signup

Advisor's Guide Transition Ebook

Recent Posts