vacuum_tuber's Journal: Timekeeping for billing

For time accounting I use a simple text file on a mainframe (uh, a Wang VS mainframe). Entries have a simple format enforced by nothing but guided by tab stops:

F 0930 0630-0645 SD1: This is a time log entry. It can
. run to multiple lines.

F = Friday, just because I keep a better picture of things
in my head when the day of the week is associated.

0930 = mmdd of the log entry.

0630 = hhmm of the item start.

0645 = hhmm of the item stop.

SD1 = the three-digit project code, in this case signifying "SlashDot 1".

Since I didn't want to have to enter the year in each log
entry I have a separate year marker that precedes the entries of each year:

YEAR 2005

Now... what does this get me? With a pretty straightforward extraction and data reduction program it gets me billing data for any period for any subset of project codes, with project subtotals and selected period totals, with output by day or summarized for the billing period.

Client ABC will tend to have project codes beginning with "A". Client XYZ with "X". Etc. I keep a list of the project codes and their creation dates at the head of the file and the data reduction program ignores the list.

For data entry I use the system's source code editor with a setup that places the tab stops where my fields are located.

In at least my main client situtations I have printed the detailed project data for the billing period and attached it to the invoice. They are usually very favorably impressed. Only one complained, but she was an intellectually- and IT-challenged manager who didn't last.

I can include or suppress the start/stop times of day. If client management or A/P can't handle the idea of work done at night I suppress them. I log breaks in order to have contiguous accounting of time, and I can include or exclude printing of breaks and personal time. With some clients I want them to see that all time is neatly accounted for, so I print everything. For others who might be confused I suppress any mention of breaks and personal time and leave it to their adding machine people to verify that the disjoint hours add up correctly. For squirrelly clients or jobs for which detail is inappropriate I simply transfer the totals for the billing period to the invoice.

Oh yes, the data reduction program calculates hours from the start/stop times I log. Hours are shown in the output as decimal fractions, rounded to quarter hours. I generally log my start and stop times in such a way that the rounding aways works to the client's favor, not to mine. That way if hours were ever questioned I could show that actual time exceeded that billed. But it never came up. Ever.

The program neatly handles stop times later than 2359. I have always handled late night sessions begun before midnight as extensions of the 24-hour day in which they began. That solves the problem of a work session that crosses over into a new billing period, which could produce the timekeeping equivalent of an "orphan" in word processing and typesetting, in cases where the project code to which the time is billed effectively ends with that overnight piece of work. I have often billed weekly or biweekly, so it's inconvenient to have the tail end of a Sunday overnight session fall into the next billing period and invoice.

No bill I've submitted using this methodology has ever been challenged or refused. On the contrary, at least some clients have commented that they wished they got this detail from other contractors and consultants.

What do I enter in the log? Major descriptive elements of the work done, as well as valuable technical details that may be of use to anyone working on the same stuff now or later. The idea is twofold: to produce work record that the client could show to any technical person even remotely familiar with the work done and get verification of reasonableness and, if necessary, verification of the actual work done. Second, to produce a record in which crucial data is recorded for future reference. Thus, I wouldn't merely log that I fixed a problem but *what* the problem was determined to be, *how* I fixed it, and any relevant settings, patch data, steps carried out, etc.

When these logs get to be large they serve as unstructured databases in which previous instances of technical issues and their solutions can be queried. At one client location where my presence spanned 4-1/2 years I made my time log available to other programmers so they could look up the kinds of gnarly problems that we can remember have been solved before but whose details elude us, and problems that may have been solved before our time.

I don't do this kind of work anymore but the methodology and tools have served me well since 1986, when I wrote the first version of the data reduction program. Despite my best anticipation of century rollover in the code I wrote in 1986 and subsequent minor modifications, the program failed after Y2K and, since the source was lost at a client location that had shut down while I was busy with other things, I had to write it again. That wasn't difficult and the new version works better for me than the original.