Higher Education IT

A number of years ago (7?), a colleague of mine at Stanford – Carlos Seligo – introduced the concept of “Orchids and Weeds.”  He meant it jokingly at the time, but it has stuck with me ever since.

Basically, there are two ends of the spectrum when it comes to technology, support, and adoption.  There are orchids, which are elegant, beautiful and perfectly aligned with needs but require an incredible amount of attention and resources to get running and properly supported.  It is unlikely that support will become more efficient over time.  Weeds, on the other hand, spring up organically and often as ancillary to something else.  They germinate quickly and soon adoption is very high and usage has proliferated.  Weeds might even be used in ways never originally intended.

An example of an orchid might be the Sakai Learning Management System, which has been developed by universities, for universities, but is quite a beast to implement and manage.  Perhaps even some of the major Microsoft products – Sharepoint comes to mind – would be orchids, too.  They can be ridiculously powerful if done right, but needs a lot of resources to get there.  The two “big” weeds would be e-mail and SMS text messaging. SMS is in particular is a great example.  Originally designed so that cell company employees could report coverage outages and other problems, it has become the primary way for many people to communicate (I send about 2000 texts a month and yet use fewer than 400 minutes).

It is important to note that there is nothing inherently bad about an orchid.  By definition, it is beautiful, elegant, and a perfect solution for the job.  It offers very high value and probably commands a high price (the amount of effort users are willing to expend to access the service).  But the cost is also extremely high.  So the overall value-cost gap (or V-C “wedge” as we’d say in my Capstone MBA course) is smaller than, say, text messaging.

But if the fundamental basis for maintaining a service portfolio is value, orchids are just fine.  You just have to pick and choose the right ones.  And that means a strong rubric for getting rid of the useless orchids (just pretty, but not the right fit) from the truly wonderful ones.

Basing services on value provision is pretty simple.  Well, actual “value” is hard to quantify, even in the business world where there is a number for everything.  But if you start with price – again, the expense of time/effort/distance traveled/hoops jumped through/etc that a user is willing to take on in order to use the service – then you can get an idea of value.  Value is always the same or higher than price (unless you have one seriously messed up measurement system).  If you put something somewhere (physical location of a high-end lab, a web service behind so many clicks of the mouse, etc) and people are still rushing in droves to use it, then the price is probably quite a bit lower than value.  Whether the price is too low is unclear, but it’s not like you’re going to disassemble that lab and move it farther away from the dorms or put even more clicks in front of the web service.  Bottom line – value is high, and it can be gauged if not measured exactly.

So once you have that, you just roll out services that are high value or high V-C.  The value could be high in an absolute sense, in which case cost is not an issue (striking a deal with a cloud-based backup company where the student pays and you get all the kudos but none of the liability).  Or it could be high in a relative sense (buying a bigger SAN for $75000 to do multiple redundant backups of faculty and staff data, on-site, in exchange for peace of mind to those users.  cost and value are high).  But if something is low in value, just don’t bother with it.  Because if it’s not of value to anyone, why are you wasting resources on it?  Worst case scenario, cost is HIGHER than value, and you’re just burning resources for nothing.

Ideally, you go low cast and high value – look for weeds.  Get as many of these as you can because they require low overhead but adoption will be high.  I’m not sure people will “value” it the same way they would with other things but they will surely use the service.  Align your staff to take advantage of these.  Have fewer staff managing more weeds – the ratio will be different.

Then go looking for orchids.  You will probably need project management staff just to test them, then a much lower staff:service ratio to maintain them.  But if you figure out the right potential orchids during testing, then deploy the best 2-5 or so and it’ll be worth it.

• On our 2008 Honda CR-V, we have different beeping, alarm tones for leaving the key in ignition, headlights on, and parking brake on.  3 different tones.
• On our 2005 Mazda 3, we have a single tone that is used for both the keys and lights.  No parking brake.
• Of all cars, the 2004 Jeep Wrangler – bare bones vehicle, zip-up windows, etc – had a single warning signal for the lights, keys, and brake.

How is it possible that that three different cars utilize different methods for the simple task of notifying a driver that he or she has forgotten to do something, or left something behind?  The ones that are most similar – the Honda and the Jeep, are almost as far apart as possible in terms of types of car (well, if it was an Acura or something that would be farther…).  And somehow the Mazda can’t even bother with all three tones.  The features of the Jeep – a car WITH NO WINDOWS – are more user-friendly than those on our Mazda.

It’s not as if the beeping sound for the brake was first invented by Jeep, musth less copyrighted (which would be required in this scenario, since the Jeep is older than the Mazda).  Nor the idea of different tones being used in the Honda.  And it can’t possibly cost much in terms of Cost of Goods Sold (COGS), which affects margin, for there to be either three tones or three different tones.

If I had to fill out a form right now asking for features I’d like in a car, having tones (same tone okay, since I can never remember which tone is for which problem) for all of those items would be on that list.  These simple things.  Just take the simple things that others have done, and make sure that you have at least those same things.  Then innovate from there.

How is this at all relevant?  Simple – if you’re running a Help Desk, get the basics of support, time to resolution, quality of customer service, etc , to the standard that others schools with roughly the same resources and limitations have achieved.  If you have a small server farm – or a giant data center – look at what others have done and just flat out copy the best of breed basics.  I don’t mean the whole kit-and-kaboodle.  I don’t mean just copy every last detail.  But there have to be common denominators that have sound solutions, proven over time, that are easily replicated.

Just as Mazda should not spend much time deciding whether or not to put in 3 bells – which can, I think, be concluded is a better solution than just 2 bells – why not just start off with 3, and spend more time deciding if an auxiliary audio input should be put in or not? Or, a year later, when all Mazda 3′s had those inputs because basically all cars had them, how about making the front console more user-friendly or improving something else?  Innovating beyond the basics.

I’ll admit that we are not doing as good of a job at this as I’d like.  And hopefully as we’d like, either.  But once we can get everything to a baseline standard – and it is definitely feasible – then we can start to really mix things up.  Think of new things and build up an overall structure that is above and beyond.

So let’s get started on the foundation.

In my previous post, I discussed the importance of dollars per capita re: resource shortages rather than simply number of staff or absolute budget.  This may be something that all IT leaders have already discovered on their own, but to me, divorcing myself from thinking in terms of absolute budget (well, of course Santa Clara has a smaller budget than Stanford or a huge state school) or number of staff and thinking in relative terms really helped open my eyes.  Basically, the real issue at the university or even project level is how much funding is available per user/customer/student/etc.  It’s not about an absolute budget.  $10,000 for 1 customer is enough to buy a whole dedicated server plus a decent bit of enterprise software.  But the same budget for an entire project meant to serve 1000 students means sapping staff time and other resources from other projects and initiatives.  That actually provides poor DPC for the one project, and decreases DPC for the other one(s).

Of course, low DPC is a problem that plagues many organization, especially higher education.  Let’s face it – many corporate IT departments, for all their notoriety for being somewhat “faceless,” would still laugh at higher ed budgets in relation to goals.  When a for-profit company decides to do X, and doing so requires $Y, then they find the money (or they cease to exist as a company, I suppose).  That’s not the case in higher ed.  So how do we address low DPC?   (more…)

At first, this post started out as commentary about the challenges that schools of about the same size as Santa Clara University face re: technology, infrastructure, and other needs in relation to the available resources.  That, in turn, would lead to some discussion on how to best address such opposing forces.  This was fundamentally about how Santa Clara was just big enough to need enterprise-level services but not quite big enough to have the staff to maintain such systems, especially over time.

However, I found myself having a terrible time writing because I eventually realized that this isn’t about the size of school.  Whether your institution is a research or small liberal arts one, state or private, funded primarily by endowment or tuition, what fundamentally matters is operational dollars per capita. (DPC)

In other words – for any one (relatively large) project, the issue of size vs. resources is about how much money is available per student/faculty/staff/overall user group.

On the one hand, this sounds really obvious.  Sure, if one has less dollars, then it must be less dollars per person.  But if the project is small with, say, 100 users, then it’s possible that even a small school could get a research grant that yields high DPC.  Which means resources are likely going to be sufficient.  Also, universities of roughly the same size could have wildly different ratios, leading to completely different environments.  Santa Clara University and Stanford, for instance, differ by only 1000 or so undergraduates (SCU being about 5400, Stanford 6500).  Yet Stanford’s huge endowment, research funding, plus incoming tuition make for a much higher DPC figure, on average, than is the case at SCU.

Both SCU and Stanford are “big enough” to need a large scale ERP like Peoplesoft.  Stanford has probably 25 systems administrators in their overall group, not counting the database administrators and storage administrators that help round out the PS operations.  SCU has far fewer.  Peoplesoft itself is scalable – there is likely little difference between managing 5500 students and 2000 or so faculty and staff at SCU vs. 6500 students at 8000 faculty and staff at Stanford, in terms of the software.  But management is not scaleable in the same way.  It might take 10 admins – systems, database, and storage – plus a handful of others (security, data center managers, etc) just to get PS up and running.  At Stanford, because of a much higher DPC figure, will always have that number available, plus more to make the process more and more efficient.  SCU might have just barely that number of staff to begin with and once other projects are considered then, in reality, staffing is insufficient.

Dollars per capita.  That is the problem, and the “resource shortages” that it produces in institutions with low DPC go much further than simply having enough staff for a particular project.  The shortages in one department lead to decisions to cut back here, eliminate a service there, etc, that another department (perhaps one in the same overall organization) actually needs for its constituents.  So now low DPC has created a spiraling, self-reinforcing interdependency of inadequacy that is no one’s fault, but must be arrested at some point.

Case in point:

1. Novell Groupwise e-mail system is managed by Networking and Telecommunications Group BU
2. due to staff shortages, NTG has decided that the feature that allows standard ActiveSync connectivity (Mobility Pack) for devices will not be installed.
3. Service Center BU has identified that providing connectivity for devices such as iPhones and Android phones is a needed part of their portfolio
4. The devices support ActiveSync natively, but of course Groupwise does not.  Service Center BU has to purchase and manage a third-party product that acts as middleware and is close to but not quite perfect ActiveSync functionality.

The result:  most features work on iOS, Android is hit or miss if it’s anything other than stock, original versions of applications (AOSP), and on both users find certain features missing, or mishandling of events or contact details.  I personally have had to basically hack both of the Android phones I’ve had so far in order to get them to work (even though the first one I had is specifically mentioned on the third-party vendor’s site as being “certified”).  One of my staff that uses an iPhone who eagerly agreed to be the iOS support person has learned that there are, in fact, a few quirks that he has to help users with.

In this case, because of DPC being low for both groups, neither is able to take advantage of scalability or other options and work together to provide an identified, needed service via tools that are actually already built into Groupwise.

Let me make this disclaimer now – this is not a criticism of SCU Central IT.  It is indeed very tempting to point fingers when I have a faculty member doing just that at me because the mail app on the iPhone isn’t working “as expected” or because that professor cannot buy that Android phone he or she wants because it is not compatible.  But I don’t think it is right to blame either group, or anyone in those groups, in Central IT.

As I have been considering various changes in my approach to management, leadership, and IT in higher ed, I am reminded of the importance of accountability.  This is one of the most important parts of a successful team – it is part of the foundation upon which productivity and teamwork rests.  In fact, it is part of a critically important cycle that is self-reinforcing – each phase of the cycle helps strengthen the continuation of that process.  Accountability begets ownership.  Ownership leads to a sense of responsibility.  Feeling responsible results in a greater understanding of accountability.  And the cycle continues.

Accountability must be pervasive, as well.  It cannot be just to one’s supervisor or manager that one is accountable for his or her activities and performance.  Peers must feel that they are part of the success of each of their colleagues and the team in general.  Conversely, not only should managers be able to hold staff accountable, but peers should have the ability to “call out” those that are not helping meet overall expectations.

The thing about accountability as a departmental, top-bottom, bottom-top, side-side trait is that nothing is explicitly confrontational.  Even the most severe conversation becomes about team and goals, rather than personal slight.  Instead of “you are messing up my ability to get my job done,” one can say “we must rely on each other to get this project done to achieve a common, team goal.”  I realize, of course, that we do not live in a utopia and that the former statement will still occur even in the most collaborative of environments now and then.  The point is that co-dependency can become the foundation for discussion in a system that relies on accountability and shared ownership.

The question, therefore, is how to build what I call a “platform” for accountability.  Much in the way that Windows or Facebook is a platform for development of software, accountability can be the foundation upon which projects and communication is constructed.   (more…)

I find myself at a strange intersection in my professional career.

On the one hand, I have prided myself on “doing more with less” in terms of what our department has accomplished with a significantly smaller budget than comparable groups on campus (to be clear – the “more with less” motto that is often used when budgets get tight or staff are laid off is one which I am firmly against and perhaps abhor as a managerial method.  We can work on getting every last drop of productivity out of our resources, but we can never do more than 100% of capacity, and we should never ask our staff to even try).

On the other, I find myself saying bold things that I have yet to back up with my own actions.  For instance, of late I have spent much time thinking about the future of IT in higher education.  This has been stewing in my head for some time now but Theresa Rowe‘s opening plenary at the SIGUCSS Management Symposium in San Diego really crystalized things.  We simply cannot keep doing things the way we always have been.  Maintaining the status quo – including the thus far incremental improvements to our systems and services – is not sustainable.  We must radically reassess our service portfolios and even reconsider whether we have the right job descriptions – much less the right people – to meet student, staff, and faculty needs going into the next decade or more.  Are we structurally sound and prepared to meet the challenges of delivering Google and Facebook-like services and innovation on the budgets that we have?  Can we really keep trying to achieve enterprise-level performance on budgets that corporate IT departments would laugh at?  I have long asserted that we have to make tough decisions and invest in those services that give back the highest value, not just the ones we “have always done.”  Rowe gave an even clearer and more comprehensive analysis ranging from technology trends to HR to management to budgeting.

Yet…have I done this in my own job thus far?  Have I actually led my staff in the charge to reduce our service portfolio to offer only high value services?  How do I even know the value level of our current services such that I can make an assessment?

I have spent the last 4 years building up the reputation of Law Technology and Academic Computing at Santa Clara Law School.  We are not perfect and many people know that.  But few point to those deficiencies as symptoms of a dysfunctional department.  There is a faith in our department – and the effort that we put into each of our duties – that has become the fundation of our role at the school.  I am extremely proud of where we are compared to when I arrived.  It’s been a combination of marketing, professional development, management, hopefully some leadership and definitely some changes in personnel.  But it’s real.

And it’s time to take advantage of it.

2012 will be our “crash” year.  This will be when we take all of this goodwill and faith in our department, bank on it and make the potentially radical changes that address the changing needs of academia.  I am convinced that, in the long run, all of our changes will make people happy.  I am also certain that in the short run several people will be upset by the removal or alternation of some services.  But during 2012, we will assess where we are, decide in what we will invest, identify what we must cut in order to achieve those goals (and things will be cut – I will not allow our portfolio to just increase without change elsewhere), and make significant changes.  We will use personal interactions, school and university-wide marketing, a bit of political maneuvering and I’m sure some apologies.  But this will be the year.

January 3 is when we return to work.  I’m sure you’ll hear from me by the end of that week…

The strangest thing happened to me the other day while helping train some students on a collaboration suite we have at work.  The professor had already explained that students would be working in teams, with their laptops, to develop the beginnings of a legal outline.  They would use the software/hardware solution – powered by Tidebreak’s Teamspot software – to interact with the shared document.  Hopefully, the students would discover greater productivity and learn more about how to develop the outline through this collaborative effort.

That’s all and good.  It’s to be expected and the professor had a really great and open mind about how to use the suite that night, possible uses in the future, and ideas for best practices.  What was not expected was students asking me this:

“Do I have to take part in this project?”

or

“I downloaded the software.  Now I’m trying to decide if I want to install it.”

My basic response to these comments was along the lines of “well, it’s for a class assignment, and I believe the professor wants all of you to work as a team, with your laptops, on the shared display.”

This did not produce much of a response.  In fact, one of the students showed a rather blatant disdain towards me and commented on how she was willing to install the software only because she was using a Mac.  She would not have done so with a Windows machine.  Clearly implying that for some reason I would be recommending the installation of software that was either going to compromise her computer or, even worse, was malware to begin with.

This honestly baffled me.  On the surface, I couldn’t believe that students would question whether they should take part in a class assignment, as requested by the professor.  Even if it’s a situation and/or environment with which they are unfamiliar – this is the professor asking them to do an assignment that is, ostensibly, critical to their education (are assignments ever not critical to your education, really?).  And while a bit of caution when installing software is always prudent, why would someone think that I, an assistant dean, would be asking them to install malicious software?

We in Educational Technology are in the business of improving the teaching and learning of our respective fields (or, perhaps, to challenge existing paradigms that have generally governed those methods).  Most of the time, we seek out innovative technologies but, more importantly, act as consultants and work with faculty to find a tool – whether new or old, cutting-edge or somewhat banal – that will help them in their tasks.  We are here to help improve things.  We are not here to cause problems, to decrease productivity or success potential.  We are certainly not here to put viruses on your computers.

I’ll admit that when I introduce myself I was sufficiently befuddled that I sounded 100% geek.  I didn’t get into how part of my department’s charge is to introduce innovative technologies and methods to faculty.  I sounded like a robot.  A nervous, very geeky robot.  But that’s not the point.

If I’m there, it’s because the faculty member has agreed that there is potential for benefit and/or improvement to teaching and learning.  If I am asking you about your progress with some technology, it’s because I want to see how far along you are in getting set up to use that technology to improve your classroom experience.

Netgen, Gen X, part-time, full-time – whatever student category you fall into – understand this.  The faculty, the staff, and certainly my department are there to help.  It is to your benefit to let us do that.

A while ago, I read an article describing what is commonly-called the “NetGen” or “Gen Y” (loosely defined as those born since 1982, though I don’t personally agree with that demarcation) as being very comfortable with “cybernudity.”  In general, this means that those that have grown up with computers and the internet as everyday tools of life (as compared to a “new” invention that has changed the way one works, interacts, etc) have not real problems with the world knowing everything about their activities, their interests, their religious feelings, etc.  You can see this everyday in seemingly pointless Twitter posts and Facebook status updates.

The article also claimed that the NetGen is simultaneously fiercely protective of its identify security.  While these individuals don’t mind if strangers know that they are at the local coffeeshop meeting with friends (via a FB Places or Foursquare check-in, perhaps), anything that would lead to identify theft is completely out-of-bounds.  You can know where Jane Doe is, but you do not get to be Jane Doe, no matter how “cyber-naked” she is.

This brings us to an interesting place – sites such as spokeo.com and many, many others hook up to Facebook, LinkedIn, Yellow Pages, personal blogs, etc and aggregate all of one’s personal info.  You can look up a person by name, drill down by state and city, and find out a great deal of information.  This includes stuff like family size and wealth, type of residence, and even street location.

On the one hand, this kind of information is exactly what one would need to steal one’s identity, short of an SSN.  On the other, the places from which this information is gleaned if often required to be public.  Consider:

• Facebook still defaults far too many things as public, meaning that one’s personal info on the largest social networking site is right there, in the open.
• LinkedIn, by nature, needs to have a detailed public profile in order for professionals to find each other.
• The Yellow Pages is a critical component of running a business effectively, which means you are putting your information as owner out in the open.

Monterey College of Law Pilots iPad Programs for Students and Faculty — Campus Technology.

A professor here at the Law School forwarded this to me recently.  He didn’t say anything in his message.  He just sent the link.  I guess I would have appreciated an attempt at something other than saying “I want an iPad too” but I’ve learned to manage my expectations these days.

There are a few interesting aspects to this post, some more meaningful than others.

• It is tied to BARBRI, the Bar Exam prep program.  Programmatic backing is always a critical component to any initiative.  If there is no clear purpose, tied into a practical activity in which the end-users are interested, then it’s likely to be dead in the water.  So that’s good.
• The main point cited for providing iPads is because students learn and faculty…do scholarship outside of the classroom.  Well, they have done that outside of the classroom for quite some time now.  On the student side, I can see where a new interface to this content can be meaningful.  That is good.  But faculty clearly aren’t teaching via the iPad (at least, not likely).  They are not likely creating content via the iPad (possible, but if you’ve met law faculty you’d know from where my skepticism comes).  And the iPad is not the device for doing scholarship.  That’s not so good.

Interesting idea.  Poor reasons cited in the article for the effort.  Sounds like more hype than content.

FYI:  I struggled with the title of this post for days.  No matter what I did, I felt like I was writing something a 14-year-old would do and laugh about.  Very sad.

I often start my work-related posts with a qualification that I fully realize the difficulties that face university Central IT.  I make my comments about technology in higher ed and my opinions about the best ways to implement such technology and policies purely as my own opinion, but also with respect to the hard work of my university colleagues.  My opinions might be contrary to not only the university’s actions but even to their policy (or maybe even to their way of thinking), but that doesn’t mean I don’t respect their efforts or the challenges that they face.

I’m taking this one step further – the university has been under tremendous fire for communication, governance, and policy issues with its “IS” department.  IS is made up of Central IT, Media Services (classrooms, media support, etc), and the library.  In reality, the problems and complaints have been mostly about Central IT, with a bit of bleed-over to Media Services.  Most importantly, this has come from all sides – the faculty, the staff, departments as a whole, an external committee, and even the national accreditation group used by the university.  This is a big deal, and my perception is that IT is under a lot of pressure right now.

Interestingly, a university faculty member wrote the entire staff mailing list (why just anyone is allowed to write to the list is a whole different discussion, though perhaps related to the fundamental message of this post) praising a presentation by three managers in IT at a symposium.  These three – one of them the director of IT – spoke of the difficulty of providing an enterprise level service at a university, the challenges that any large IT infrastructure presents, and the type of staff power (both quantity and quality) needed to provide services that many people take for granted.

The real issue, however, isn’t whether IT at a university (or anywhere, really) is hard.  It is.  Nor is it just that our IT department has provided sub-optimal services at times.  It has.  These are very black and white perspectives that ignore some fundamental, cultural issues.  And difficulty in provision is never, ever, an excuse for low quality of product.

For instance – the difficulty of setting up and maintaining a university infrastructure is unimpeachable.  But the methods through which one builds such a system, and the policies that govern the development and growth of such an environment, must be examined closely.  To simply say that “it’s hard – acknowledge that and we can all move on”  is a gross oversimplification, and an insult to those that try to provide high quality service in such a “difficult” environment.  The complaints expressed by many during the external committee’s “Open Forum” session were often far too vitriolic and ignored the effort needed to provide the services we had.  The e-mail sent to the staff, in turn, ignores that just because something is difficult doesn’t excuse those responsible from mistakes along the way or for not remedying those issues since their emergence.

For instance – from my outside perspective, I have no idea whether the topic of outsourcing of services – cloud, third party, whatever you want to call it – has been discussed properly.  I do not have any clue as to whether the General Counsel has put forth our official stance on having sensitive data on someone else’s servers.  I am fairly certain that a stringent review of our business processes, our personnel, and an evaluation of what we actually need so that we can find the best solution has not been conducted.  I am pretty sure that we’ll go to Google Apps for Education just because that’s what everyone else is doing.  But that’s still probably 20% guessing and another 20% educated conjecture.

Not even all the right people are included in the conversation.  Why am I not better informed of what is happening?  No, I’m not a vice president or provost at the university – I’m not even part of the central university.  But I am the head of technology (CIO, whatever) for the law school.  We are the only other 100% full tech shop on campus (everything but e-mail, ERP, and networking).  Why am I not at the table?  Why have my requests (yes, I have been proactive) to be included on whatever committees come up been met with silence?  I am at the point of leaving vague messages about “however I can help” and “just say the word” in an effort to be informed.  Whatever process they do have in place does not include looking for outside opinions, as far as I can tell, empirically.

This is just one example, but the fundamental issue is that there is a procedural gap, flaw, fault, undersea trench that no one seems to see whilst they are viewing only the extremes.  Doing IT at a university is hard.  But that means that it’s all the more important to be as smart, as considerate and thoughtful as possible.  That all options must be weighed and that things are done the right way.