A few days ago I was exchanging e-mail with one of my son’s teachers to make sure the young prince had completed all of his assignments when one of my replies bounced. According to the headers it appeared the Ventura Unified School District’s mail server had suddenly decided to disallow my message because it figured it would require unauthorized relaying. Very strange — e-mail working one minute but not the next.
I tried sending a message to my friend Ted Malos, who runs the VUSD IT department, and that also bounced, so I called and left a message.
Some hours later he returned my call and explained what happened. Turns out the school’s domain name had expired and, because the e-mail account that had been used when the school registered the name was no longer monitored, the renewal notification had gone unnoticed. He immediately renewed the domain for the next eight years and by time he returned my call everything was back to normal.
Now Malos has a new problem: How to ensure that when the registration runs out in eight years someone will be able to field the renewal request. The chances of Malos being there in eight years are good but not certain, and the same applies to all of his IT staff.
This tale is a small scale example of what is actually a big hairy issue — the problem of institutional memory. Institutional memory is concerned with storing and retrieving information about the organization that is needed for it to function properly over both the short and long term.
While this is a recognized issue (there’s even a Wikipedia entry for institutional memory) and there’s a fair amount of advice and commentary on the topic, almost everything concerns institutional memory as it relates to “high touch” information — the information that organizations use frequently. Most of the fixes involve things like groupware and CRM systems to capture and retain data, events and business processes, along with a few mentions of corporate historical record keeping.
But how do we deal with “rare touch” information? For example, information about infrastructure decisions that were made a decade or more ago when there’s no one left who has a clue about what was done? How do we stay organized over time?
The solution is a special repository. It needs to have its own e-mail address and it needs to be the focus of all top-level system messages and documentation, as it needs to be able to route management messages to a wide spectrum of internal staff such that it can’t be forgotten about. And it needs to have a calendar service so critical event notifications can be scheduled and sent out.
You’ll also need a virtual user that is understood by everyone to be a permanent fixture and from whom they hear frequently — perhaps admin@yourdomain.com. This address should archive all incoming messages and make them searchable, as well as forward all incoming messages to multiple users, add events and alerts to calendars. It should also be referenced so thoroughly in your network’s design that it can’t be overlooked.
But even with a system like this and people paying attention to it, there’s the added problem of whether recipients will understand the messages and do something about them. Again, in-depth, unavoidable documentation is the answer and maybe the way to make the repository’s existence durable is to build it into the legal articles of the enterprise, perhaps as a board level responsibility.
So, what kinds of institutional memory does your organization have? Will it work over the span of years or decades? If you think it will, how?
At least when it comes to my son’s school and e-mail, I know Malos has got us covered for at least eight more years, by which time I sincerely hope my son will be in college.
Gibbs remembers everything in Ventura, Calif. Recall your thoughts to backspin@gibbs.com.