How can I manage my content effectively?
I'm lined up to give a talk at the Boston Consultants Network in March. The title of the talk is Help your clients manage digital content (they won't do it on their own). Many of the people who hear the presentation are consulting engineers. Typically they have a lot of documents - digital content - to manage as part of the projects they undertake.
So I thought I'd start thinking about this subject ahead of time, via some short posts. The first thing to say is that the parenthetical part of the title conveys a little humor, but it's not demonstrably true. People manage digital content the best they can. Often they have to do it on their own, since no one will do it for them. Moreover, companies, teams, project managers, and technical types generally run the full range in the care they take with doc management. You cannot say with facile assurance, people won't do it on their own.
Having said that, the full range of care is notable for the large number of digital content management systems that are below average. The goal for such systems is simply stated: create and deliver correct information, to the person who needs it, at the required place and time. If your content creation processes fail, it does not matter how well your delivery channels function. If your delivery channels fail, it does not matter how well your content creation processes function. You have to couple the two parts together tightly.
That's a general introduction. Now let's have a look at some of the practical questions you want to ask when you undertake a new project. Sometimes the tools and processes you use are in-house, and they do not change from project to project. More frequently, you must adapt your work methods to accommodate your client's established processes. Here are three questions that arise right away:
- What tools will I use to create content?
- What tools will I use to manage content?
- What content management processes are in place?
- What file formats are in play?
I've stated these questions as simply as I can, but you can see that for large companies, the way content management works can become complicated pretty quickly. Even for a small project team, proper content management can become troublesome if people do not think about the problem.
Let's take the second question as an illustration. Then let's narrow that question down to the problem of version control. Later, I'd like to compare the way software developers handle source control with the way document developers handle version control. They are not the same thing, though they both involve similar techniques and goals. For now, we'll consider the question that comes up at the beginning of a project: What tools will I use to manage content?
If you are the only person who will ever handle the document, the answer to that question is easy. We all have a file structure on our local drives, file naming conventions, and more or less rational routines to make sure we don't lose data. Losing data is the great bugaboo of modern office life. We build our processes so it does not happen, because we have difficulty doing our jobs when it does happen.
As soon as you create a document for other people, you have to think about basic document management questions. Simple questions, such as where will the date appear, must be taken up. Does the document need a version number? Whether or not a number is assigned, how is versioning of the document handled? If applicable, at what point in a document's development is a version number assigned? Lastly, how do answers to these questions about dates and version numbers affect file naming conventions?
You want to glance at a document in a data storage system, whether it's on your local drive or on a server, and determine immediately whether it's the document you want. If you murmur in objection, "When I start a project, I don't want to think about file names right off the bat," think about what happens when you don't. Requirements of modern data retrieval systems force you to have methods that work. Recall that business firms in the 1930s hired armies of clerks whose only job was to maintain the company's data retrieval system - that is, paper documents stored in filing cabinets. The need for proper control of digital content is far greater now, when you can't touch the documents, and content multiplies stupendously.
Content management systems
I've managed to write nearly the entire post without talking about the tools we use for version control. They vary a lot, and none is perfect. Some content management systems, such as Microsoft's SharePoint or Drupal, are designed from the start as document control software. Others, such as CVS (Concurrent Versioning System), are designed to handle source code in particular, but companies may use them for document control as well. Subversion, Perforce, and Team Foundation Server work reasonably well for code and content. Lastly, some companies use home grown content management systems. Watch out for these! These tools are hard to update.
Doc managers, of course, feel most comfortable in an environment tailored for all kinds of document and image formats. Workflows for document control are not exactly the same as those for source code. If you are a software developer, you may not react negatively to a source control tool that emphasizes computer code over document files. All in all, if you have a lot of documents to manage, you want a content management system designed for content, whether the content is stored in tool-specific project files, .doc files, .pdf files, .html files, .xml files, or all the image file formats you can think of. You especially want a content management system - or version control system - that adapts well to all the processes in place to create, publish, and revise your content.
Note that when we talk about content management systems, or version controlsystems, we usually think first about the tools we use for these purposes. That's natural enough. SharePoint as a web application is properly called a content management system. More broadly, though, you probably want to think about content management as a set of procedures or processes, where the tools in place determine some but not all of what's required to manage documents effectively.
Once again, toolsets, version control systems, or large content management systems cannot determine all of what's required to meet the goals of document control. Tool vendors may claim that their product or service will solve all of your content management problems for you, but in fact you still have to give some independent thought to these problems. Practical solutions to create and deliver content, when and where it's needed, cannot come from an application. The toolset has to work for the company and its project teams, not the other way around. If you are not careful, you can become so absorbed in making the tools work that your team's creative energy dissipates.
Document control and companies
What does that mean for consultants? First is to be conscious of how many tools for content management exist. Second is to remember that companies generally don't give as much thought to content management problems as they do to, say, sales or customer support. That is true even though effective document management is integral to superior customer support. Third is to know that you can adapt your work methods to accommodate your client's processes for document control. Your client will not change its document control processes to accommodate you. Nevertheless, you may sometimes be struck by how broken and ineffective the processes in place can be.
In the end, document control places demands on companies they are not well equipped to meet. Business accounting practices have had several centuries to evolve. Companies rely on these practices to track and fund global operations. Procedures for document management in the digital age have had only a few decades to evolve. Many see content management as an extension of writing. In some ways it is, but in several important ways document control requires other skills. Large companies commonly overlook the need for these skills in their organizations.
Some companies have developed more effective practices than others. Almost all companies recognize that problems of document control are not as easy as they may have looked at first. You cannot merely assign a document number to a file, store the file in your database, and retrieve it down the line if you need to have another look at it. If you leave it at that, you end with a largely static pile of outdated files, rather than a flexible management system. Companies know that if their document control systems do not take change into account - if they are not streamlined and adaptable - they just slow the company up and demoralize its people. Those outcomes make companies ill equipped to match their competitors' success.