Technology for your Mission

Yesterday I attended HigherEdCamp Philly. This unconference (structured as a bar camp) brought individuals together to talk about technology in education. The primary focus was, not surprisingly, Web 2.0 (a term I am somewhat tired of hearing).

I attended for two reasons. The first is that institutes of higher learning often face the same issues that non-profits do. They can be slow to change, and often have an institutionalized fear of new technologies. They are also mission focused and dedicated to helping their clients (students). The second reason is that I have toyed with entering higher education at some point later in life. Either by getting my Ph.D. and teaching or by entering the administration and staff.

I’ll be writing more about what I learned at the conference, but I wanted to share a few of the things that really stood out to me. I’m copying these straight from my notebook — they are unstructured, inconsistent, and may make no sense to anyone else. However, I still think a few of them are interesting and sometimes raw ideas are the most thought provoking.

• What can IT/Infrastructure learn from web design? 
  • EX
  • user-centric
  • cyclical design
  • flexible / innovative

• What can web learn from IT/Infrastructure?
  • Formalized process
  • Excelent project management processes
  • Well established metrics

• Top down doesn’t work. It may be inefficient but buyin starts from the bottom.

• Don’t just support the mission — empower the individual

• Technology is working to mitigate specialization of labor through information accessibility — everyone can be an expert. Maybe not enough to do the work, but enough to take professionals off their pedestal and help consumers engadge.

• The switch to a service based economy is a metaphor for open source software — the tools and raw material are available to everyone, but you still have to pay for the expertise to put it all together into something useful. OSS developers sell a service not a product.

• Technology is allowing us to achieve the better teaching methods (problem-based learning, etc) psychologists have been telling us about for year. We need to harness it better.

• It’s impossible to really test huge systems that transform the very way we interact (example: blackboard, facebook) in any quantifiable way. Instead we need to find really subject-specific applications and test them with hard metrics. Do this a couple hundred times, generalize common results, and apply the lessons learned to the system as a whole. This could apply to large infrastructure projects too.

• Education is now similar to open source. Everyone has access to the raw materials and information, but we still need the experts to facilitate the process and teach us how to do something with it.

A coworker of mine likes to say that clients pay consultants to tell them what they already know. I would agree, with one small change. Clients pay us to help them understand what they already know.

Our clients already know they need a new server. They already know their database isn’t tracking the data they need. They know no one is visiting their website. But they don’t understand it. They don’t know why, and they certainly don’t know how to go about fixing it. And frankly, telling them what they need to do in the form of a document isn’t going to help.

A few years ago I volunteered at a community center in west Philadelphia. There I taught basic computer skills to under-privileged adults as part of job training. If there was one thing I learned, it was that having them memorize a set of steps to save, or print, or italicize, just wasn’t helpful. As soon as something went wrong, they were out of luck. Instead, I had to teach them the process. Explain context menus, tool bars, contextual editing. I had to teach them how a computer worked. Only with this knowledge could they figure things out on their own. Not that I was particularly good at it, teaching this kind of thing proved very very difficult.

Creating a Strategic Technology Plan is no different. You can explain the steps needed to gather requirements and implement a database as much as you want, but it isn’t going to do them any good. You have to help them understand the process, the reasons for doing things in a particular way. They have to understand how metrics drive fund raising drives implementation projects. They need to understand why long term budgeting is important.

The deliverable is a piece of paper that will be shown to the board once and put on a shelf. The valuable part is the lesson. This is what our clients pay us for.