Rules to Better Timesheets
Do you agree with them all? Are we missing some? Email us your tips, thoughts or arguments. Let us know what you think.
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
- Follow Do you know how to 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:
- Fully electronic - Enter your timesheets daily (recommended)
- Keep details in OneNote or Notepad++
- Jot it down on paper (i.e. a physical diary)
- Copy and paste your TFS check ins. The comments from these check-ins make great comments for your timesheet entries
Tip #1: SSW TimePRO automatically pulls TFS check-ins in 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 TFS check ins, CRM bookings, Outlook emails, and Daily Scrums to ensure communication.
These are the essential fields for your timesheets:
- Client ID - or Client Name
- "On-Site" or "Off-Site"
- Project and Iteration (if applicable)
- Category (what kind of work it is)
- Amount of time
- Break - Minimum 1/2 hour break if you work more than 5.5 hours
- Who you were working with that day - both your company and Client people. We then know if we are missing any timesheets
Figure - Good Example - A good timesheet with all the required fields taken from SSW Time PRO!
Clients want to know how you spend your time, and how you word it matters.
Tip: Avoid doubling up by using your TFS check-in comments, that flow through to timesheets - use TimePro.
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).
'Fixed Bug on customer form'
- Figure: Bad example
'Investigated and improved the validation on customer form to enable saving when Customer name is > 100 characters'
- Figure: Good example* Be specific about what you did. e.g. 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 - Do you not use "General" 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 traveling 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.
'Apply changes as per Tony's request for FRDCAPP'Figure: This is an example of a bad timesheet note 'CaterPRO! Version 8.3Fixed Sales Reports (Sales Dashboard). It now reconciles correctly with Food Sales Summary.Fixed Function Counts (was doublecounting)Fix to DiaryTemplate UpdatesAttempt to run CaterPRO! In the old Windows 7 with Alan
Figure: This is an example of a good timesheet note
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 have a technical issue that stops you from entering them directly, email your timesheets to your manager and ask him to enter them
- 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.
Everyone gets a free lunch today except for the following people:
- Person 1’s name
- Person 2’s name
Can you please complete your timesheets ASAP and little ‘r’ me when you are done
Here’s what we check:
- Timesheets - http://reports.ssw.com.au/Reports/report/SSWTimePRO/SSWTimePRONETReports/11_ValidateMissingTimesheets
- SugarLearning - https://www.sugarlearning.com/SSW/Leaderboard
- Bookings - http://reports.ssw.com.au/Reports/report/SSW2005Reports/SSW%20Booked%20In%20Days
<This email was sent as per the rule: https://rules.ssw.com.au/do-you-reward-your-employees-for-doing-their-timesheets-on-time />
Note: 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 $10.00 Tax Invoice back to Accounts for reimbursement.
Note: Ideally, buy the free lunch in 1 go, to reduce the admin involved for the accounts department.
Note: 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 his timesheets.
If the dev is booked in on the Service Calendar in CRM, he will be billing that full day to the respective client. Let's see 2 examples:
- Developer X comes in in the morning
- Checks inbox, replies to a few emails, gets a coffee
- Looks at the calendar to see what he’s supposed to work on that day
- Spends some time getting up to speed on the tasks involved
- Then starts billing once he has started work on a specific task for a client
Bad Example: Scenario where developer bills a partial day
- Developer checks his calendar or the CRM Service Calendar the day before and knows what client he’s going to work on before he comes in
- Arrives (with a double shot of coffee) and starts billing as he opens his computer and sets up his development environment
- Works and bills all day regardless of distractions and other people
- Does not stop to wait on someone else because of a dependency, but continues to find ways to deliver value
- The full 8 hours is billed to the client
Good Example: The developer knows ahead of time what he’s working on and bills the full dayThe 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 him to make sure he is 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.
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.
See Rules to Better Sales Account Management - Do you book in a minimum of 1 day's work at a time?
This rule has been migrated to "Do you know the best ways to keep track of your time?"
Developers should *never* use the "General" Project.