Time overviews

These are our internal guidelines on timesheet overviews. They are part of our principles. A clear time overview is an effective service quality tool.

The benefits to you as a software developer are:

1. Get a quick overview of what takes up your time.
2. Understand how you could re-prioritize your time.
3. Understand what tasks can be delegated.

The time overview (ERP link) is a list of all requirements in a work order and the total time booked on each of those requirements. It can be accessed by clients as well. For development teams there’s a work order for each sprint.

Non-sprint-based projects (NSBPs) include administration, recruitment, marketing and agile maintenance projects for which a sprint and work plan cannot easily be pre-planned. NSBPs can have work orders named by time period. E.g. “Admin 2017” and “Accounting 2017”.

A new work order can be set up for NSBPs when the list of requirements gets too long, cluttered and unclear. Ideally, that shouldn’t happen frequently, and a new work order would ideally need to be set up only once per year.

This is my personal time overview named “David 2017” which corresponds to about five months of work. Note that requirements shall be set up as billing type=unbilled for unbilled in-house work.

You can create an unbilled requirement by unchecking “Make this requirement TM” in the add requirement page. You will then be asked to set a fixed budget for the requirement which should be given as 0.

Your personal time overview (PTO) is how you can ensure that you follow these guidelines. You can access your PTO by appending your employee id parameter to the URL: http://staff.litebreeze.com/TimeSpent.php?application=000&workorder=000&fromdate=&todate=&employeeId=000

You can also access your PTO from: http://staff.litebreeze.com/timeEmployeeOverview.php

Bookmark your PTO so that you can easily ensure its neatness.

Create a new work order in the ERP when necessary. Top technical staff and department heads have permission to create new work orders. In 99% of cases they have already created a suitable work order for you.

Anyone can add requirements to a work order here. Name requirements in a short, clear and concise way. Don’t suffix requirements with unimportant terms like “page”, “and related tasks”, “etc”.

Concise requirement names will make time overviews consistent and neat. It will allow us to see full requirement names in browse page columns and select boxes in the portal, where space is a constraint. Check the TO before adding new requirements. Carefully consider the name.

Plan what requirements you will need for the year. Never add ambiguous requirements such as “bug fixing”, “small fixes”, “new changes”, “new tasks”, “other”. It’s better that you estimate roughly what features those “bug fixing hours” were spent on and book them on specific requirements.

If your senior gets an “invoice” where time is booked on an ambiguous requirement like “bug fixing” or “general work”, they would not know what you have actually worked on. A client would be more likely to dispute the invoice. And it makes it difficult for us to explain why they should “pay for bugs”. Seniors would miss valuable information.

Another problem with ambiguous requirements is that once it’s set up, other staff tend to start booking time on it for the sake of convenience. It erodes service quality slowly but steadily over time.

Ideally, requirements size should have minimal variation/dispersion. Requirements should be as similar in size as possible.

I realize that perfection is not always possible and there are valid exceptions. But, always consider if small requirements could be merged and if large requirements could be broken down.

There is some dispersion in my own PTO. “Project management (clients)” has very few hours booked on it, but I have kept it on purpose to demonstrate how few hours I need to spend on handling existing clients.

“Systems development (ERP, servers)” is another one, and the reason for keeping it is that much time will be booked here once we have the resources to start the ERP revamp project.

A detailed breakdown results in higher service quality for stakeholders, but obviously comes at an administrative cost. The level of detail depends on your seniors and clients. It makes sense to give a new active client a more detailed breakdown.

Long-term clients tend to have more trust in us, and might not require a super-detailed break-down, so we can then reduce the level of detail a bit. So for a 300 hours development sprint an ideal size would be around 15 hours per requirement for a new client, whereas 40 hours might be acceptable for a long-term client where we have solid rapport.

15 hour TO requirements can also be too detailed for a passive client. Personally, I break down my PTO into around eight different requirements. This is fine for now as stakeholders only need an overview of how I spend my time.

Never delay booking your time on the right requirement; never book your time on the wrong requirement temporarily. If you think “I’ll make my TO neat later”, you’re making things very difficult for yourself.

Moving time entries retrospectively is a hassle and can mess up invoice time overviews (ITOs) that clients have access to. If you use the SMS time entry system, registering your time entries will be a breeze.

The client can access newly created requirements and the newly booked time immediately, in real-time. The client will be sent an ITO when invoiced. The client may be invoiced at any time.

Therefore, TOs must be kept neat and tidy at all times. Never postpone this till “tomorrow”. Don’t rely on seniors to tidy up your TO for you.

Like time entries and work plans, time overviews can even be of legal importance in case a client fails to pay and we need to take legal action.

Continue reading about work plan guidelines.