Rules to Better Timesheets - 12 Rules

Timesheets are the lifeblood of the company and are the ultimate source of everyone's income.

Timesheets should be right near the top of your priorities. It's #2 on Do you get your work done in order of importance (aka priorities)?

There needs to be consistency between all of your developers' timesheets, so you should get them all to adhere to the following:

• Be accurate

  

• Describe the work you have done?
• Record all the work you do for a client, even if it is to be written off
• If you are working with another employee, ensure your times are consistent, in both time and category
• If you are providing telephone support, count your time in 15 minute blocks
• If you work for a client 4 times in a day for 15 minutes each, feel free to enter one timesheet for 1 hour, listing the 4 things you did. The extra information adds no value and only serves to clutter up invoices

The goal is simple, accurate hours and good comments.

There are 4 ways developers can keep track of what they have been working on when the time comes to enter their timesheets:

1. Fully electronic - Enter your timesheets daily (recommended)
2. Keep details in OneNote or Notepad++
3. Jot it down on paper (i.e. a physical diary)
4. Copy and paste your GitHub or Azure DevOps commits. The comments from these commits make great comments for your timesheet entries

Tip #1: SSW TimePRO automatically pulls Azure DevOps commits for you.

Tip #2: If you're using Microsoft CRM for bookings, you will have an appointment every day in your outlook that you can use to know what client you worked for.

Tip #3: As a last resort, you can copy and paste the subject from your emails to the client. Check your Sent Items to see what work you completed in the day. This should be simple if you're sending "Done Emails".

Why have we moved away from Physical Diaries?

Back in the day, people used to keep physical diaries to keep track of what work they did, and then they'd get the client to sign it each day they were on site to ensure they were communicating. This is now all covered by GitHub/Azure DevOps commits, CRM bookings, Outlook emails, and Daily Scrums to ensure communication.

These are the essential fields for your timesheets:

1. Client ID - or Client Name
2. "On-Site" or "Off-Site"
3. Project and Iteration (if applicable)
4. Category (what kind of work it is)
5. Amount of time
6. Break - Minimum 1/2 hour break if you work more than 5.5 hours
7. Notes - Describe the things you've worked on, including people who you were working with - both internal or external

Clients want to know how you spend your time, and how you word it matters.

On your timesheet entries, there are a few rules you should follow on how to best explain the value you have created for the client:

• Use standard terms to describe the work you have done E.g. 'Build', 'Investigated', 'Resolved', 'Enhanced', 'Created', 'Optimized', 'Experimented with', 'Improved' or 'Fixed'.
• Use the word 'bug' only if it fits the definition of a bug.
• The term 'Investigated and changed' is better than 'Fixed bug'. The word 'bug' gives the impression that the problem was solely the developer's fault, when often most fixes are to do with changes as a result of unspecified work (extra validation, extra testing or gold plating).

• Be specific about what you did.

  • If you create a new form, write 'Created Client form'.
  • If you are adding a button to a form write 'Client form - Added button AddNew'.
  • If you are trying to find a bug write 'Investigated error on ClientDiary form'.
  • If you fix something, write 'Resolved'.
  • If you are making something faster, write 'Optimized procClientDiary'.
  • If you are writing stored procs, write down their names.
• Use capital letters appropriately - if it is a Proper Noun use a capital.
  E.g. "Adam Cogan", "SQL Server", "Toyota" is ok, "Website" is not.
• Start a new line for each new detail. It makes it more readable. However, don't go overboard and take up half a page for one timesheet.
• Use past tense e.g. 'Updated web page' rather than 'update web page'
• Avoid abbreviations. Use 'version' rather than 'ver'
• Avoid using "General" as a project in your timesheets
• For public holidays, timesheets should be entered as "Leave".
• For customers from other states, travel time is usually billable and should be recorded separately on the timesheets so that the customer is fully aware of the exact time spent travelling to/from the client site
• Non-Billable time - If you do any work that is related to a client that you would not usually bill for (such as going to an initial meeting or travel within Sydney ), you should still enter it under that client - when it comes to invoicing time, this rate will be set to zero, but still show on the invoice, so the client has a record of all the time that was spent on their project.

Remember to enter your timesheets at the end of each day, while they're still fresh in your mind.

Here are 5 tips to getting this done:

• If you're facing technical issues preventing you from entering your timesheets, send the details to your manager and request that they enter them for you
• It's good to do this straight after lunch, so as not to interrupt your flow, but, as a deadline, they should be done by 6pm
• Every now and then, there is a blocking issue stopping you from getting this done. In that case, you can catch up the next morning. There is no excuse at all for not having them in by Sunday night. The purpose of this is so that your Accounts team can check all timesheets and invoice the clients first thing on Monday morning
• Make it easy on yourself by working for 1 client per day whenever possible
• You may want to have a reward system in place to ensure this always happens

Having a reward system in place can be a great way to make sure all employees get their timesheets in on time.

Get your employees to enter their timesheets daily and have a system that entails:

• A Friday email to update their timesheets, SugarLearning, and service calendar

A deadline for submitting timesheets (Friday 12pm). The entire company is rewarded with a free lunch, and only people who missed the deadline will miss out on it.

Notes:

• The Free Lunch should not accumulate. It's an 'on the day' reward, so take it or leave it... If they're not in the office, give them 30 days to get the $15.00 Tax Invoice back to Accounts for reimbursement
• Ideally, buy the free lunch in 1 go, to reduce the admin involved for the accounts department
• Since it's damaging to have senior people belittled by getting called out for relatively trivial things, you should always make sure you do your absolute best to help them comply

When an Account Manager and a client have made an agreement that a developer will work on a particular project for a day, the dev needs to work on it all day (at least 8 hours), and that should be reflected in their timesheets.

If the dev is booked in on the Service Calendar in CRM, they will be billing that full day to the respective client. Let's see 2 examples:

The bad example scenario is not acceptable as the full day will be billed to the client as per the agreement, so it's up to them to make sure they're as productive as possible.

The major benefits of the good example (working full days for the client) is that the Service Calendar will be an accurate representation of what will be worked on, and when a client thinks they have a resource booked for a day, they do in fact get the full day.

There will of course be exceptions, such as emergencies or urgent work coming up, but 90% of the time, full days should be billed to 1 client.

On occasion, you may be asked in the morning or even halfway through the day, to pause your work by the client.

Scenario:

1. Developer X shows up in the morning and starts working on feature Y as per CRM Service Calendar
2. Client calls and says “We’re sorry but we have to pause the development of feature Y because XYZ”

The reaction from Developer X should be:

“OK, I will call my Account Manager and make sure future bookings are cancelled until further notice. For today, is there anything else I can work on so you get the best value out of the rest of my day?”

Note: Same-day cancellations still incur that day's costs. If there is nothing more you can work on, and the client is unhappy, refer the client to your Account Manager.

It takes as much effort to book 1 hour as to book 1 day, therefore your efficiency of sales work to billable work goes down when you book in multiple small appointments instead of 1 big one.

When booking in client work, always make sure you ask the client to gather enough work for 8 hours of work. The minimum amount of time per booking is 8 hours.

There are always exceptions, such as emergencies or small fixes, but do your best to limit them.

If a dev is asked to do a few hours' work on a day that he is not already booked, a good response is something like “I’m available tomorrow if you’d like to book a day. Let me know if that's ok and I'll work on this then.”

Checking for Exceptions

You should always bill an 8-hour day, unless the developer feels that some time should be written off and you agree with their assessment. Speak to the developer if you see any discrepancies.

Some developers may take it upon themselves to only timesheet for 6 or 7 hours, and book the rest internally. This should only be allowed if they have explicit permission from their manager ahead of time.

For example:

Developers should avoid using "General" project in their timesheets.

"General" should only be used in rare cases, when you're doing something that:

• Doesn’t fit in any of the existing projects
• Isn’t worth creating a new project, as it won’t be a long term project or repeated in the future

If you’re using "General" in timesheets frequently, then it’s a problem.

When entering timesheets against a client for a Spec Review, you should always create a separate project so that this time does not pollute the data for the total project costs.

When a client asks how you are tracking against an estimate, this is always the post-Spec Review estimate and so should be compared to the post Spec Review costs.

The naming convention should be "{{ PROJECT NAME }} - Spec Review".