The Importance of Finishing the Job

Some time ago I was responsible for a camp in the Ardirondacks with a big dam that controlled our lake. One summer we had some problems and had to bring in an engineering firm to do some work, and one of the engineers was explaining why building dams is so expensive. Generally about 90% of the work is invisible: rerouting stream beds, pouring footings and installing other infrastructure elements that, on the surface, have noting to do with stopping the flow of water. While that’s true, the entire project has no value unless you finish the job and do the last 10% that actually stops the water.

In some ways many academic IT projects are a little like that, but with the numbers reversed. Buying and installing hardware and software, configuring systems and running pilot tests all take time and technical expertise. But for many of our projects, the real work that produces gains in teaching, learning or productivity just begins when those initial projects are completed. Producing those gains may take years of communication, evaluation, training and re-engineering. I wonder how many of us really understand that and commit to finishing the job when we launch some new initiative. Would we focus our time differently if we were more realistic about what we were committing to?