Friday, 6 September 2019

Stop Using Timesheets


In an organisation which does software development, timesheets can really damage your productivity for what is actually a false economy. As Head of Development at The Cogworks I saw all of these problems and eventually abolished them completely.

In this article I will debunk common reasons for requiring developers to do timesheets. I will give better alternatives which will make your workforce happier and the organisation more profitable.

Comparing Projects For Efficiency

I cant believe I even need to state any of this, but here we go...

No two projects are the same. When I was at The Cogworks, we helped a client launch 100's of websites using a standardised multi-lingual starter-kit, "virtually identical" Information Architecture, and "very similar" designs. Each project was totally unpredictable in delivery due to changed in content, varying client-side interaction times, different developers, different designers, different devops people on the client side, and secret stakeholders who appear at the 11th hour. Keep in mind, this was the same client!!!

Requirements will always differ in some way, and stakeholders and client-side Project Managers change even within the same client & during a project. I have seen a project be totally derailed because a new (not so great) PM appeared on the client-side.

There is no point trying to compare build & deploy time for even small items. No two pages will ever be identical. I commonly hear "It's identical except...".

People on two project teams will have differing skills, experience, knowledge, personalities, and experience working with each other. Imagine taking a team who get along and have created many projects, however they are a bit sloppy. Compare that group to a team who have new members who don't know each other's skills and personalities, however they are all very capable.

I hope I have convinced you to stop trying to compare projects.

There are however other ways to tell if a project was efficient. For example, count the number of calendar weeks that the project took to complete. This is not the same as the number of utilised hours!

Performance Reviews

Using timesheets for performance reviews makes absolutely no sense. As a manager I want to know how many tasks a dev can do, and how often bugs are reported by QA.

I'll give you this (really bad Apples & Oranges) example:

Time logged is not the same as output
Anthony is a great at baking, however he worked on task "Apple Sauce" for 4 days. 
Greg is a great at Apple Sauce, however he worked on task "Orange Meringue" for 3 days. 

These people worked on things which they were not specialised in. How can you compare their time?

An alternative is to track output, not time logged. Track the number of tasks which each developer does. A very simple metric is to count the number of Jira/Trello/Asana/etc. cards which are completed within a timeframe.

Anthony's Apple Sauce is horribly overcooked with over-caramelised parts.
Greg's Orange Meringue has less perceivable defects than Anthony, however he didn't need to use a stove.

These tasks were totally different. Anthony basically failed at his task. How do you compare them based on timesheets?

An alternative is to track the number defects which are flagged. If you are using a Kanban process, then you can simply count the number of defect cards which are created against the work items.

Other Issues
No one knows if either tasks are complete, or even if they are done to the satisfaction of the client. Did the client report any issues, did QA find issues? 


Timesheets are seldom accurate. Here are some common habits of someone who fills in timesheets. I can absolutely say that these things happen because I personally have done all of these, and will continue with these habits if made to do timesheets.
  • Round up numbers to get 8 hours tracked per day
  • Add a number to a random client which I "think" I worked on
  • Forgetting to do them on Monday, so I do them from memory on Tuesday
  • Forgetting to do them all week, so I do them from memory on Friday
  • Forgetting to do them all month, so I do them from memory on when I am chased
    • Yes I've done this one too!

Even automated tracking will still be wrong...

Think about toilet breaks, coffee breaks, discussion at the water cooler, cigarette breaks, impromptu project chats, emergency meetings, helping another developer, doing a quick code review, phone calls, emails, Slack, calendar, Trello, and finally... short lunch vs long lunch. Trying to account for all these scenarios is a fantasy fallacy of micromanagement.

But I hear you saying "what about mouse tracking software?". Well, stop reading this article. If I cant convince you then perhaps these people can:

Client Billing

Fixed Cost Billing

I have been part of countless projects where I was required to do timesheets because they were apparently used to bill the client. When I found out that the projects were all fixed cost, I asked the question: "If the project is fixed cost, then how are the timesheets used to bill the client?"

The answer was: "The timesheets are used to see if we're losing money".

*face palm*

Tracking project time is different to tracking people time. I'll explain more in a future post.

Billing For Time Spent

If you are using timesheets to do client billing, then you are probably being too granular.

What would you do in this following scenario?
Developers help each other with questions, code reviews, discussions, architecture. Very often the knowledge / skills required may not exist within the same project team, so developer from another team is asked for some quick help. Very often this will be just 5 minutes. Sometimes it is longer.

Also, what about all the project meetings? eg. Standups (3-15mins), sprint planning, sprint review, sprint retrospective, random comms, emails, quick chats with the PM, 2min slack conversation with the client devs. What about when a colleague asks "How was your weekend"?

I know what you're thinking...
1. Dev 2 should enter a number into their timesheet that they spent 5mins helping Dev 1
2. As long as a developer's time is tracked against a client/project then there is no money loss.

Why are you concerned about tracking developer time by the minute? This is classic micromanagement! There is not value to the business to know that a developer asked another developer a question. It is wasteful. People hate and resent this level of micromanagement. Developers help each other and it all evens out anyway. So stop trying to track this!

A better alternative is to take a higher level approach. Bill by the day, week, sprint, month etc. See here for a better alternative.

Final Thoughts

I hope I have given you food for thought when it comes to timesheets and your production team. Comparing timesheets of projects has absolutely no value. Performance reviews should be based on quality and quantity of output, not time logged. Accuracy of timesheets is also generally crappy. If you can change your billing process to be less granular, then you will not need timesheets.

Once you remove timesheets from your business, your staff will be more productive and happy.

No comments:

Post a Comment