Measure your own click work: tally for a week before you automate

Which task eats most of your week in Inventor? Chances are you just named the task that annoys you most. And chances are those two are not the same. Annoyance sticks in your memory; scattered seconds do not register at all. That is exactly why gut feeling almost always points at the wrong automation candidate.

There is a simple remedy: measure repetitive work before you do anything about it. Not with time-tracking software or a consultant, but with a sheet of paper, a pencil and one working week of tally marks. This article gives you the complete method: which categories to tally, how to convert marks into hours, and how to distill your top three automation candidates from the result. Only then does it become interesting to look at tooling, whether that is a macro or a toolbox like Thundercad.

For the record: this is the personal baseline. What all that click work costs your department as a whole, and from which point automating pays off, are different questions; we will point to two earlier articles for those along the way.

Why your gut picks the wrong task

Annoyance measures intensity, not duration. Printing the weekly drawing package feels like waste because it is one continuous, mind-numbing hour. But the five times per hour you browse through folders hunting for the right file feels like nothing, because each occurrence lasts half a minute and supposedly just comes with the job.

Run the numbers, with assumptions your own marks will later replace: five searches per hour, forty seconds each, eight working hours a day. That is well over twenty-five minutes a day, more than two hours a week. The hated printing hour looks pale next to it, yet ask an engineer for his biggest time sink and printing wins. How such small actions add up to entire working days per month at department level is something we calculated earlier in What does repetitive work really cost your engineering team?; here the question is where they sit in your own week.

The tally method: one week, one sheet

The setup takes ten minutes. Put a list of categories on paper beforehand; tallying in a file does not work, because then the mark itself costs another window and another click. A usable starting list for Inventor work:

• searching for files: browsing to the right folder, the right project, the right revision
• opening assemblies and waiting for everything to load
• exporting to PDF, DWG, DXF or STEP, and printing
• filling in or correcting iProperties: description, material, status
• refreshing BOMs and transferring them to Excel
• updating drawing sheets after a model change
• rework: fixing mistakes, your own or someone else's
• other: anything that occurs more than three times, with a keyword next to it

Make a mark the moment the action is done, never afterwards from memory. Do not time every occurrence; nobody keeps that up. Clock each category two or three times with the stopwatch on your phone and note the average as the unit time. Five working days is enough.

From marks to minutes

At the end of the week, processing takes fifteen minutes: number of marks times unit time, then sort by the outcome. A fictitious but recognizable result, with all durations explicitly assumptions:

Two things almost always stand out in a result like this. One: the total. More than seven hours a week spent on actions that are not design work, nearly a full working day. Two: the ranking. The category this engineer complained about, exporting, is not at the top; waiting for heavy assemblies and the invisible searching win. Which is exactly why you tally first and conclude afterwards.

Picking your top three candidates

Sorting by minutes per week gives you a first ranking, but minutes are not the whole story. Weigh three things per candidate:

1. Volume: how much time per week, and was the measured week representative of your normal work?
2. Error-proneness: an action that occasionally goes wrong, like retyping a BOM by hand, weighs heavier than the raw minutes suggest.
3. Energy: between two equal candidates, the one you dread most wins, because that is the solution you will actually use.

Searching and waiting usually score on volume, retyping on error-proneness, printing on annoyance. Keep the list at three: candidates four and five get their turn once the first three are solved. Whether a candidate justifies the build or purchase effort is the next question; the thresholds for that are in When does automating pay off? Three thresholds.

Keep the measurement honest

A baseline is easily ruined. The best-known trap: changing your behavior because you are measuring. If you suddenly start tidying folders during the tally week, you are measuring your good intentions instead of your normal week. Measure the week as it is; tidying can come afterwards.

Also pick an ordinary week, not the one where a machine has to leave the building and your normal rhythm is gone anyway. And tally everything within the categories, including the actions you feel simply come with the job. The result is allowed to surprise you; that is what it is for.

Finally, repeat the measurement a few weeks after you change something, with the same categories and the same unit times. Then you see in black and white whether the change delivered anything, and that overview doubles as your story towards colleagues and management.

Frequently asked questions

Is one week of tallying really enough?

For daily actions the picture stabilizes surprisingly fast: searching, opening and exporting look almost identical in a second measurement week. Only for strongly project-bound work does it pay to tally two separate weeks and take the average.

Can I do this with the whole team at once?

You can, with the same category list for everyone, and it produces a nice department-level picture. But do not wait for it: one honest personal measurement convinces colleagues faster than a mandatory team-wide form ever will.

What if no clear winner emerges?

Then your week is more varied than you thought, and that is a result too. In that case pick the most error-prone action instead of the biggest one, or simply test a candidate in practice: try Thundercad 30 days free and tally the same week again afterwards.