I’ve been training myself to think in terms of “process-cycle time” instead of “work-effort hours”.

Say I know for a fact that a particular database coding task really only takes about 1 to 2 hours to accomplish on average in the hands of a dedicated technician. So do I use the 2 hours estimate in my plans? No. While it is true that the actual work time has meaning to the technician doing the task, it has very little project management use. It’s because the 2 hours of actual task is not the real turn-around time to get the job done.

What I want to really know is how long does it take for the request to go into the black-box of the programming team and then come back out of that same black-box all cooked and ready for consumption.

Sometimes I don’t want to even know the details, but here’s what I would suspect is happening inside the black-box and cog-wheels of that fictional team:

Code work request gets submitted (e.g. 2 minutes)

sits waiting (e.g. 1 business day),

gets reviewed (e.g. 5 minutes of scanning by an expert),

sits waiting some more (e.g. 1 business day),

gets approved (e.g. 1 minute),

gets scheduled (e.g. 10 minutes),

sits waiting some more (e.g. 2 days)

actually gets coded (e.g. 2 hours),

then gets submitted, reviewed, corrected, and then finally accepted and proclaimed as task done.

In that case the turn-around time I’m looking at is about 5 to 7 business days. That’s the time information that’s relevant to making plans and setting expectations with the customer.

(Incidentally, you might have noticed that doubling or tripling the speed of the coder would actually have little effect on the cycle-time – the gains could only be obtained in that department by improving its internal process.)