As a consulting company it's core to our business to accurately track the time we spent on our clients' projects. Even for non-billable work, we should track those hours so we know where we're spending our time. We use Harvest to track our time. This guide will cover the specifics of that process.
It's best to establish a habit of tracking your time daily. Using Harvest's timer is even better to keep it accurate and straight forward. By the end of each day you should have accounted for your time in Harvest.
As you work on a task, which we'll refer to as a card, you should create a time entry for it per day. It should include the total time you spent on that card. In the description field you should include the card's title, limiting it to a phrase or sentence that identifies what it refers to followed by the card id. We do prefer past tense as we use these descriptions for weekly and monthly reports. Take this example:
Added bio to the user profile (#42)
If you'd like to include more information on the specifics of what you did, do so after this line in the description field.
We use a variety of tasks to represent how our time is being spent on a project. Though each project may have unique tasks according to the work being done we typically use the same core tasks on all projects.
This is our most generic task and represents time we spent designing and writing code. Internal discussions with the team about the design, modeling or implementation fall under this task. Unless a project tracks bug fixing separately that would also fall under development.
This task covers any work we do on server infrastructure, DNS or external services that relate to the operations of our systems.
Any time we spend talking to a client via conference call or in person gets tracked as meeting time. Weekly planning meetings fall under this task. Internal meetings are not billing under this way. If internal meetings are focused on ui/ux design or software modeling we'd use the more specific tasks of UI/UX development or Development respectively.
This is a special task that we use to track time getting up to speed on a new project.
This task covers work that specifically deals with interface design and implementation. There is a gray area where a full stack dev might be making changes to UI or to the front end. That would fall under development unless the work is focused on the visuals such as layout or css-driven design.
There are some tasks in Harvest that rarely get used. In most of these cases you'll want to talk to Marty before you start tracking time against them.
This is a non-billable code that we use when we want to know that time is being spent on a project but don't want it to be billable. It functions as a catch-all so we know that it's happening but it has no impact to the client.
If a client asks us to develop documentation for their business, this is the task we use for that work. Documenting our code and the README does not fall under this task, only when producing documentation as a deliverable is it appropriate.
This rarely used task was originally added for general maintenance type tasks. We now prefer to categorize under development or another more specific task.
This is a special task that is almost exclusively used by Marty when working on a client's business model or product direction. Unless you've been told to use this task, choose another one that feels the most appropriate.
This task is used when spending time doing traditional project management.
Sometimes a client will ask us to perform quality assurance tasks that fall outside of our normal development process. Use this task in those cases. Reviewing pull requests and verifying that code works in deployed environments as part of our typical flow does not fall under QA.
This is a non-billable task that is included in case you're doing research on some new library or framework that we might want to use on a project.
If a project needs us to provide end user support or training, this task gets used for that time.