Going – Going –

clip_image002They’re not gone yet, but by the middle of 2013, our network shared folders become read-only. That was the message delivered a few days ago to a group representing every functioning department that hasn’t already moved their content onto SharePoint. Tough love? No, reality. Let me be clear about my motives, I am not advocating SharePoint, I’m advocating the value of information. Shared network folders have been considered to be among the best things I ever suggested since I first mapped a directory on our NetWare server to K: in 1988. However, not only are they less capable than SharePoint, shared folders have become dysfunctional. They are hard to navigate unless particularly well organized (most are not). Also, because searching and sorting are done on the client, they are pathetically slow for remote workers. So I find myself having to put an end to the era I started 25 years ago.

Sometimes, in order to move forward, you have to make it impossible to move backward or even to stay in the same place. I didn’t invent this concept, I read about others doing it, and I held it in reserve hoping that education and cooperation would suffice. They won’t. I realize that something I wrote about a long time ago, something I learned as an undergraduate in chemistry (of all things) is at work – activation energy. Chemical reactions have an activation energy which if not established, will not proceed. Information management has the same requirement. As long as people have the ability to keep tossing stuff onto the K: drive, they will continue to do just that. The incentives and promises of easy access, findability, sharing, remote and / or mobile connections will only inspire a limited few people to embrace ECM. For the people who create more content than they consume, manage the content others create, or primarily consume the content stored in their own silo, ECM offers little benefit. For them, ECM is “the stuff I have to do to make someone else’s job easier” and oftentimes, the “someone else” is a future employee. Once again, I find myself facing the unenviable task of changing behavior.

I wrote about that task very early on this blog, and I mentioned that my boss had advised me that changing behavior wasn’t like driving a speedboat; it was more like driving an aircraft carrier. He told me to get comfortable with only being able to turn one or two degrees at a time. That was great advice, but when it comes to changing the way people work with content, sometimes I feel like I’m driving Africa, like I am moving at the speed of the tectonic plates. The problem that I face is that if I don’t start making 2-3° changes soon and 5-7° changes in the not too distant future, some of the ships in my carrier task group are going to run aground. Still, there are two important nuances contained in the opening sentence above. One is the fact that we are targeting mid-year. The second fact is that we are not eliminating the K: drive.

Mid-year is an important target both for my team and the people we support. From my team’s point of view, we know that if it doesn’t happen by the end of June, it won’t happen. We will be delayed by vacations and then we will roll into the 4th quarter “busy season” and it will be year-end and 2014 and then we will be starting over. For the people in those operating departments, mid-year means that they have 4-5 months to figure out what they are going to do. During that time, we can help them define the sites and libraries that they need, establish basic metadata and get the process underway.

Making the K: drive read-only has numerous benefits. Nothing will be lost, nothing has to be moved right now and we don’t have to solve every problem before the end of June. Before the end of June, we have to have a place for all the stuff we are likely to create in July and August. We have to have a plan for moving the most important files from the K: drive into SharePoint, and we have to convince people that some of the files on the K: drive are garbage. That’s why we aren’t simply moving the entire contents of K: into SharePoint! Read-only means if they need a file, they can get it, but if they need to edit it, they have to figure out where it belongs and they have to set the basic metadata. If nothing else, everything we create after 6/30/2013 will be easier to work with. That sounds like a workable plan that offers enough benefit for now. Stay tuned, I’ll report on our progress.

Information Management 101

clip_image002When AIIM decided to increase their emphasis on people, and spread their net beyond Content Managers to attract Information Professionals, I was thrilled. It may be minor semantics, but ‘information’ is easy to understand and ‘content’ – well content makes me think of ingredients. Ingredients are sometimes managed, like when a factory produces bread, or shampoo or beer, but ingredients are just as likely to be thrown together when you and your 6-year-old bake a pretty good cake. Ingredients sound like the stuff hidden in the fine print. Information sounds important, it sounds vetted and validated and downright useful. I decided to launch a series of training sessions around the concepts of information management because we are involved in a wide variety of systems development projects right now, and many more lie ahead.

The first training session was short, in fact I finished 5 minutes ahead of my 45 minute goal, but that may have been the only thing that the audience enjoyed. The message was simple but not entirely appreciated. That we are all ‘information professionals’ sounds flattering, but pointing out what constitutes ‘professional behavior’ isn’t so appealing. One of the slides that wasn’t accepted well at all was the one titled “What’s Not a System”. From the thousands of things that aren’t systems, I chose four that cause the most problems for me:

Templates – Word, PowerPoint and even SharePoint all make great use of templates, but the idea that building a solution from a template is enough to insure consistency, reliability and usefulness is folly. Templates are like the recipes that guide our use of ingredients. We can change templates, ignore portions, delete portions or put the wrong things in the wrong place. Saying “I used the template” isn’t really the equivalent of saying “I followed the rules” – It’s more like saying “I had the rulebook open at the time.

Spreadsheets – I like to think about spreadsheets the way I think about sports cars. In the hands of the right people, they are both fantastic. If the people are unskilled, unwilling to follow the rules of the road, on the wrong road or trying to do the wrong thing, the end result will not be pretty. You can move furniture in a sports car, but… Spreadsheets are good at so many things, but pretending to be an automated system isn’t one of them. Spreadsheets are fragile, hard to debug, hard to document, way too easy to copy (and then confuse the copies), and way too easy to be made to look official. Even worse than when people try to use spreadsheets as a data processing system, is when they try to use them as a content management system. The simple row-column interface of a spreadsheet encourages people to store, track and categorize stuff the way the top left kitchen drawer attracts gadgets. When you go back and try to sort and filter your list though, you realize that ‘Cars’ are not ‘Automobiles’ are not ‘Chevys’ are not ‘Vehicles’ and so on and so on.

Folders – My target here wasn’t just the myriad file folders on the remaining share drives in use on our network. I also took aim at the SharePoint libraries that were created, from some of those file folders. Folders and unmanaged libraries are not systems, and they provide minimal (at best) support for managing information. Yes, folders do help us to organize information, but they can’t enforce rules, they can be moved, renamed, and they can hold so many things that don’t belong in them that they are the top left kitchen drawer. Folders are a good starting point, if you have better places to put the things that are in them and if you are willing to throw some things away.

People – Actually, in a failed attempt to be cute, I said “You” are not a system. I went on to explain that people are pretty unreliable when it comes to managing information. People make the rules, but they also forget the rules they make. People take short-cuts through the processes they define, ignore the procedures or convince themselves that rules and procedures were meant to apply to “other” people. The most dangerous thing about people is that they think, and when they think, they convince themselves that changes should be made and then they make them. Systems can change, but only when the changes are confirmed to be appropriate by everyone who will be affected and then only under the control of the same process by which the systems were built. I wish people wanted to manage information the way some want to play football, then I could try something like this.

Can I Trust Explorer View

imageNothing sends a chill up your spine quite like saying something in public and then finding out that you were wrong. Well, there is one other thing, doing something, or telling other people to do something that you’re just not sure you should do. A strange sequence of events on this blog has me dealing with so many chills; I’m reaching for my Steeler hoodie. Last April, I wrote an article about using Document Sets where I talked about the features I liked. In one of the comments I received, a person asked how to create a folder inside a document set. I don’t usually dabble in the art of “how to” on this blog, but I thought I’d research that one a bit. I thought I found the answer, and I replied that as long as the parent library supports folders, you would be able to create folders in a document set – wrong!

A few days ago, somebody replied to the person who asked the original question, stating simply that “folder cannot be added to document set.” Seeing that comment caused chill #1, but it also inspired a bit of investigation. I was pretty sure I gave my original answer based on something I read, mainly because it was a statement of fact that I didn’t have the knowledge to support (I don’t usually make those). I couldn’t find anything to support my earlier conclusion, so I decided to see if I could find a solution that would work. By work, I mean “is there a way to add a folder to a document set?” The answer is yes, and the title has telegraphed the method. While you cannot get your document library to offer you the option to “create a new folder”, you can create a new folder in the parent library; open the library in explorer view and drag the folder into a document set. You can drag document sets into other documents sets and, if you like living on the edge, you can drag document sets containing folders into the folders you previously dragged into a document set. You can see in the image that ‘New Folder’ is disabled but my document set includes a folder and another document set. I’m not sure why I would ever want to create these organizational elements inside themselves, but suffice it to say, it can be done. That brings me to chill #2 – should I offer this as a solution to someone? I poked around and I found others who have offered explorer view as an option, but I’m stopping short of saying that here.

I am a firm believer in the adage “just because we can do something doesn’t mean we should do it” and that second chill is because part of me thinks there’s a reason Microsoft didn’t include this feature. The option to create folders in a document set is missing due to an oversight, or perhaps they never considered anyone would want to do that, or perhaps there is something about document sets that makes having folders in them a bad idea. In the library I used for testing, it would be a bad idea, because the document sets have workflows attached to them. If a workflow ran on a nested document set, it would generate a task for a person who would rightly feel lost and confused when they found themselves inside a document library that doesn’t contain the set they were working on. I realize that my situation is unique, but if I were suggesting explorer view as a way of creating folders in document sets, I would have to qualify my advice.

I’m also getting a chill from what I consider the worm-hole nature of explorer view. Explore view provides us with an unfiltered opening into otherwise cloistered containers. In the TV series Star Trek Next Generation (STNG) worm holes were featured in several episodes. A “stable” wormhole between the Alpha and Gamma quadrants spawned a seven-year spin-off Deep Space Nine. In a different episode, “The Price” two people are lost for decades in the Delta quadrant because a worm hole they were exploring was only stable on one end – you could always enter at point A, but you might emerge at point B, or C, or Z on any given day. Using explorer view to nest folders and document sets inside document sets makes me feel like I’m traversing an unstable worm hole. I have users who might like to put folders in document sets, but before I offer this solution, I am going to conduct a little more research. I am going to start with asking them “why?” It seems to me that I’m more likely to find a disconnect between the user’s goals and the intended nature of this library than I am to find a valid request.