People like to be busy. It seems like it is built into our DNA. A recent post from Joitske Hulseboch has me thinking about this again, Busy is the new smoking and she links to an earlier post with some advice, Only suckers are busy (in Dutch - thank you Google translation) by Annemiek Leclaire.
There is a strong need in our culture to "contribute." For many people, this gets translated into doingsomething. And for people who manage other people, this gets translated into some version of "if you aren't busy, I can give you something to keep you busy." And many organizations have a real or implied threat: if you aren't busy, you are likely to be outsourced / fired / made redundant. And what are you supposed to do instead of "be busy"? Sit around and "do nothing" while waiting for that key piece of information, or that key activity to start?
This sounds like a classic internal conflict: On the one hand, find things to do in order to always appear to be contributing (and keep your job). On the other had, be available and ready in order to support the bigger picture in your organization. People have a strong tendency to fall towards the "keep busy" side of things because of those underlying assumptions about job security. And surely, doing something has to be better than doing nothing.
However, one of the side effects of the "keep busy" side of this is that it means people are not available when they are really needed to contribute to a key activity. Particularly in the context of knowledge work, it is very difficult for people around you to know whether you are engaged in a key business activity, or if you are doing something of lower priority to fill time - like writing a blog post. And if people aren't available for a key activity, that key activity ends up takes longer due to all the waiting. And the waiting and restarting and then waiting again for someone else often generates errors or mistakes and rework. All of this ends up extending the overall effort by massive amounts.
Improvement programs that focus on fixing the work process - optimizing the activities themselves - often don't create that much of an overall improvement because they miss the time lost due to flubbed handoffs, waiting, and rework. This time is significant - on the order of 25% or more of the duration of a project.
The improvements that have a lot of success here tend to emphasize getting the work out in the open: shared workspaces, visual boards, kanban, etc. These create a collective understanding of the work and what needs to be done on a regular basis. I find the exercise of learning what people are really doing to be instructive: often even the managers don't have a good picture of everything that people are doing. Even for solo contributors or self-employed consultants, having that visual display of what is happening can be helpful in prioritizing and getting "busy" on the right things.
An analogy: We often operate as if we have a large lake to swim in: many places to go and things to do. But in reality, in any kind of project, we are rowing down a river to meet an objective. The group must row in the same direction and seek to remove barriers as they arise, or the project doesn't get done. Activities required will present themselves as the river flows - there will be times of intensity and times of calm. Of course, the analogy breaks down because those times of intensity will be different, depending on the participants' roles.
[Photo: "stream at Lake Dennison" by Jack Vinson - me!]