Your content model isn’t finished
One lesson that I share repeatedly in talks and in Model Thinking is that teams working with a content management system (CMS) need to expect that their content model will evolve.
But when one of the early steps of a CMS project is finalizing the content model, we reinforce the idea that the model is immutable. And, the reality is that many teams are funded as project teams, and many organizations lack institutional support for evolving the content model.
Viewing the model as unchangeable and failing to fund ongoing content modeling work is a recipe for the failure of a CMS implementation. We can’t easily address the resourcing constraints, but we can learn how to more effectively manage a changing content model.
A source of truth
First, I think it’s helpful to identify what is the source of truth for your content model. You need all partners and stakeholders in your CMS implementation to agree on the source of truth. Is it what’s deployed to your production instance of the CMS? Is it some other sort of artifact?
The path of least resistance is to say that the production instance is the source of truth for the content model, but that’s a non-decision decision that ends up short-sighted. You might end up having discussions about improper fields that go like this:
“Hey, I think we need to change the fields in this content type because XYZ.”
“Yeah well, we can’t really do that.”
“Why not? This is causing problems for our editors and the wrong information is getting published to our website.”
“Because that’s what’s in the model.”
And even if you don’t have that kind of discussion, you still lack a good mechanism for evolving the content model while it’s in active use. You need to document your content model. I usually call this documentation the content model specification.
Why you should document the content model
Content management projects involve a lot of people and moving pieces. Institutional knowledge is great, but it’s fleeting, so you want to have something that everyone can turn to as a resource about the content model.
Reasons to document the content model include:
- To have a clear source of truth: Even a small CMS implementation has content stakeholders and engineering stakeholders who will benefit from documentation about the content model. Larger implementations have many, many more people who might need the documentation.
- To guide future evolution of the content model: You can build the guidelines for changing the content model directly into its documentation.
- For handoffs and collaboration between stakeholders: Whether it’s a brand-new CMS build or changes to the existing, a variety of disciplines need to review and give feedback on the content model. A draft specification is a great place to contain the comments and discussion in a way that you can’t get any other way.
- For continuity in case of turnover: Maybe your documentation is for the longer term when you—or other members of the project team—have moved on. The documentation is a sign of respect for the future.