« Real Life Getting in the Way | Main | SecondLife ... Watch Out »



Feed You can follow this conversation by subscribing to the comment feed for this post.


I am always a little wary of porting business solutions (or methphors) into education (higher or K-12). Here I think the problem is that if you move resources toward the popular service or solution you potential lose interesting work being done my the minority that find the less popular tools useful. There is no way in that system to measure, or take into account, tools that are extremely powerful for a small group (the long tail notion). This seems to me to run against the idea of what universities are designed to do -- work that is interesting to a small group of folks that has the potential to make large impact (or not). This is the foundation of the idea of basic science, that it need not have applications or be popular or for that matter even understood by the general population, but that is pushes the field. Is this any different with regard to technical resources? Do we really want them going to the most popular uses of technology on campus? What would that look like? What would it mean to be an innovator on a campus where the innovation must be immediately (or quickly) very popular to be fed resources?

Cole Camplese

The question I am really asking is how do we become more agile in higher education? If we don't find ways to take risks with emerging trends then we are dead in the water. If we don't embrace a beta style mentality can we test out new approaches to old challenges? Or should we only focus on large University wide projects like email, calendars, and back office systems? We are living in a new era of technology utilization for teaching and learning ... how do we move the tail forward more quickly on our campuses?

gary c.

I’m hearing two issues: the idea of perpetual beta, and the notion that a tech unit can create some level of structure for the management of exploration/emerging tools that evaluates those tools and moves selected ones along toward sustained support and integration (or your definition of a “service").

I’ve always thought of the ongoing beta status of gmail, flickr and the like as the webapp form of versioning; instead of downloading updates or new versions, web-based tools fix/update without the necessity of distributing those updates. Thus, they don’t have to “announce” updates I the same way that client-based software needs to. In short, I don’t see “beta” as a clue to a possible lack of staying power. I see it as analogous to purchasing installed software X v2.0, understanding the implication that there will be an X v.2.1 distributed at a later date. Maybe this is a fundamental misunderstanding of perpetual beta on my part.

The second issue is very interesting: how can an organization evaluate new technology in a planned, controlled way that recognizes the potential for some tools and moves those high-potential tools along toward a point where they integrate into the IT support structure (or “service”)?

At Educause 2006, some folks from Duke had a great presentation that outlined their phased approach to transitioning innovations from idea/experiment to full-blown service. They basically see three phases:
1. Experimentation- white papers, pilot projects, etc.
2. Extension Transition- support for promising tech; identifying use cases
3. Standard Support Integration- widely available supported (helpdesk, etc).

Their presentation files are available at: http://www.educause.edu/ir/library/pdf/EDU06190.pdf

They would seem to agree with your point about problems with scaling to the total user base straight out of the box; resources would most likely not allow for an approach like that. Some of these ideas are addressed in innovation/change management literature, specifically stuff on “ambidextrous organizations” (organizations that simultaneously engage in ongoing/mature operations and innovation/exploration operations). What the literature seems to indicate are those organizations that include both ongoing service operations and longer-term innovation efforts are more successful in diffusing radical innovations. In other words: agile is good, but agile and stable in the same organization can pay dividends.

My sense from the presentation was that a structured approach helps by allowing for risk-taking with emerging tech while providing some measure of assurance that selected tools have been chosen for a reason and not simply on the basis of novelty. Early on, the faculty are in more of a partnership role, so "emerging opportunity" would probably be more accurate than "service" through the first two phases.

Interesting topic.

The comments to this entry are closed.