The CMS Workflow Myth
(Originally posted to the Confab Events Blog: The CMS Workflow Myth. I will be speaking at Confab Higher Ed in Atlanta in November)
Why do we call it workflow when it generally prevents work from flowing?
If there were a Rube Goldberg prize for “significant complexity in an imaginary system,” it would often go to workflow design. “Does the system support multi-stage complex workflows,” an RFP might ask, “including multiple configurable decision models, automated notifications, task pooling, conditional branching, and granular tracking of changes and comments?”
I can hear the complexity (and potential cost) mounting. How many times can a piece of content go through workflow loops (from draft to submitted to reviewed to revised to reviewed to revised to published)? Can editors or administrators with greater privileges skip over multiple stages? Can the workflow be different in each language/for each section/for each content type? Will the system notify administrators whenever content has remained in a specific state over a predetermined amount of time?
That Way Madness Lies: The Workflow Myth
We sometimes hope that workflow will magically solve all of our content problems. This myth of workflow is based in three core ideas:
- Content is an important asset produced by the organization.
- Those who must validate the content before publication are higher on the org chart than the authors themselves.
- The best way to reliably ensure content governance happens is to have the CMS platform enforce workflow (typically through roles, responsibilities, and a series of states content must pass through).
The first two aren’t problematic on their own (though the second does beg the question, “If the content is such an important asset, why aren’t people further up the org chart more involved in its creation?”).
It’s the third premise that gets us into trouble. It translates complex governance and process issues—where business rules or editorial guidance gets applied, how we ensure we’re producing consistent high-quality content—into features to be engineered into a system.
I can’t tell you how many times I’ve watched content editors logging in and out of the system with different user names to “push” a content item through workflow—having been given approver’s passwords long ago in frustration over the effort of getting through workflow. Often the “real” workflow happens via Word docs sent back and forth via email. Then a useless, choreographed, and convoluted workflow occurs to satisfy the system.*
What to do when you are asked to design a workflow
1. Recognize that content governance ≠ workflow
Don’t let the content strategy questions of where content comes from, how it is created/shaped/edited, and when it should be published/unpublished, get turned into questions of workflow features. CMS-driven workflow is one potential avenue for implementation of content governance, but it is not the only option and not necessarily the most appropriate.
2. Start simple and lightweight. Only add complexity as it proves necessary.
It’s clear that multiple internal users may need to see content. The need for anything beyond a preview/draft state and a published state should be demonstrated, not assumed.
Think of workflow as a feature that can always be made more complex based on real need. But just as you shouldn’t start renovating a house you just moved into (because you don’t yet know what it is like to live in it), don’t start imposing complicated workflows at launch of a new site. Wait until you have some real experience with how content flows through the system before imposing gates and loops.
3. Involve actual authors and approvers in content governance.
Workflow, in most CMS platforms, is a fairly technical effort to implement. It requires some understanding of content states, roles and permissions and how they get assigned to users, and what triggers are available within the system. But that doesn’t mean workflow should be designed by the engineering team. Real users who will produce content and real approvers responsible for the ongoing production of content should drive the process. Make the system match what works for the humans, not the other way around.
Breaking the Workflow Myth
If scaling back your workflow model sounds scary, consider the success of Google Docs as a platform for content collaboration. Yes, some basic controls are provided—who can only read, who can comment, who can edit—but otherwise it’s basically a free-for-all. There’s no complex multi-stage approval, no real notion of draft, submitted, final. And many content teams find it far more useful than a complex, multi-stage, system-enforced workflow.
Next time you’re asked to design a workflow, remember the workflow myth. Instead of aiming for complexity, imagine the simplest possible working model—one that actually enables the work to flow. Demonstrate success with that simple model (with real content, real contributors, and real approvers), and then build upon that success with the gradual introduction of more complex options.
*Footnote: Of course there are regulated industries in which it is critical that the system record a specific approval by a specific user of a specific version of a content item. These folks need the traceability and CYA that workflow can provide. But let’s not pretend every site needs the same level of content traceability, or that this is more important than time spent focused on producing content that is actually useful, usable, and persuasive for our audiences.