Measuring Wait Time and Touch Time in the Real World

Tools
#1

Can anyone give me a pointer as to whether conventional project management programs have ways of measuring “wait” time and “touch time”.
“One might wonder, why not start immediately with the right perspective to begin with? The answer is simply that it would not seem accessible or credible enough to get things started. And we need to get started this way, because unless we first focus on reducing Wait Time, we will never be in the operating conditions to focus on Touch Time, which is where the real big gains are to be found.”

Tendon, Steve; Doiron, Daniel. Tame your Work Flow: How Dr. Goldratt of “The Goal” would apply the Theory of Constraints to rethink knowledge-work management (TameFlow) (p. 70). TameFlow Press. Kindle Edition.

#2

I’ve never seen one, Kenneth!

#3

I guess you could deduce it by comparing the difference between the time the task was assigned, and the time it was finished…with the number of hours the programmer logs working on the task. Which would assume that you could link the task the programmer attributed his time to with the task he was assigned. That would not work for kitting out time or for ramp up and ramp down time for each task…but it would be a beginning.

#4

You can learn a lot from manufacturing. Have a look at the topic of overall equipment effectiveness (OEE). If you have a simple app that the worker can switch on and off when they are working, you can also get an empirical idea from there. You have to be very careful though about the fear people have about being measured on their timekeeping.

#5

If you’re using a tool like JIRA, you can actually measure the time a ticket sits in a certain status on the Kanban board.
For example, you can measure how long an item takes from “Ready for development” to “development” and from “dev” to “ready for test.” But I feel that’s kinda micro-managy if you’d do it at team level.

In most practical cases, it’s entirely sufficient to measure the wait time from “Program Epic scoped” to “Program Epic in development”, to Program Epic Done. That may be enough to reap massive gains in wait time reduction by introducing replenishment signals and full-kitting there.

#6

If you structure your boards as a proper Flow Efficiency boards, and are just diligent in moving around the tickets, then Wait/Touch Time data should be captured automatically, without to much of a hassel.

The purpose of the FE boards is to get more reliable WT and TT metrics. (In addition to the psychological drivers they inject)

#7

That is too much big-brotherish… and probably breaks Union rules in many EU countries.

What we should measure is the time of the work, not of the workers. This can be “sold” to Union reps, albeit with a lot of effort.

Even Union reps need to be taught the difference between resource efficiency, flow efficiency and ultimately throughput efficiency.

#8

Year’s ago, I started in mfg, using lean prior to ending up in sw dev. At the time we used active vs wait time, value stream mapping in conjunction with traditional proj mgmt. As project managers we had to learn toc. It wasn’t until recently with tameflow that I saw it all put together simply and succinctly for knowledge work.

1 Like
#9

:heart:

TameFlow is breaking many molds… but then things make sense!
:wink: