On return from TCUK10 my mind was seething with enthusiasm and ideas about Content Strategy. I have been quite the giant nerd at friends and colleagues, some of whom have displayed more than polite interest.
However, twice now I’ve been asked to explain what specifically I mean by Content Strategy. On both occasions the explanation has gone down reasonably well, but I am still slightly concerned I might be getting it wrong.
So what better way to invite a storm of correction and disagreement than to post my explanation on the internet?
Content Strategy, as I understand it, is the application of strategic thinking to the way content is created, distributed, stored, used and maintained in a given environment. This could be a website, an intranet, a department, or even an entire business.
In practical terms, what does this actually mean?
I want to describe a scenario that doesn’t actually have anything to do with the Web, but in which content is (or at least should) be generated in considerable volume: project-based software development. This scenario is essentially a composite of several examples I have come across during my career, and therefore shouldn’t be attributed to any one business.
Software development lifecycles often generate a great deal of content: proposals, authorisation documents, business cases, requirements, specifications, meeting minutes, release notes… maybe even the occasional user guide.
In our scenario, when a project is initiated a new shared folder containing the templates for all the types of documents that might form part of a project is created. All the members of the project team are supposed to use these templates to create documents, and should store all the resulting versions in this shared folder.
As I type, I can almost feel my fellow Technical Communicators wincing.
The reality, as I’m sure we all know, is that this simply won’t work. Documents will be stored elsewhere and passed around on email. There is no way to know whether the documents on the folder are the most recent versions. In some cases there will actually be no content in one or more of these templates, either because the actual version is sitting in someone’s hard drive or inbox, or because it was never needed in the first place but no record was taken of this.
Clearly, a huge amount of vital information could be falling through the gaps here. How therefore can anyone, present or future, trust the content that exists to be valid and complete?
So what to do?
Simply installing a Document Management System (DMS) will be insufficient. Without thought given to how such a system should be used, it runs the risk of being used as if it were a shared folder. I have seen this. It is not pretty.
In my opinion, the following needs to happen, with each stage logically informing the next:
Content audit – A full audit of the content on the DMS, and on a selection of key projects. The aim is discover content that is invalid, incomplete, out of date, or even completely missing.
Process discovery – There is bound to be a gap between the theory and practice of project processes. The content audit should already have given some idea of where these gaps fall, but interviewing the people who work on projects on a day-to-day basis will give an even clearer picture. To date, I have never found a project that has followed a mandated methodology to the letter.
Process and Template improvement – With a better understanding of the processes, the existing templates can be either improved or completely replaced with new templates aligned with how people actually do their day-to-day job.
Technology assessment – Notice how this has come so late on. I am a strong believer in not just throwing money at technology to solve problems. If a DMS is to be deployed, time must be spent to understand how its functionality can be used to help project teams discover, capture, collaborate and publish content.
The next steps are not necessarily in this strict order, and will in fact probably form part of a continuous improvement initiative:
- Revise existing content on the DMS in accordance with the audit.
- Document and publish processes.
- Run a pilot project or three using the DMS and new templates.
- Continually monitor and gather information on other possible improvements in process and technology.
So, within the bounds of this scenario, this sounds like Content Strategy to me. How about you?