Week 8 - Content Management Goals and Consistency

After meeting with Dakota, everyone was excited about the new content management system again. Dakota had given us a well-written and well-priced proposal as well as a direction for how we should approach bringing our content into the system and conducting the knowledge transfer.

Since we were stalled with Flatirons (see prev. post) we decided to take advantage of our time and move ahead with the advice Dakota had bestowed us. In doing so, a few of us sat down to really analyze our current documents and find how much of our literature was really reusable. By reusable, I mean a chuck of content from a particular suite of documents that appears over and over again on a continual basis. Thus far, we had never really created a library of such content and that's what we had planned on doing today.

The problem that we ran into, that I am sure any company would run into, is consistency. Consistency is a critical in ensuring that the new content system would operate smoothly. Our first issue with consistency was figuring out what topics were reusable in what kind of deliverables. Further, we asked if we would always assume that said content be used with a particular deliverable?

The second issue with consistency came in how we were to save the topics or chucks of information; in other words, what would the actual file name be versus what was to be included in the metadata. Having a naming convention is critical because that's how future users of the content management system will search the repository (the place where the all the content lives).

Again we found ourselves in a relatively heated debate. Should we name the files with a series of numbers or actually describe what the content within that particular topic is? Would legal wording in one type of deliverable make its way into a second type of deliverable? How extensive should a reusable topic remain, if parsing it may make it more reusable? Would we always have to take out parts of a topic that were not needed for certain deliverables? These types of questions and many more permeated the meeting and left us confused as to how we were going to approach this entire situation.

Then one writer suggested something a little unorthodox. He said that we first should start playing around with the system, adding in a large chunk of test content to see how it works in real time (for example, during a scheduled due date), and see how individuals intrinsically search for content (whether that be text or image files). After which, we might be able to decipher the naming convention. When the meeting ended, things were still up in the air, but it seemed that the only way to move ahead might just be as the writer suggested and dive right into it, putting the initial content in before a realistic due date.


Return to HOME page or leave comment below.

Week 7 - Content Management and Knowledge Transfer

So, ladies and gentlemen, today was an very interesting day in the world of content management. We had a serious sit-down with some knowledge transfer competitors by the name of Dakota Systems. They basically prepared a nice proposal, reasonably priced, that reflects their knowledge transfer services. What is knowledge transfer you ask? Simple, it's when one entity teaches another entity how to do stuff in an efficient and effective manner (and people versus instruction manuals are needed to transfer the knowledge because most of the knowledge is tacit, or ingrained in the minds of the experts, hardly ever extracted into the written word).

More specifically, in the field of content management, knowledge transfer equates to a team that teaches others how to use a CMS system, how to push the system to its boundaries, how to evaluate technical issues effectively, how to use the system in the most efficient way, how to ensure that the system remains expandable (so that, in the future, content can be built up, figures or diagrams can be easily altered, etc.). This knowledge transfer team also offers coding training in case the system actually needs to be reprogrammed for any reason. Lastly, and maybe most importantly, the knowledge transfer team should define and shape the process by which the actual content moves from the old suite of deliverables and documents into the new content management system.

Piece of cake right? No. That's why it's imperative to use a knowledge transfer team that knows what the hell they're talking about. And in our meeting today we had some individuals who did not hesitate to answer the tough questions. They seemed to already know the system (even though they did not build it) inside and out. They also easily grasped our current process and illuminated the direction in which we now need to head. And we haven't even hired these guys yet.


Return to HOME page or leave comment below.

Week 12 - Migration and Legacy Content

Today we had a basic refresher on the benefits of Content Management via a presentation given by Vasont (this was done to keep CMS as a viable option given these rough economic conditions). The first and most important beneft would obviously be ROI. But Return on Investment can only first be calculated if it's possible to figure out what the cost to implement the system is in the first place. In figuring that cost out, one must examine a major aspect of implementing the CMS: Migration. Migration is the process by which the current doucmentation will "get" into the new content management system.
We can begin (and finish) discussing migration with the topic of Legacy Content. Legacy Content is content that was created before the content management system is implemented, but content that will be around after the CMS system is launched. It's content created with the idea that it will be converted into ACII text or a .cvs file in the future.

This conversion can happen in one of two ways: legacy content can be converted via a modular-source or book-source method. With modular source, you can mannually convert the legacy content across all documents, increasing conversion costs and time spent as each piece of content is converted as a stand-alone or peice meal effort. The benefit to this would be a granualr and micro examination of the content before being embedded into the CMS. On the other hand, book-sourced conversion, breaks down text by topics and headings and maximizes reuse. It is autmoated and does not require reauthoring; this method is of course cheaper and less time consuming.

Once a method is decided upon, or if both methods are used, the next thing one should look at are the best practices of Migration. The best practices comprise 5 activities:

• Understanding the requirements of the system
• Understanding the requirements of your legacy content
• Test/Pilot conversion
• Flexing the system; getting to know it's boundaries
• Producing; loading the system with the leagacy content.
  

Now, I could go into more depth on each of these 5 points, but they are fairly self-explanatory, except for point #2. In other words, understanding your document requirements involves deciphering how each tag is handled, determining what are explicit versus implicit topics, and deciding which tags belong where. These items might best be firgured out during either of the two legacy content conversion methods.