The Bucket and the Water

As someone focused on process improvement and knowledge management I have a relationship with IT. In this case, I am speaking of IT as a group of professionals responsible for keeping the technology “lights on” in my organization. Often IT is called on to do more than keep the lights on. I have been spending time lately thinking about what it is that I ask of IT and whether my needs and expectations line up with the way that our IT groups is resourced. I have started asking myself if my need or expectation is the bucket (technology) or the water (information/content).

The bucket and water is a useful analogy for the relationship of content and technology.

Buckets can be short or tall, made of plastic or metal. They can have handles and be excellent for carrying things or be tipped upside down and used as a resting place. My husband finds buckets so useful that they have their own designated storage space at the Mireau Farmette that cannot be superceded by items of lower value. Buckets can also have holes in the bottom. Depending on the application the bucket is required for, a hole is either a fantastic addition or a major inhibitor.

Water is a useful analogy for content. Content is fluid, it changes, it evaporates and also falls from the sky. Water is not useful as a thirst quencher if there isn’t a receptacle to gather it in so that you can have a drink. In my IT relationship analogy the bucket and the water are clearly co-dependent.

A process improvement project can have a result that calls for a different bucket. A KM project can add colour or fizz to the water.

When I ask IT to deploy a macro I wrote to make it easier for a group to upload content to a online service that they need for client work am I creating a bucket or filling it with water? It may seem like a ridiculous question, but it is important to understand the answer. By messing with the bucket, as someone who is not part of IT, I might be asking the group to deal with something that is going to impact their workflow in ways I do not even think about. By doing as I ask, do they need to change the image that a computer is built with? Who is responsible for testing? What happens with training? Is today’s solution tomorrow’s problem and who has to solve that problem? If the macro is water, what does that mean for the questions above? Who is responsible for the training and testing and how does the change (please, let it actually be an improvement) become institutionalized?

I believe it is my responsibility as a team player and collaborator to ask myself whether I am making a racket by banging on a bucket or leaving a garden hose to flood the patio and whether the noise or the mess is necessary.

Who has the mop?

Comments are closed.