SSW Foursquare

Rules to Better Timesheets - 12 Rules

We use SSW TimePro for our timesheets. It is a sleek and powerful software is a web app, so there’s no tricky installation required.

  1. Do you know how important timesheets are?

    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)?

    enter your timesheets
    Figure: You should be filling out a timesheet for every day you work

    Bucket list
    Figure: Timesheets come first, always!

  2. Do you follow policies for recording time?

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

    • Be accurate

      timesheet accuracy
      Figure: Good example - Inform accurately how much time you spent for each client

    • 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
  3. Do you know the best ways to keep track of your working time?

    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.

    diary
    Figure: Bad example – Physical Diaries are no longer needed

    TFS comments
    Figure: Good example – Azure DevOps commit messages are a very accurate recording of what work was done

  4. Do you have essential fields for your timesheets?

    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 - Things you've worked on, including people who you were working with - both internal or external

    Good Timesheet
    Figure: Good example - A good timesheet with all the required fields taken from SSW TimePro

  5. Do you know how to describe the work you have done?

    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).

    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.

      • 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.

    Apply changes as per Tony's request for FRDCAPP

    Figure: Bad example - 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 double-counting)

    Fixed DiaryTemplate UpdatesAttempt to run CaterPRO! in the old Windows 7 with Alan

    Figure: Good example - Informative timesheet note

    Tip: Use TimePro to avoid doubling up by using Azure DevOps commit messages that flow through to timesheets.

  6. Do you know when to enter your timesheets?

    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
  7. Do you incentivise your employees to do their timesheets on time?

    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
  8. Do you know to work all the hours you're booked for?

    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:

    • Developer X comes in in the morning
    • Checks inbox, replies to a few emails, gets a coffee
    • Looks at the calendar to see what they are supposed to work on that day
    • Spends some time getting up to speed on the tasks involved
    • Then starts billing once they have started work on a specific task for a client

    Bad example: Scenario where developer bills a partial day

    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.

    • Developer checks their calendar or the CRM Service Calendar the day before and knows what client they are going to work on before they come in
    • Arrives (with a double shot of coffee) and starts billing as they open the computer and sets up the 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 they're working on and bills the full day

    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.

    service calendar
    Figure: Your timesheets for next week should end up looking a lot like your original bookings (in our case this is shown in the CRM service calendar)

  9. Do you know how to manage booking cancellations?

    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.

  10. Do you book a minimum of 1 day's work at a time?

    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:

    "Hey {{ DEVELOPER }}, I see you are putting down 6 hours for Northwind when I have booked you for the whole day. Please always timesheet the full 8 hours and let me know if you think something should be written off."

  11. Do you avoid using "General" in timesheets?

    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.

    using general timesheets bad
    Figure: Bad example - "General" project or category

    good example timesheet
    Figure: Good example - Specific project or category

  12. Do you track time against Spec Reviews separately?

    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".

    spec review costs
    Figure: Good example - Spec Review costs clearly shown separate from the project costs

We open source. Powered by GitHub