The Unproductiveness Factor

A friend of mine sent me this article and asked me for my opinion.
The basic premise of the article is simple: if you want to know exactly how a certain tool, technology, or process, improve the productivity of your staff, you cannot just measure how much time it saves. If a certain tool saves ten minutes a day per developer, for example, "we all know" that at least part of this time will not be used for doing productive work.
“When productivity returns from IT are measured, time saved does not equal additional time worked. Using a correction factor to account for the inefficient transfer of time allows accurate and structured the quantification of returns from increased productivity.”
So, the article continues, we need a Productivity Correction Factor™ (trademark of Nucleus Research Inc.) to correct our estimate of productivity gain from deploying a new tool. Naturally, this factor can only reduce the estimation — no one can be more productive than what you expect him to be, right? So in fact, this simple numerical factor can now tell you how much time your staff is wasting, or, in other words, how unproductive they are.
The whole idea of representing the productiveness (or in this case the unproductiveness) of a human being using a single number is flawed. I’m really curious to know how a CEO reacts when he reads his marketing personnel are half as productive as his service representatives. I personally know some managers who will try to come up with innovative ways, such as limiting Web access, to prevent their stuff to waste so much time. After all, its company’s money they’re wasting, isn’t it?
But you know what? That’s not even the real problem. The real problem lies in the underlying assumption that any minute that is not used directly to create money for the company is a waste of time.
Let’s say that out of each hour you save by introducing some new technology or practice, your developers will spend 45 minutes on online games and random conversations by the coffee machine. Does that mean productivity is increased only by 15 minutes? Is it possible that the time your developers spend on "meaningless activities" is in fact an indirect productivity enhancer? Is it possible that the time they "waste" on stupid games helps your developer be more focused and do a better job in the rest of the time? Have you considered the option that some of the best ideas are born in random conversations?
People are not machines. Measuring people’s productivity as the percentage of time they spend on their primary task is relatively easy. But that doesn’t make it a meaningful measurement. People, and especially people doing creative tasks, might spend much of the time on other things beside their primary task. This is not necessarily a waste of time. On the contrary, it’s probably an essential ingredient of the creative process.
The problem is that many managers think that in order to be in control they have to have "accurate" measurements of every part of the process. The unproductiveness factor is just an extreme example. Many in the software industry still think about productivity in terms of the number lines of code per developer per unit of time, the number of bugs per tester per unit of time, etc. Each of these measurements is as inaccurate as it is easy to calculate. Trying to capture a complex concept, such as productivity in a creative process, using simple factors and measurements can easily lead to the wrong conclusion. With these wrong conclusions and the bad decisions that follow, you will eventually decrease productivity instead of improve it.
Instead of deconstructing the process into meaningless numbers and measurements, it’s sometimes better to look at the overall picture. If you are evaluating a new tool, a new technology, or a new process, consider using some soft evidence. Use the new tool in a pilot project, and then try to understand its effect by talking to your customers, your developers, and other stakeholders. Will you come up with an accurate number reflecting the return on investment of using the new tool? Well, you won’t. But you will have a much clearer picture of the effect this new tool had on your development process and on the product or service you provide.
For years, it has been said that things that cannot be measured cannot be managed. Now, think of all the things you manage in your life even though you have no way to measure them. Is it possible that some aspects of managing a team, a project, or even an entire company are also unmeasurable?












November 27th, 2006 at 3:10 am
Nice article that leads me to a question: if productivity is not easily measurable, how do you detect a decrease in productivity ? By carefully watching factors such as staff motivation/happiness ?
November 27th, 2006 at 11:57 am
I am one that believes happiness and “quality of life” is crucial in being productive. Sure, you can try to measure productivity by the quantity of output, but like Lidor explains here, not all things that add to productivity are quantitative.
Like right now; I’m at work reading this article and posting this comment. Am I wasting the company’s time because I’m not coding software? I think not because I am expanding my knowledge thinking about how I can work better - which will, in turn, make me a better (happier) worker and will lead to better quality output (products).
Anything that can/does/might make you a better person by enhancing your view on working is never, ever a waste of time or money.
November 27th, 2006 at 2:09 pm
The article’s examples were, to say the least, surprising. I haven’t a clue why this vendor singled out marketing people as time-wasters. They’re trying to sell a service to estimate ROI. Of course they admit that the only way to “corroborate” (that’s “tell if it’s true” for simple people like me) such estimates is to check output after a period of time.
That said, I don’t think we can go too far into the post-modern “everything that makes you a better person” is OK for an unlimited amount of working hours.
There has to be some kind of balance, IMHO heavily weighted towards a person’s primary output (e.g. not lines of code but yes working features delivered on time).
In a supportive environment people can relax a little around the screen or the water cooler, and definitely spend time reading and learning as needed.
But I can’t see the justification for, e.g., major game-playing when you’re supposed to be working.
November 27th, 2006 at 4:36 pm
[…] PD: But if you think you’re going to increase the productivity in terms of the number lines of code per developer per unit of time, the number of bugs per tester per unit of time, etc, you’re wrong, remember the unproductiveness factor. […]
November 28th, 2006 at 6:17 am
“There has to be some kind of balance, IMHO heavily weighted towards a person’s primary output (e.g. not lines of code but yes working features delivered on time).”
Tom, how do you size and count features? Should bigger features count for more than smaller ones? What if a feature is small, but it takes a lot of time because you have to refactor first?
I agree there needs to be balance, but I think it’ll need to come from judgement and context, not quantification.
February 14th, 2007 at 11:37 pm
Why not just measure productivity by output and get it over with?
November 20th, 2007 at 9:10 pm
Are you proposing to measure output by volume? If so, that just encourages people to just shovel out more cr*p and not create quality output.
I could write the same logic in one line of code…
or
I
could
use
several!
December 5th, 2007 at 3:04 am
[…] Art Here. […]