Examining the ongoing challenges of delivering high-quality, value-added ERP services in Higher Education.
Monday, February 28, 2011
About a year ago I sat with a colleague at the local watering hole. We started talking about the pros and cons for a certain technology solution. A three-letter acronym – by now I forget which one, so let’s call it ABC – was involved. He argued the merits of ABC and I spoke of obstacles. He suggested resolutions and I countered with more emphatic concerns. Eventually we agreed to disagree. As I lifted my pint glass, I realized something was wrong.
“When you say ABC,” I said, “what, exactly, do you mean?”
Turns out we were talking about two entirely different solutions, which fortunately explained some of the more confusing points in our exchange!
Lately, I have been studying the
Information Technology Infrastructure Library (ITIL), in anticipation of applying its standards to the segment of my group focused on access management for the Harvard ERP systems. The framework is by-and-large common sense – things that many of us learned through doing, but not always with a shared nomenclature. But it is positively riddled with acronyms. A sampling of this morning’s alphabet soup: CMDB, CMS, SKMS, CI, and PIR. In only 30 minutes of Element K training! To pass the certification, I see flashcards in my future…
In part, the problem stems from the lack of an International Institute for Acronym Definition (there’s one for everything else, why not this?) However, it also reflects a broader challenge we information technology professionals face almost daily: simple phrases co-opted by corporations (and often subsequently trademarked!), divergent stakeholder interpretations that take on lives of their own, and the frequent omission contextual detail. For information technology, sometimes the context is not even enough – we recycle and reuse phrases even within the same sub-disciplines of our world.
Consider “CMS” – a repeat offender in the acronym-ubiquity-and-ambiguity category. A quick
search on Wikipedia yields a full page of disambiguation options, including TWELVE in the “computing” sub-category (not one of them ITIL’s configuration management system).
I am not suggesting we abandon acronyms; it would be terribly unwieldy to repeat fully qualified names time and again. So what can we do? Legends in every document? An IT-acronym registration service?
Here’s a funny link I found while making sure such a body didn’t already exist:
International Association for Important Unnecessary Acronyms
Wednesday, February 2, 2011
Every IT professional has a trove of war stories about challenging customers or end users. These “problem” users are not of a homogeneous sort—I can think of a half-dozen classifications off the top of my head. But today I have one particular breed in mind: the user possessing too much knowledge of an application. He might have been an implementer in a past life. He might even have been part of the project team that established the system. Sure, there is a sub-species of this user whose knowledge is dated—tied to an ages-ago release that has long since changed. But we are concerned here with the other sub-species, the user whose knowledge is current; he might even have an active user account on one of the pre-production environments. He is a most dangerous creature.
“Our old boss was like that,” one of my product managers told me. “We had to take her access away.”
For our implementation of Hyperion Planning, I have become “that user.”
The deployment project ended in November 2010, but this is my first year using the system to model my own departmental revenue and expenses. It has been hard, for all the reasons that budget-building and performance-monitoring are challenging activities. But old habits die hard—and I can’t help but generate lists of potential solutions. “Couldn’t we do X?” I ask. “Check out the nifty form I configured on DEV… When can I get it on PROD?”
I try to stop myself. I preface every email or call with a heart-felt admission that I know better. In the end I am my own worst enemy; I helped write the change management rules, to make sure that enhancements are treated with due rigor: formally defined and prioritized, tuned for extensibility and performance, integrated into communications and education plans. One-off solutions are dangerous—I know this and have preached it to hundreds of clients through the years.
But I can’t stop pushing.
Thank goodness my product manager holds the line. “This is great feedback,” he says. “I’ll include these for discussion at the next working group.” I can accept that.