Project Management

It’s About Time: Intellectual Technology and General Education

September 6th, 2011  |  Published in EPPL639, Project Management

The first session of this fall’s Educational Technology Planning course met last night after losing a week to Irene. The course is an elective in the Educational Planning, Policy and Leadership program at the School of Education and is made up of a students in masters and doctoral programs in K-12 and higher education administration. The goal is to look at technology decisions through the lens of the leaders who will be responsible for selecting and managing large-scale education technology projects–chief information officers or chief technology officers. It’s a difficult course, since it requires students to integrate a considerable amount of technical information into a personal vision of how information technologies might impact education in the near to intermediate future.

The course is generally built around an authentic learning project for an outside client. This year presented an unusual opportunity since William and Mary is undergoing its first review of general education requirements since the invention of the World Wide Web. Michael Lewis, one of the co-chairs of the Curriculum Review Committee, is a mathematician/computer scientist who has been involved with a number of IT initiatives in the past, and we had talked about the possibility of the class looking at the role of “intellectual technologies” in general education. Obviously, I think that computers and communications technology have transformed society in ways that pose a whole host of technical, pedagogical, ethical, social and economic questions that need to be addressed much differently than we would have addressed them in 1990. For me the broad question might be framed this way:

How much does a citizen need to know about information (educational, intellectual) technology to be considered well-educated in the 21st century?

The project that I suggested to the class was writing a carefully developed white paper where we offer some perspectives, ideas, and thoughts about that question. We have 16 students in the class, 12 weeks of class time, and an incredibly broad range of backgrounds and experiences. Michael came and met with the class to provide an overview of the committee’s work to date and provided some history on general education at WM, and left us to determine if this was the project that we wanted to take on.

The discussion was spirited, but I’m not sure if it was effective or not. My fear is that I really didn’t allow the group the freedom to decide if these was the project that wanted to work on or not. I had put a fair amount of effort into developing a structure that I thought would allow us to get organized relatively quickly, but that structure didn’t seem to work for a fair number of folks in the class. The biggest concern didn’t appear to me to be the importance or substance of the project, but rather if there was enough time to complete it. (At least that’s what I heard.) My own sense was that it was a tight deadline, but we had the time and the tools to make a real contribution to the discussion at the College if we put our minds to it.

We decided–or maybe they acquiesced to my expectation–to give it a week working within the format that I had proposed and see where it goes. We’ll see where it goes.

How bad Is it?

August 28th, 2008  |  Published in Project Management

Back in the olden days, I was one of those people whose bedtime was established by end of the Johnny Carson monologue. Carson’s opening act often included an interchange where he would lead with the line “it’s hot/cold/smoggy and the audience would respond “how hot/etc. was it?” to set up the joke. To this day, when someone makes a statement “it’s whatever”, my mind responds with with the audience’s line. “How whatever is it?”

This time of year, I spend a fair amount of time trying to figure out “how bad is it”–not as a way of setting up a joke, but in trying to figure out what problems are important enough to solve “at the root” rather than just dealing with the symptoms. For example, we’ve opened a new building on campus and one of my staff members just spent about a third of last week dealing with issues have nothing to do with academic technology–she’s chasing down questions about wire molding, conduit, network connections, door locks and other stuff that clearly is not her responsibility. (I guess these things are technology related in some broad way–they all do have wires.) She gets the questions because she knows all faculty in the building and because there is no clear communication path established as to who really is responsible. When we try to figure out a way to deflect those questions so she can focus on things are clearly are her job she comes back to the relational question: “If not me, who?”.

In complex, decentralized, underfunded organizations, figuring out who actually does have the responsibility for even something (relatively) simple like coordinating all those building changes (and then documenting the process) may require hours of phone calls, meetings, memos, negotiations and communications–even staff training. Deciding whether or not to try to fix the root problem is a judgment call that we make dozens of times a day, and, more often than not, it’s easier to just spend extra time to solve the immediate problem rather than to try to dig down and fix the root. Our faculty are busy folks and they’re generally very appreciative when someone–whoever–helps them.

But I have to wonder what the long term cost is when “fixing the symptom and ignoring the cause” becomes ingrained in the organizational culture and it becomes the accepted way of doing business. In my real (non-William and Mary) life, I much prefer to deal with organizations where the simple things are simple. No matter how helpful, friendly, and courteous someone might be in helping me navigate the corporate run-around (think Cox or Comcast here), I much prefer not not to get embroiled in a mess in the beginning. I’m wondering if we’re as much a part of the problem as the solution?

The Importance of Finishing the Job

July 17th, 2008  |  Published in Faculty Blogging, Project Management

Dam2.jpg

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?

Photo by Flickr User Farm3 under a Creative Commons Attribution License