Technology is not required/Low-tech solutions

 I enjoyed the recent newsletter "technology not required" http://bit.ly/NKXW5e  It concludes: " if there’s a choice of two solutions, choose the simplest.  In most cases, it’s cheaper, takes less time and is at least 90% effective."

The newsletter asked for our own favourite examples, here's mine:

I once worked on the editorial staff of a magazine. Prospective subscribers could go on a mailing list and get 4 free issues. Our problem was as follows: Our customer database could record the addresses of these prospects, and we could add a flag to say they were doing the trial. But we could not find a simple way to get the database to record how many of their free issues the prospect had already received, so  that we didn't keep on sending out free goods. 

But then we came up with a much lower-tech solution. We flagged all the trial accounts and got the database to print out 4 sticky address labels for each of those customers. We put the labels in a binder. When a new issue was published, someone went through the binder, and used one of each prospect's labels to mail out a trial issue. If there were 4 labels for this prospect, or if the last label was being used, we added the appropriate marketing letter. Obviously once the trial was concluded there were no more labels for that prospect, and they automatically dropped out of the system.

That plan worked well. An advantage was that the envelope-stuffing could easily be done by anyone with a bit of time that day. They did not need access to the database, or training to use it, and the damage that an untrained person could do by accident was very limited (they could mess up the labels, but not the database).

Clearly there ARE situations when a more elaborate system is worth the investment. But I think that "10% of the investment for 90% effectiveness" sometimes does not get adequately considered  My example illustrates the main reasons:

1) Habit - we were used to using the customer database for this kind of thing, so it is what we started to think about first, and it was only when we got stuck that we considered other options. If we'd found a fairly onerous but workable database solution, we might well have used that without thinking further.

2) Glamour - a scruffy binder full of sticky labels looks "make-and-do"; the database looks much more impressive - surely the database is better?

3) Too much emphasis on anticipating potential or future problems and needs.

Yes, our system would not scale very well. If we had scaled up, we would have had to invent something else. We planned to deal with that problem if it arose (I don't recall that it did).

If managers had wanted statistics on the progress of trials, we could not have immediately generated them from the database. We COULD have got statistics - we would have to had printed out the list of flagged records from the database and cross checked them against the remaining labels. So we would only have bothered if someone had seriously wanted the numbers, not just for curiosity. (Perhaps that's an advantage too - in my experience a large amount of IT work  goes into enabling reports that someone might want someday, and I expect a lot of that effort is wasted).

If someone had lost the binder of labels we would have been in trouble. But we dealt with this by making sure everyone involved knew that the binder of labels WAS the system, so that nobody messed with it. A cup-of-coffee-all-over-the-binder disaster would probably have been recoverable (e.g. start all trials over again, if needs be, &  maybe make a marketing feature of our generosity).

There's a cartoon in which someone asks a programmer to "pass the salt" and twenty minutes later the programmer is still building "a system that can hand you any arbitarty condiment - it will save time in the long run". I think that about sums it up...