kaiyen: pepper

Monthly Archive: December 2011

not reinventing the beeping noise

  • 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.

December 19, 2011 Higher Education IT, Work-related 0 Read more >

do more with more, more efficiently, in the same amount of time

I loathe the phrase “do more with less.”  I abhor it.  I loathe and abhor very, very few things in life, and I reserve those venomous verbs for rare occasions.  Yet I both loathe and abhor the phrase and the idea behind the notion of “doing more with less” as a management tool or concept.

The idea that any organization – whether it be an entire institution, a school, a department, or even a single project team – should be expected to provide, say, 125% output with less than 100% resources is utterly absurd.  When this is used during times of economic crisis – which is what we’re looking at right now in higher education – the philosophy can be something of a necessary evil.  When budgets are tight then almost any project will have less than 100% of funding.  When hiring freezes occur then existing staff are spread more thinly across projects.  Resources – both dollars and staff – must be at less than 100% in such a situation.  And at least for the short-term the same set of services must persist.  There simply isn’t enough time to retool an entire department, help desk, or other operation in the face of a sudden budget crunch.  Dollars per capita (DPC) goes down because it has to, at least for now.

But this cannot become standard, ongoing policy.  Service portfolios must be reviewed, staff must be rearranged, and overall operations must be reorganized to accommodate the new monetary restrictions.  Only those services that can be offered at the same, pre-crunch level should remain, and overall DPC should be restored.  This has to happen, or everything and everyone suffers.

So “more with less” cannot work as a long-term response to budgetary constraints.

As a general inspirational philosophy, however, it can have some kind of meaning.  “More” and “less” are relative terms.  Provided that there is not the expectation that we somehow work 125% time (in the perhaps utopian world where everyone works to capacity and capability, no one can work more than 100% of what he or she is capable), doing “more” simply means to provide some additional quality with the work we do.  For me, I use value to customer as the yardstick.  How much value are we offering to our students/staff/faculty (or some subset – residential students?  just the financial aid office?) with our services?  How can we provide “more” value by doing X instead of Y?  Or perhaps by doing a new version of X?

Similarly, “less” just means using a lower quantity of available resources.  It does not and should not mean that there are fewer resources, in an absolute sense, with which to provide the same value.  Just in a relative sense.  In other words, using “less” is all about efficiency.  How can we provide value in a manner that consume less time, less dollars, or both?

Ideally, how can we provide more value, more efficiently than we are doing now?

Taking the value concept further, it is quite possible that there are extremely high value products and/or services that are actually extremely costly in terms of resources.  In a perfect world we offer huge value at a low cost – a major streamlining of workflows for a specific office using open source software that is easy to install and maintain.  But if the value boost is high enough – providing a toolkit that makes Santa Clara Law students “twice” as useful to law firms than students from other schools – then cost becomes less of an issue.  Maybe that toolkit involves building multiple web-based software tools and purchasing, installing, and maintaining a very expensive piece of software that provides practical training.  Maybe it’s worth it.  Maybe not.  But it is a possibility one should consider.  The “more” value part should be the first consideration, with the “less” resources – efficiency – part coming next.  Hopefully if we offer this huge value, high cost solution, at least whatever resources we are expending are the absolute lowest amount required because we are very efficient.

Now – my preferred way of approaching this concept, the only way in which I am truly comfortable espousing anything along the lines of “more” and “less” is to:

“provide more value with more resources, using less resources and being more efficient, all within the same or less amount of time.”

Now, that’s awfully long-winded, but that’s also the history major in me.  It is, however, important that all of these points be included.

Provide more value:  covered above, but again the key thing is that we first want to provide value.  If the customers don’t get the value then we shouldn’t offer it.

With more resources: if I’m asking you to find a way to provide more value, then I’m going to give you a bigger pool of resources – staff and money – to help shape things.  To help form the project at the outset.  Start with loose reins, then bring them in when you are underway and need control.

Using less resources and being more efficient: Of course, it is not acceptable long-term to add services to our portfolio that consume resources disproportionate to the value being provided.  At the least, when pilot leads to production, the service should be streamlined and using fewer resources than all other alternatives.

All within the same or less amount of time: This is key.  We all work 100%.  For most people, that means 40 hours per week.  So what I want is for my staff to do all of this, develop new projects that provide more value, etc, all still within those 40 hours per week.

Of course, if you’re being efficient, then what is really happening is that whereas you provided X amount of value during those 40 hours, you are now providing, say, 1.5X or even 2X in the same amount of time.  The entire department is better at providing more value, and over time we do more with more while using less.

December 13, 2011 IT Leadership, Work-related 0 Read more >

low on resources – what to do?

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…)

December 9, 2011 Higher Education IT, Work-related 0 Read more >

just big enough to falter

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.

Santa Clara University needs an enterprise-level e-mail system.  It also has users in its community that need connectivity via a variety of mobile devices, smart phones, etc.  SCU is big enough to need both of these services.  But the dollars devoted per user (in this case those that need mobile device access to the e-mail and calendaring system) is not nearly enough to provide an effective solution, even when two different groups are working on the same problem.
The question, therefore, is whether there is any “hope” in such a situation.  Whether a school such as this is destined to slide further and further down the hole of decreasing resources in the face of increasing demands, or whether something can be done about it.
This post has gone long enough in setting the stage and asking the questions, I hope.  Next comes some ideas on what to do next.

December 6, 2011 Higher Education IT 0 Read more >