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.