2

I work in a small engineering company whose engineering department consists of a small handful of engineers. We will generally have one or two major development projects ongoing, but are also required to support a multitude of existing products. Due to pressures from our holding company, a requirement has been demanded that in order to understand how much each of the various projects we work on cost, we need to be recording how much time we spend on them.

The reason for this requirement is because our department is the most expensive department in the company. The board of directors wants to understand where this money is going and how it's being spent. Hence they feel that if they measure our time and what we're working on, they'll better understand and justify the costs of the department. They're not doing this directly for client billing purposes.

We started to have a go at this using various apps to "clock in and out" and trying to use timesheets, but unfortunately it never worked because it very easy to forget to "clock in and out", especially when the main projects were interrupted by small minor tasks that were done during the day (e.g. problem occurs in a product that needs addressing, manufacturing problem needs sorting out). It seemed that such a method of recording time was more suited to a workshop/manufacturing environment where employees had very defined pre-planned tasks and weren't "interrupted" with sudden minor tasks that needed to be addressed immediately. We certainly quickly started to see it as an annoying bureaucratic hindrance. We've talked with our immediate manager (who comes from a manufacturing/workshop career), but she doesn't have any alternative ideas and is just trying to meet the demands of upper management.

I'm trying to find a solution to this problem. I believe that the main issue lies in the fact that, as a small company with few engineers, one or two major ongoing projects and many existing products to support, inevitably, things will crop up that need addressing, which means an engineer will need to break off their main task (sometimes for several days) and address those. However, I'm not sure how to go about solving that. I understand the need to reconcile employee time against projects to help with costing, but feel that time-recording is too bureaucratic and unsuited to the sometimes unpredictable working environment.

So, what can we do to the resolve the problem? Can time recording be applied in a non-intrusive and beneficial manner, or is it just not appropriate in this situation? Are there any other ways in which we can meet management's demands to reconcile employee time against projects? Or is the only solution to to try and fix the level of unpredictability we currently have?

  • What is the problem that you're trying to solve with the time sheets? (In general, I agree with your comment on factories. Time sheets make sense for tracking 8 hour work shifts for one customer--but not usually a multitude of fragmented projects for multiple customers). – DA. Jan 21 '15 at 22:59
  • @DA. The problem they're trying to solve is tracking how much of the working day is spent on which project. At a later date, the timesheets can be grouped together and the total man-hours on each project can be determined, thus giving a man-hour cost. – EncumberedEngineer Jan 21 '15 at 23:01
  • I get that that is the often stated problem trying to be solved, but even then I question that. I've rarely seen meaningful decisions based on such statistics other than "OMG we're spending too much time on everything". I've never seen 'proof' that tracking the engineering time on project X is any real indicator of how much time it will take on project Y. – DA. Jan 21 '15 at 23:04
  • @DA. You're right - the actual problem they're trying to solve is that our department is the most expensive department in the company and the board doesn't understand where this money is going. They want some sort of statistics that help them understand where this cost is going. – EncumberedEngineer Jan 21 '15 at 23:12
  • 1
    Aren't your higher-ups also missing the time it takes to context switch between two completely different problems? – shivsky Jan 21 '15 at 23:33
3

All our work including production support is client billable. It is just a fact of life that you have to keep track. We are required to fill out a daily timesheet. I usually have anywhere from 5 to 10 items on mine and some people have many more than that.

Clocking in and out doesn't work as you have seen. In this environment, we estimate to the nearest 15 minutes. We are required to fill in the timesheets daily so we don't lose track of what we did. I usually reconstitute mine by looking through my emails/calendar and IMs to catch the little things (I can remember the big ones!).

Really this isn't hard to do and I have had to do it for evey dev job I have ever had because they really really need to know how to bill. Lots of engineers, almost all lawyers and lots of other professions manage to do this task daily in spite of mulitple task changes through the day. I am not sure why your team thinks it is hard.

  • 1
    "I am not sure why your team thinks it is hard." That's why I'm asking the question! – EncumberedEngineer Jan 21 '15 at 23:18
  • Billing clients for engineering at 15 minute intervals is certainly not unheard of, but insane in my book. And I'd never subject developers to have to split their day up across 5-10 tasks. My sympathies! :) – DA. Jan 21 '15 at 23:20
  • Also, lawyers are always the example given but note that most all lawyers round up to the hour (if even that) and most have a huge support staff under them. It's a bit of a different world for lawyers. – DA. Jan 21 '15 at 23:22
  • At LastJob we had to track to the nearest 6 minutes! But I just keep a daily text diary, put in the time (or approximation) when I start a task, and add notes that might be useful as I go. At the end of the day it's easy to add up the time spent on each task. The notes themselves are more useful, as I can look back weeks or months to see how I did something the last time. – thursdaysgeek Jan 22 '15 at 0:02
  • 6 minutes: this is why lunch at IBM was nominally 42 minutes. Management wanted to allow 45, but the accounting unit was tenths of an hour so this was the closest the could (officially) come to that. My work day is still claimed to be 8:30 to 5:12, not that anyone's tracking that. – keshlam Jan 22 '15 at 15:01
2

Can time recording be applied in a non-intrusive and beneficial manner

No.

It can be guestimated with various levels of success--but even that will be intrusive on some level.

At the end of the day, at least in IT environments and the like, time sheets are often an attempt to leverage antiquated factory floor management processes but ultimately end up just as a 'stat juking' exercise. For the latter, everyone could save a lot of time if managers simply put in the hours as they'd like it to look to present to their superiors. Then everyone's happy.

The only realistic solution is to make the units of billable time practical. Don't track time to the quarter hour. Track time to the 2 or even 4 hour chunk'. Anything that takes less that 2 or 4 hours is written off as 'maintenance' or somesuch.

2

Sometimes -- especially for government projects. -- it really is important to have credible accounting for how you spend your time. They understand that you can't _completely _ swap out one task when you switch to another, but you need to make a good -faith effort or you can lose the contract. In that situation you definitely need to "clock in and clock out ", and the easiest way to do so is a bit of software which records the times and calculates the totals. Any programmer can whip up a basic version of this in a few minutes, or you can buy industrial -strength versions.

I have an even simpler version that I use to record what I'm working on so I remember it all at quarterly review time. It just adds a line to a file giving the date/time I ran it and a line of commentary I typed in. It doesn't try to distinguish start/end times, and I use it only when I have something significant to record, since my hours do not need to be tracked.

  • This is the way to go. Ask for a time clocking program that meets your requirements at Software Recommendations. I have been using some custom made program (so I can't share it) that ran as a tray icon app and very quickly let me switch project/activity. – Jan Doggen Jan 22 '15 at 7:55
0

At the end of every half-day, try scheduling yourself a 10-15-minute appointment to reflect on what you've achieved, what has been hindering you. (Most of the time, once you know what you're doing it will take less time)

That way it's recent enough that you can remember, but it's not so frequent that it's intrusive. Don't attempt to be more precise than 15-minute chunks, and don't be afraid to have a 'misc' for interruptions too small to be worth individually allocating, which might well amount to a lot over the week. Everyone needs to do things like tidy their desk, read the CEO's announcements, etc. and if over a week a lot of that 'misc' time is down to one person or one project you'll probably know and be able to communicate that - otherwise that's just costs shared across projects, same as your finance or HR functions are paid for.

Use the opportunity to reflect on what went well, what you could have done better (can you fix it?). Remember that this is all part of your work and time budget needs to be spent on things like this.

You're not trying to facilitate micromanagement - and a second-by-second account of your day is probably of no interest to anyone - but to be able to give a reasonably consistent guide to which things cost more to maintain. Your bosses probably just want to know the percentage per project in round numbers, to the nearest 5% at most, so they can say to clients "You're costing us 40% of our engineer time and other similar-paying projects cost us half that, descope or pay up" and be able to plausibly back it up. Figure out a system that gives them that.

  • 1
    I think this is a sane approach, but it's interesting to note that this adds up to a half hour of overhead each day. Which is roughly 125 hours a year dedicated to time sheets. – DA. Jan 21 '15 at 23:24
  • Yes, it is a lot, but time is a necessary cost of data collection. That said, 15 minutes every half-day is a generous allocation: you may not need it all. The time you will lose if you have to task switch to finding your timekeeping system every time you task switch is going to be a lot worse, not to mention the inevitable time spent fixing things like"oh, hang on, I forgot to stop the clock on that, when was that?". – user52889 Jan 22 '15 at 19:47
0

I think what you need is a ticketing system (aka bug-tracker, issue tracker, pm tool) where these minor tasks each get put into a ticket. Then you either assign these tickets to individuals or have people just assign themselves. These ticketing system often have a definable workflow/progress-indicator and some way to indicate total time spent (and by whom) upon completion.

This way, you allot the bulk of people's time for normal development projects and set-aside a fraction of their time for the ticket-system (people often call it "the queue"). Alternatively, staff can take turns spending a day or more exclusively dealing with the queue.

If you do it right, the end result is a query-able database of all tasks, their status, who worked on them and how long. The pointy-haired ones can then make reports until they're blue in the face.

The advantage of these ticketing systems is that if people use them correctly, they're never in a situation of staring at a blank-spreadsheet and having to GUESS what they spent their time on to an absurd level granularity. Instead, tickets are completed one-by-one and managers use reports to figure "how much was spent on what".

Atlassian Jira is a particularly nice and configurable system for this kind of stuff.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.