Resisting the Technology Imperative

Dwayne Phillips

Revision History
Revision 1.0 December 2008

This is the Cutter Information Technology e-mail Adviser  (that is obvious, but stay with me here). It may not sound right for someone to advise against the use of information technology in this forum,  but that is what I am going to do.

I recently saw an article in Technology Review about putting RFID tags on tools (hammer, screwdriver, wrench) so that a computer could help the workman find his tools in his pickup truck. I am all for things that help workmen be more efficient, especially if they are working at my house and charging by the hour. But really, do we need a computer system to help a carpenter find his saw?

I once worked in a computer lab where the technology imperative ruled all management decisions.  This imperative stated that if a technology existed, we had to buy some of it (regardless of our mission and our needs). We wasted a lot of taxpayer money in purchasing stuff, installing stuff, administering stuff, and learning how to use stuff. Somehow, we found a little time to do our actual jobs.

We never asked questions like, "Do we really need this new technology? Would it be nice to have for experiments? What would we learn from it?"

This computer lab was also infatuated with databases. Every week someone would ask for a new database to track something. We considered building a database of the world's military aircraft. Another government lab was contracting for millions of dollars to  build a database to track data tapes (we used tapes in those days).

We could have easily solved our aircraft knowledge "problem"  by thumbing through a copy of "Jane's Military Aircraft of the World." The other lab could have solved their tape-tracking problem with a pencil, a clipboard, and a disciplined person standing at  the door of the tape-storage room.

These examples are extreme. They are also from government labs, and we all know that government organizations are, well government organizations. I have also, however, found examples of people in private industry wasting resources on "neat" technology that wasn't really needed.

Before building some new IT system, I encourage people to think. As a help, consider questions in three areas: (1) the problem, (2) the technical solutions, and (3) the human solutions.

(1) The problem:

. What do we do here (our mission)?

. What "problem" are we trying to solve?

. How does the problem affect what we do here (our mission)?

(2) Technical solutions

. How much would a technical solution cost (both to build and to maintain)?

. How long would it take for the technical solution to pay for itself?

(3) Human solutions

. How much does our current human solution cost us over time (dollars of salary per month)?

. If we had a thousand people sitting around twiddling their thumbs, what would we have them do for us?

In addition to these questions, I use this guideline when considering requests for IT systems:

Don't build an IT system unless you have tracked the information with a  pencil and paper for at least six months.

Often you will find that the data are not really worth tracking. If you learn that the they are worth tracking,  you will know much about how to do the job and what an IT system should do for you.

I have used these questions and this guideline successfully for the past 15 years. Life, however, has a way of crushing my smart questions and guidlines. At work,  we had a system where we moved classified data from Europe to the  U.S. by physically shipping disk drives on an airplane. The young engineers wanted to change the system and move the  data via a communications link. Again, these data are classified, so shipping and communications links are more complicated than they may seem. I walked through my questions with the young engineers and showed them that our physical shipping method met all requirements. The new communications link was not necessary. End of story - not.

The young engineers stumped me with one statement: "But this is the year 2008.."

I didn't have an answer for them. Hence, I add (at least) one more guideline: Consider the context of the world and your workforce. Avoid things that seem stupid.