Monthly Archive: June 2015

startups and higher ed IT

When we bought our house 4 years ago, we invested in some improvements. One was to lease a solar panels for our roof, from a quasi-startup that worked specifically in cities with sizable solar rebates.. At the time, the notion of leasing panels rather than buying and installing outright was pretty controversial. You didn’t own them, you didn’t get the rebate, and you are dependent on another company for maintenance, etc. The way I saw it, at the time, was that since I didn’t have $30,000 lying around for an install, not getting the rebate was moot. We would get a significant energy savings, so it seemed like a win-win. One of those situations where a solution that is sub-optimal to many was actually pretty okay for us.

I’ve had to revisit this decision recently, and it occurred to me that it’s not unlike the times I’ve worked with startups while here at Menlo. At face value, it seems really dangerous to work with a company that has 10 employees and is a year old. These companies can go through ups and downs. The obvious one is going out of business, but there can be severe changes in direction due to market forces, abrupt adjustments to planned features quarter by quarter, and a seeming rotating pool of sales folks (if they have a sales force at all). Ironically, the one consistent thing has been negotiating pricing – these companies want to get into the higher education market, so they are usually willing to talk until we find something mutually beneficial not only now but also for at least a few years down the road. I can’t exactly adopt something now at an affordable price then pay ten times that amount in year two.

At the same time, all institutions should be looking to take advantage of new technologies and solutions and especially here in Silicon Valley there are many options around if one has an open mind. We can do some really interesting things with security, management, and monitoring based just on some recent agreements that we’ve made. And not so long ago, when I was still at Santa Clara Law School, I was working with “start ups” like Box, which is definitely a lot more than a fledgling company now.

There are many reasons to pursue partnerships with startups. One of course is that we’re a small college, and they are flexible on terms because they want to get into our market. These are companies that are hungry and of course must create compelling solutions to problems. They are there to be a David to the existing Goliath, and to aim that sling-shot with great accuracy. We have come upon some truly stunning products from these companies that have greatly enhanced our abilities. Of course we have been careful in the solutions we’ve pursued. We need to consider the benefit from multiple angles (will this provide not only superior results and features, but also at a reduced management load?) and of course the risks. Sometimes we have to look at what stage of venture capital funding they are at and the valuation established by investors along with the technology itself.

In the end, though,what has mattered is having the open mind to consider such solutions and the organizational ability to take advantage of them. We must be open to the idea that, perhaps because of certain aspects unique to Menlo College, taking a calculated risk makes sense. Just as how leasing those panels, at that time, made sense for us in our particular situation. While we missed out on $10,000 in rebates, we never could have gotten them anyway, and we’re still getting an energy savings every month that far exceeds the lease payment we have to make. In the case of start-ups at Menlo, we may not get the benefits of working with a larger company with its substantial infrastructure, but we get at times a better (or better-fitting) solution with fewer strings attached.  Even if a company goes in a different direction with some tool we’ve adopted, as long as we’ve gotten what we need out of it and haven’t entangled our operations with the solution such that it’s a chore to undo, it’s probably been worth it. And we’ve shown again that we as an organization are agile enough to take a calculated risk here and there. In many ways I value that agility that we’ve developed and the mindset that propels it more than anything else.

In the long run, this agility plays out in more traditional ways. Some new next-generation security option comes up, and we’re able to act on it faster than one might expect. There might be a new technology that is actually quite hard to master, but because we have placed an emphasis on the ability to adapt and learn, we can go through that adoption process sooner than others and perhaps get ahead of the curve. We’ll make our mistakes, but perhaps we can rebound from those, too, without as much pain because we’re accustomed to such changes from taken risks. Or perhaps we’re just going through a “normal” infrastructure refresh that involves servers, storage, and our virtualization layer. Perhaps we’re able to handle that kind of stress better, too. No matter what, agility and a mindset that appreciates that flexibility is invaluable.

I’m not saying that I’m going to be reaching out to start-ups and taking risks – calculated or otherwise – at Muhlenberg. But I do hope we can achieve the kind of agility that we’ve found here at Menlo. And if we are able to buck a trend here and there and do something new and impressive, then that certainly wouldn’t hurt.

thinking about frameworks and “best practices…”

As I prepare for my move to Muhlenberg College as their CIO, I have been doing a great deal of thinking about adapting to new situations. I have been keeping a completely open mind about Muhlenberg and the Office of IT themselves – I must learn the environment and culture and absolutely cannot make any judgments before arriving. But I have been thinking a lot about how transitions go in general. I’ve been reading the books, talking to mentors, and just tossing around ideas. I have allocated much time to considering the myriad of ways to handle a transition, both personally and to those with whom you interact. And a big part of a transition is what set of values will drive the organization.

One way to develop values that has come up quite a bit surrounds using “best practices” and various frameworks for managing IT organizations. I speak specifically about ITIL and Lean IT. The former is a non-prescriptive approach to managing organizations of almost any kind, with discussions about defining a service vs. a process, how to catalog and therefore understand those items, and determining “owners” for the sake of accountability and communication (massive oversimplification of a powerful set of tools). When applies specifically to the world of IT, the acronym ITSM is commonly used – IT Service Management. So the processes become the Help Desk, and the service might be repairing a printer or building a new wireless network. Owners become specifically the Help Desk Managers or the Networking Administrators, for example.

Lean also comes from outside IT – its origins are with manufacturing. Pioneered by Toyota, the idea is to eliminate wasteful, non-value-adding processes and utilizing “demand management” to create a pull-based flow of procedures and practices. The end user pulls in pursuit of valuable service, which better defines what resources and methods are truly needed to deliver that value. Whereas Toyota was talking about helping eliminate waste in their car manufacturing plants, Lean IT isn’t really that different. The wasteful process might be handling password resets, and demand management might be a lot different (I could read a thousand books and I’d still have no clue how to manage the demands of faculty to create the same kind of “pull”), but the ideas are the same. Identify processes that don’t add value to the end user and eliminate them, find a way to look at the end of the “value stream” and build your operations to fill those values, rather than deliver products because that’s just what comes out the other end.

This post started out as a discussion about the role of ITIL and Lean in higher education, about the pros and cons of going about them in different ways. However, as I wrote, I realized something more fundamental was afoot.

Both frameworks talk about “value.” In ITIL, it’s all based on whether your process or service provides value in the eye of the customer. In Lean, you work hard to get rid of non-value adding work. While I personally define value broadly, it is easy to start thinking of “value” as “flashy and new.” Investing in value means enhancements that gain attention. Value comes from high profile services. Also, there is a trap of thinking that something that is a relative commodity, such as a Help Desk, where services can be documented and are repeatable, is by definition not actively adding value to an organization. They should, therefore, be eliminated or at least receive less investment.

The problem with this viewpoint is that it presumes that value is either mutually exclusive from or trumps importance. A reliable Help Desk is critically important to the organization, and provides a service that is extremely and fundamentally valuable to the larger institution. Yes, procedures can be boiled  down to documented, repeatable models. In fact, at a Help Desk in particular services should be commoditized as much as possible, such that virtually everything is based on a prescribed set of steps that lead to consistently repeatable results. One should make the Help Desk as “dull and reliable” as possible, as compared to “flashy and new.” But sometimes commodities are dull, yet they add a ton of value. I do not think anyone would claim that a Help Desk does not add to the overall value of an IT organization to the institution. A lot of investment should in fact be made into documenting and commoditizing those services. This investment can take the form of new knowledge base systems, ticketing protocols, and even staff. Bottom line – something that is easily codified isn’t necessarily unimportant nor non-value adding. It is very possible for such services to be incredibly valuable because they are so important.