I spent my late teens and early 20’s as a student in an undergraduate and graduate experimental psychology program. There were two main research paths in the program, one of them behavioral and the other cognitive. Regardless of which path a student chose, they would spend an enormous amount of time reading peer-reviewed experimental psychology literature. Many of these studies are considered “classics” in the world of experimental psychology in that they tested and confirmed critical hypotheses about human behavior, influence, and cognitive processing.
At the same time that I did this, I began my career in IT. My first IT job was when I was 17 immediately following high school. I worked in a large mainframe data center operating several IBM 3800 printers from 11 PM to 7 AM, five nights per week. Sometimes we printed payroll checks! I moved up through the IT ranks in such data center environments.
As I began my IT career, one thing that always struck me as odd and confusing about the field was how there was often very little rhyme or reason to the design of the interfaces we used to work with and manage the various systems. It would seem that when accessing a system, whether it was some mainframe application, a pc-based tool, or any of the various other systems and network management tools that we used, myriad and unrelated choices were presented, usually in no clear logical fashion.
Technology changed dramatically since then, but our ability to logically group things seems to have increased at a snail’s pace.
Fast-forward to the last ten years with the huge rise in popularity for service management in many organizations and IT in general. Usually, when an organization develops an interest in service management and ITIL, building a service catalog is soon to follow.
In most cases I witnessed, the first few iterations rarely achieve their desired goals. In some cases, the service catalogs never deliver on their promised benefits. I have a theory as to why this is the case. In every situation that I witnessed (and some that I’ve heard about from colleagues) when an organization initially pursues creating a service catalog, they almost always see it as an exercise in how many services can they think of to cram into the catalog with little regard for what services the business actually needs.
This violates an important aspect of service catalogs. Service catalogs are intended to establish boundaries that specify the details of the services that an organization provides to its customers. They should be easy to use and should not create extra work or confusion for the business. If an organization sets an ineffective boundary, and tries to be everything to everybody, they usually end up doing everything poorly. This shows up in many organizations as the business completely ignores the service catalog that IT worked so hard on and spent so much money to build.
Now, back to where I began this post. When in school, one of my favorite experimental psychology studies was titled The Magical Number 7, Plus or Minus 2: Some Limits on Our Capacity for Processing Information. This study was conducted in the 1950’s and is considered a classic in the world of experimental psychology. It concluded the following:
“First, the span of absolute judgment and the span of immediate memory impose severe limitations on the amount of information that we are able to receive, process, and remember. By organizing the stimulus input simultaneously into several dimensions and successively into a sequence or chunks, we manage to break (or at least stretch) this informational bottleneck.”
Retrieved from: http://cogprints.org/730/1/miller.html on 9/9/2011
I suspect this one statement explains why many service catalogs fail to achieve their intended goals. By putting too much information in one place, without any appropriate or logical groups, the tendency is to overload people’s capacity to process information. Generally we are good at handling information in “chunks” of between five to nine discrete items.
It’s the political aspect of service catalog projects that contributes to their failure. As humans, we seem to associate more with better. Additionally, in many organizations it’s not uncommon that every part of the organization wants to ensure that they’re represented in the service catalog, as these are typically highly visible and important projects. Because of this, we often see service catalogs with hundreds of services and very little recognition of the commonality between the services.
Although ITIL doesn’t specifically call on the Miller study, interestingly enough it’s possible to find evidence of this study in the best practice. One of my favorite diagrams in the strategy book, ITIL 2011 – Service Strategy, Figure 3.28 (below) describes what are called “service archetypes”.
Guess, what? There are only nine service archetypes, which fits the seven plus or minus two rule. We can process nine things without overloading ourselves, but once we surpass that, we start to degrade our mental processing power. Our working memory simply doesn’t work well as its capacity limits are reached.
There’s nothing about IT that requires it to be confusing or overwhelming. In fact, ITIL gives us the tools to control some of this confusion by establishing clear boundaries. By establishing those boundaries following ITIL’s guidelines and coupling this with a healthy dose of proven research, organizations will likely experience greater ROI from their service catalog initiatives.
ITIL® is a Registered Trade Mark and a Registered Community Trade Mark of the Cabinet Office and is registered in the U.S. Patent and Trademark Office.
The image used in this blog post is taken from ITIL Service Strategy: 2011 Edition, Figure 3.28, p. 90 © Crown copyright 2011, reproduced under license from the Cabinet Office. Some of the graphics, tables, and text have been reproduced, or adapted from, the official ITIL publications, published under license from the Cabinet Office.