For the Children

imageLast Tuesday, in a post on my AIIM blog, I described my effort to begin crafting an Information Policy that will apply to one of our most recent SharePoint solutions. Eventually, I hope to have a collection of these policies bundled into a comprehensive information policy for our company. That may not happen in the 5 to 7 years that remain before I retire, but I’ve heard that it’s good to have goals. This first attempt was presented to the department earlier this week and the draft was well received, even after I explained that most of the work that remains will fall to them. We moved onto the other agenda items, but we kept coming back to the information policy, and I began to realize just how important this document is going to be. The point where this became most clear was well into the meeting when one person asked

“…how is this [SharePoint site] really any different than the K: drive?

It’s not the first time we’ve been asked this question in the years that we have been trying to move our content from shared folders to SharePoint, but this was perhaps the easiest it has ever been to answer that question.

“It’s different because we can answer three questions for every document on this site that we can’t usually answer for content on the K: drive:

1) Why did we create this document?

2) Who was involved in its creation and disposition?

3) Why did we keep it?”

The inability to answer those three questions is why most of the content on the K: drive will end up staying there. Once the shared drives become read-only; it will take a lot of effort to explore the content and answer those questions. That task will get even harder when the people who were here as those documents were created retire. The loss of tacit knowledge has already begun to affect our ability to classify older documents, without reading them and without a little guess work, and it’s only going to get worse.

One of the tasks that this group has to accomplish is to move a lot of historic content into the site we created for them. This effort will be guided by the information policy, and the experience will help them refine the policy. A good example of how this will work came as we demonstrated Boost Solutions’ Classifier product for them. I’ve written about this product before, but in a nutshell, it lets you quickly tag and process a lot of content that has similar qualities. We stumbled upon two documents that looked like good candidates, a draft contract from a vendor and a list of changes that our staff had proposed. Before we could process these, the head of the department asserted that “we should not keep these, because, in this case we only care about the final contract” which we also had. This led to a short discussion of the kinds of documents where we want to keep drafts and review commentary and the kinds of documents where we don’t. This distinction mapped well to the library structure we had created and there was a placeholder section in the draft information policy for that kind of management decision to be documented.

Other elements of the policy are equally important for helping future employees answer those three questions. For example, there is a section titled Definitions. In the draft of that section, I included the words, library names and metadata elements that need to be clearly defined. Two library names that I included were Internal Communication and External Communication – why do we need to define these? Well, maybe we could live with one definition, but are we talking about external to the company or external to this function? Another definition was a word we have all seen too many times in business, “stakeholders” – when does someone we do business with become a stakeholder? That’s important because it’s a metadata term used in a lot of places, and if stakeholders are involved, the apparent importance of the document increases.

In our board meetings at the New England Chapter of AIIM, we often describe a documentation task as being necessary “for the children.” In other words, we are taking the time to document something that we figured out, but that future board members shouldn’t have to. That’s the difference between managed content and a bunch of files in a shared folder. That’s why you create information policies and that’s why you pay attention to the definitions, guidelines and clear instructions that people include in that very important document. Of course, the policies can change, so when they do, the document should be revised.

Personalized to the Point of Failure

imageIn 1997 I wrote a bit of code that has finally come back to haunt me. The idea was sound, the implementation was flawed but I didn’t know it at the time. I wanted a way to include some rudimentary (by today’s standards) personalization into our desktop systems. I crafted a Parent Class that contained a System Setup utility and a startup routine to access and apply preferences. I stored things like the fonts and font sizes, the position and size of the main window and certain basic application parameters. This was at a time when most Windows applications contained UI elements that didn’t even scale when you stretched the window, so I was quite happy with the outcome. My mistake? – following Microsoft’s advice to abandon the trusted .ini file in favor of storing this stuff in the Registry. I wrote a Registry interface before a good commercial class library was available for Smalltalk, and that bit of code has reached its breaking point.

It seems that errors with personalization are moving like ripples on a lake, because while I am rewriting a 15-yr old process, we are facing the other side of the personalization dilemma, when to say “no.” We’ve been asked to reduce the detail in a dashboard view in SharePoint. Saying “no” isn’t something I enjoy, but we do have to know where to draw the line between a personal view and the minimal amount of information a user should receive. This is a tricky endeavor. I used to work for a man who viewed the world as a series of binary equations. Status to him was “done or not done?” He would prefer a dashboard with a simple red/green indicator (no yellow required), but that isn’t always what people need to see. “Not done” inevitably leads to questions, and good dashboards should answer the most common questions as well as report the status. This is especially true in SharePoint, where finding those answers may not be easy. Our dashboard highlights reports that are nearly overdue as well as reports that are actually overdue. Seeing that 7 reports are approaching their delivery deadline will absolutely cause you to ask “which reports?” but finding them takes a bit of sleuth work. So, if someone asks me to remove the actionable list of those reports from the dashboard, I hesitate; I want to talk to them and walk them through the scenario(s) that might unfold and test their resolve on that request.

Another oddball request we received this week was actually a multi-part mind numbing exercise. We have a list of contacts, which are organized into three categories. To avoid adding enough detail to identify the suspects, I’ll just call them Type A, B and C contacts. We had to produce a series of reports that include A’s and occasionally B’s but never C’s. That was pretty easy. Now we have a request to include a single B-type contact on a report that doesn’t contain B’s. In addition, we need to include a contact that is neither an A, nor a B nor a C on a report that only includes A’s.

These are the kind of problems that make you question your design effort, not to mention your chosen profession, but a bad design wasn’t the cause of our problem. The root cause in this case is the nature of this list – contacts are people and people aren’t as easy to manage and categorize as things. Rather than try to manage our way through this issue, we opted for a few technical tweaks that provide the necessary capabilities while stopping short of hard-coding individual reports.

I hope that you can see from my opening story that I am a fan of personalization; however, I do think there are practical limits that should be considered:

1 – There should not be an ability to eliminate information that is widely considered to be essential to the understanding of the content.

2 – Personalization should not require arduous coding. This is another way of saying that personalization should be intuitive and available to all visitors to a site. When we start trying to make micro-adjustments to accommodate specific individuals, it’s time to push back.

3 – Personalization should not interfere with knowledge transfer. This might be a special case of the first item in the list, but it’s worth considering separately. When we look at what information is essential to the viewer, we have to consider what an experienced user does with that information as opposed to what the new guy might do with it. It’s fair to say that not all people know what information they might need under certain situations.

Hope Is Not a Method

Last Tuesday, our Chairman opened our Annual Meeting with a speech that, among other things, talked about the challenges ahead of our organization. Knowledge Transfer is one of those challenges. Then, he talked about the tools we are using to meet these challenges; Enterprise Content Management (ECM) is in that list. Those of you familiar with this blog know about my experience with our ECM effort. Those of you familiar with ECM know how important management support is to an ECM project, so you understand how happy I was to hear ECM being mentioned in the Chairman’s speech.

After the business meeting, Admiral James Ellis, CEO of the Institute of Nuclear Power Operations (INPO), delivered an amazing keynote address. His presentation had been uploaded to our Internet-facing SharePoint site earlier and I noticed that the title began with “Hope is Not a Method” then trailed off after a few letters. I found the partial message intriguing and I asked him for permission to use it. He said he didn’t mind, because it wasn’t his message. Ironically, listening to his speech, I think it was part of his message. As Admiral Ellis described INPO, its history, operational characteristics, mission and its vision, it became clear that INPO’s success was not a series of random events. Their success is the result of skill, analysis, careful planning and systematic effort according to that plan – no hope involved. His was a speech that reinforces the notion that if you have the knowledge, are prepared to work and, if you work, you will succeed.
I love hearing stories like that. Success stories are the single best tool we have to muster support for SharePoint and ECM. I’ve written here before about how I publicize our success stories within our organization – nothing sells SharePoint like the successful use of SharePoint. Everything else we say is marketing hype; we might be slightly more credible than Microsoft, but it’s still “picture yourself doing this” and “wouldn’t you like to solve this problem?” – with all the credibility of EPA estimated gas mileage. If that’s your approach to marketing SharePoint or ECM within your organization, you are currently hoping for success.
I’m not sure who typed the message that accompanied Admiral Ellis’ presentation. I’m not even sure that the title string was the complete message. One thing I do know for sure, I like that message – hope is not a method of any process, if the goal is success.

Picture note: Our Annual Meeting was in Ft. Lauderdale, FL. it was nice to be able to take a picture that didn’t include snow and ice so I just had to use it here.