Learning From Our Failures

If you get a moment, read Meredith’s blog entry, Technology Failures: My Brilliant Failures on her Information Wants to be Free blog.  (Meredith is the Distance Learning Librarian at Norwich University in Northfield, Vermont). A couple of her “failures” center around employing Web 2.0 technologies, anticipating that her staff would be as excited about them as she was.

Believe it or not, I had started an article back in May 2004 along a similar vein – examining some projects that just didn’t work in our district and why. If one could identify common elements of failed technology implantations, perhaps one could use them to predict whether future implementations will be successful or plan strategies that will minimize the likelihood of failure. Leaving the door open, of course, for new and more inventive ways to muck things up.

From my earlier draft...

___________________

While the Mankato Schools’ tech department has a long string of technology “wins,” there are three notable “losses” that have occurred while I have been the director: the purchase and use of an early digital video editing system, the implementation of interactive television, and the attempt at creating a data-mining resource. While none of these projects was either financially or educationally catastrophic (I AM still employed), each cost the district and our department many hours of professional and technician time and decreased our credibility.

So what the hell went wrong?

Digital Video Editing (1996) At this time we had a young and ambitious video tech on staff who wanted in the worst way to replace our analog editing equipment with the latest in digital editing software. I think we laid out about $13K for a system that just never did work quite right. The tech became so frustrated (and probably tired of my questions) that she quit and the equipment sat unused. iMovie made an appearance not long after, and the rest is history. Lessons learned?

• Don’t buy a technology that is so complicated only a single person can run it. Or cross train if you do.
• Don’t try to fix it if it isn’t broken. Our analog system couldn’t make someone disappear in a shower of sparkles from a scene, but for about everything else it worked fine.
• Wait for the technology to mature.
  

Interactive Television (1999) At the cost of about $20K (from a grant, not local dollars), we installed an interactive television hook-up in our district staff development room. Other than one university course, an after school advanced math class, and a few meetings, the equipment did not get used and we removed it after two years. We now use other ITV facilities in town for meetings when needed. Lessons learned?

• Don’t build it and hope they will come. They won’t come. We might have had better success had we placed the set-up in a high school rather than in our annex to a high school.
• Don’t assume that just because others use a technology, you need it too. Our smaller neighboring districts use ITV for offering classes that the single small district alone can’t provide. They use it to give high school students the chance to take college courses. Mankato doesn’t really have low incident classes because of the size of our high schools and we have several colleges within easy driving distance for kids wanting classes at that level.
• Don’t forget to take entrenched interests into account. Offering Japanese sounds like a wonderful idea until your current world language teachers see it as competition to their own class offerings (and job security).
• Wait for the technology to mature. Of course, I’ve been waiting for quality, easy-to-use, and reliable ITV connectivity for 15 years. It just hasn’t happened.
  

Data-mining (2001) We contracted with a regional tech center in Minneapolis to develop a data ware-housing, data-mining solution. About six months into the project, the tech center closed. We found another developer. He bailed after deciding his company would rather focus on online testing. Total lose of funds was about $20K and countless staff hours of planning. We have since joined with a group of schools who all use a commercial data-mining product, Sagebrush Analytics, that is supported by the (solvent, I hope) regional tech center that also supports our student information system. It’s still been a struggle, but it works to a degree. Lessons learned?

• Don’t go it alone. Our project, while important to us, was small potatoes to the developers. We did not get priority service. If there are not many schools asking for changes or fixes, you won’t get much attention.
• Don’t buy a product without thinking of the service and support component. Duh!
• Figure out ways to grow a big system. We started trying to capture every test score, every intervention and every piece of student demographic data. Better to get a subset of things working well than everything badly.
• The new project is really the assessment department's baby, not ours. We provide technical support and implementation, but not leadership.
  
• Wait for the technology to mature. Even after 3 years of using the commercial Sagebrush product, we are still only part way to having a fully functioning solution.
  

Of course, one can’t guard against the arbitrary. Businesses fail, people quit and products are discontinued. But mabye better planning can help minimize these potential catastrophes.

In general, my rules are now:

1. Don’t do it unless there is a genuine task that needs doing or a real problem that needs solving.
   
2. Go with the tried and true and in a group.
   
3. Make support as high a priority as functionality.
   

The older I get, the happier I am to let others be on the “bleeding” edge of technology implementation. Does this mean it’s time for me to step aside and let a braver soul lead? I think about this often.

Other things you may have learned from failed tech implementations?