Posts Tagged 'faculty'

Want Better IT Service Design? Make CIOs Teach…

A little background for this post…I was recently accepted as a mentor in the Technovation Challenge program, which kicked off this week. The program’s goals are near and dear to my heart: promote women in technology. It’s an exciting 9-week program where teams of high school girls develop a business plan for, and actually build, a fully functioning prototype Android app — and then pitch it at the end of the program to a panel of outside experts. Totally cool! But I digress…

Tonight we discussed a five-step design process that the girls are going to use when developing their apps — Empathy, Define, Ideate, Prototype, and Feedback. The steps aren’t anything revolutionary or new — they just represent a good solid design process. But sometimes it’s good to get reminded about the basics.

So I got to thinking about “empathy” in the context of what we in IT do every day. Empathy, of course, is “the intellectual identification with or vicarious experiencing of the feelings, thoughts, or attitudes of another” (dictionary.com). Or, as one of our girls said tonight, “putting yourself in someone else’s shoes.”

I think we’d all like to believe that we’re empathetic to our users. We try really, really hard to understand the needs of our users; to identify with their experiences using the technology we provide. We can — and do — ask questions, watch interactions and behavior, and make careful *observations* — not *interpretations* about what we see. But is that enough to impact the design of our technical services in a meaningful way?

In the fall, I got the chance to truly put myself into our faculty’s shoes when I taught a semester-long course on Web Design. I’ve given a lot of presentations, conducted numerous trainings, and talk extensively to faculty about their experiences with and use of technology in the classroom. And *none* of that compared to the first-hand experience I gained teaching in the classroom.

There were a number of issues I experienced that I would have considered minor had I heard about them from faculty, prior to my own experiences. My first day of class the printer was out of paper. Another day the YouTube streaming was somewhat halted, buffering every so often for a second or two. And then there was the issue with the plug-ins, the sound dial, and so on — and all, truthfully, were minor from a technical perspective.

I’ve seen help desk tickets like these before, and have been empathetic to them. But I’ll admit, a little, teeny, tiny part of me has felt like you have to expect some level of…je ne sais quoi…when it comes to technology, and you just have to be flexible and, well, deal with it. Not that I’d ever tell someone to just deal with it, mind you. I swear.

While these little issues became quite large issues when I was standing in front of a class trying to teach, what surprised me most about my experience was my ability — or lack thereof — to use the technology in place for me. Quite simply, I couldn’t. I’m a highly technical user, but when it came to using our technology in a real-world setting I couldn’t do much more than use the most basic of tools — the computer and projector. The classroom is nicely equipped with software to allow faculty to show their screen to students, or show one student’s screen to the class — both of which would have been helpful in my class. While I’ve actually pitched the benefits of this program to our faculty, and conducted some of the training on it, I couldn’t work it “on the fly” when I was trying to also teach on a different subject matter.

So what does this have to do with empathy? We can *vicariously* experience what our users do and gain some level of empathy, but nothing compares to the real thing. I look at our classrooms and our instructional support tools in an entirely new way because of my experiences last semester.

If institutions want to build better relationships between their faculty and IT — a connection that is generally presumed to be shaky, at best — I believe they can do no better thing than put their CIOs and senior IT managers into the classrooms to teach. Having that experience did not make me an expert in teaching or in the needs of faculty — far from it — but it did provide me with a much better framework for asking questions, observing behavior, and intellectually identifying with our faculty. And that’s the goal, right?

Death of the Computer Lab?

Question: What are the most popular buzzwords in IT?

Answer: Last year, the “cloud”. This year (so far), “VCL” and “VDI”. As in, if you can build a virtual computing lab (VCL) using virtual desktop infrastructire (VDI), you can shut down at least some of your computing labs and save money as a result.

Really???

Everything we know about computing labs indicates that lab usage has *increased*, even as the number of student-owned computers/laptops has risen to near universal levels. Let me rephrase that. Other options exist, but usage has increased. And yet we believe that the introduction of another option (ie, VCL/VDI) will now decrease usage/need?

Ummm….remember when computers and email were supposed to help us move to the “paperless” office? Yeah, I’m getting more paper than *ever* these days, too.

Don’t get me wrong. I’m a huge fan of VDI. We have a virtualization strategy at Menlo that extends far beyond the lab (more on that later), and are very excited about VDI’s potential — as a change agent for how we deploy desktops across the institution, and as an extension of the physical lab. But not as a replacement for it.

Here’s how I see it…

Today we have specialized labs that each run a different set of software. So to teach a Photoshop class, you have to reserve lab #1, and to teach an accounting class with Quickbooks or another accounting application, you have to reserve lab #2.

A VCL/VDI solution changes this, because you can virtualize your Photoshop desktop or accounting desktop, and then allow access to that desktop from any lab, or really, any location. This enables your faculty to reserve any lab they want, but unless you have dozens of underutilized labs, doesn’t change the fact that faculty will still want to teach their classes using the software, which generally means, in a lab somewhere.

And keeping in mind that virtually everything we do is computer dependent these days, and more and more disciplines/professions are using specialized software, the instructional usage of labs is only bound to increase. In fact, we built another instructional computing lab at Menlo last summer, and it’s already nearing max capacity (and usage in our other labs has not decreased).

Does that mean you shouldn’t explore VCL/VDI? No!!

In my view, there are a good number of benefits that VDI can provide your constituents, and your staff. Better access to software, increased life of hardware (you can run a virtual desktop on the equipment in your physical labs, too, not just in the ether), easier image/desktop management, greater flexibility, simplified support, and so on. Presumably lower costs too.

So is there a strong case for virtualizing your desktops? I believe so, yes. But as for those reports about the death of the computer lab as a result? Ehhhh, not so much.

Maybe It Really *Is* You

Most of us have that person (or persons) that we just can’t seem to work with — a fellow student, employee, colleague, faculty member, administrator…you get the picture. “Oh that so-and-so, s/he’s just a complete [insert favorite adjective here]. S/he’s impossible to work with; everyone says so.” Sound familiar?

So here’s the thing — if you want to change that dynamic, perhaps the person that needs to change is *you*.

I met someone recently who does mediation for a living. When I asked what was new in her profession, she started talking about “narrative mediation.” The basic premise is this: conflict is derived from how we perceive the situation or person we’re dealing with. In the case of personal conflict, we create a narrative for the person based on some limited set of interactions and/or events, and then filter all subsequent communications and interactions through that narrative. We may even completely filter out some things the person says or does because it doesn’t fit our narrative.

So, if you want to change the interactions, you need to change your narrative. Or, alternately, change *their* narrative of *you*.  Or both.

Of course this is easier said than done. It’s hard to see past an initial impression, or an early slight, to conceive that someone’s actions may not be driven by the things you perceive them to be. And then there are subtle external influences that help to shape our narrative about people, groups, or situations.

Take, for example, the IT-faculty relationship. Ask an IT person about faculty and you may get a roll of the eyes and a comment like “oh, you know those faculty…they’re a different breed.” Go to an IT conference and you’re likely to hear a crowd giggle and clap for statements like “faculty, a thousand points of no.” (Yes, this really, truly was said by a very prominent speaker at a conference I attended).

With this type of priming, it’s no wonder that even the slightest negative interaction with a faculty member — who may be completely and rightfully upset about malfunctioning technology in his/her office and/or classroom — feeds a narrative that serves to perpetuate the bad IT-faculty relationship many have come to accept as “normal.” And it works the other way, too, with narratives that faculty have created for IT folks.

A colleague wrote an article recently that referred to faculty as “a thousand points of know,” which I thought was a rather clever reshaping of the original quote, and, perhaps, the narrative that goes along with it. Would your narratives (and the relationships that go along with them) benefit from some reshaping, too?

The “Trouble-Free Semester” Challenge

Recently I sat down with our Faculty Senate steering committee to discuss ways to engage faculty in short and long-term IT strategic planning. While we had a protracted conversation on the subject, one comment stood out—both for the insight it provided me and for the subsequent conversation and thought that it has sparked. Roughly paraphrased, it was this: “I can’t even begin to think about what technology I may want in the classroom in the future when I can’t trust that the technology that’s there now will work [and she gave an example of a classroom that wasn’t functioning properly]. Give me a semester without any technical problems, and then we can talk.” My gut reaction and immediate answer was, “it’s not possible.”

I can hear you faculty-types now…typical IT answer, always “no.” Guilty as charged, on this one anyway. But in fairness, my thoughts raced to all of the different types of reported “IT issues” we encounter in any given week. A fair number of them aren’t really technical problems—they range from power issues (something was turned off) to user “tinkering” (in a classroom another professor or student may change a setting), to just plain old user error. There are a decent amount of truly technical problems mixed in, of course—and we can, and should, minimize those. But when all issues are lumped together as “IT” problems, well, I feared we would never be able to meet the “trouble-free semester” (TFS) challenge.

I’ve thought about this comment a lot since that meeting, and have revisited it several times in conversation with our Senate chair. Underlying it, I believe, isn’t just a frustration and lack of confidence in the technology, but with the IT department itself (based on tenuous faculty-IT relations with several previous IT directors). So I know, and accept, that my first job must be to cultivate relationships with our faculty and build trust based on open communication, collaboration, and accountability.

With stronger faculty-IT relations, a “trouble-free semester” is not at all out of the question. Together, we can discuss our respective roles and responsibilities in resolving both real and perceived technical problems, and use real data—via Help Desk tickets—to quantify our current level of IT issues, and set targets for reducing/eliminating them. Already, as a result of these initial conversations, we (in IT) are discussing maintenance measures, from regular classroom “check-ups” to automated nightly restarts of classroom computers to reset key settings, to prevent problems *before* they occur.

And so, dear faculty…I believe we *can* create that trouble-free semester, after all. Will you join me in accepting the TFS challenge?


@rclemmons on Twitter

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 25 other followers