You Want Collaboration, Not Workflow

Content management isn’t unique this in regard, but the CMS sales cycle is a process of people asking for things they’re never going to use. You smile and play along because they’ve put a lot of work into that RFP, but, honestly, at least 50% of the functionality they swear they need is nothing that’s ever going to get implemented. Call me a cynic.

This is never more true than with workflow. I’ll say this: workflow is the most over-purchased feature of content management, hands-down (I’ve said this before, in fact).

Seemingly every project has grand plans around workflow. Editors are going to submit content to an approver, then it’s going to an editorial committee of which 60% need to sign off, then it’s going to a metadata specialist, then the legal department, and then it will be published when the temperature in Moscow hits 60 degrees and the Oakland Raiders win the Superbowl, etc.

None of this ever happens (especially the part about the Raiders and the Superbowl…)

In my experience, 95% of “workflows” are simple serial chain approvals, and 95% of those are one step. Someone can edit and submit, then someone else comes to review then publish. It’s barely even “workflow,” but that’s fine because it works and it’s what most clients really need.

I wasn’t a huge fan of Ektron as a CMS, but as noted in the link above, they did workflow well as what they simply called “Approval Chains.” They didn’t even try to pretend that workflow was anything more than a chain of approvers, stacked however many levels deep.

Episerver has a slightly less powerful model in that you can give Editor A “Edit” rights but not “Publish” rights. This means that Editor A can simply designate content as “Ready to Publish,” and Editor B (who has “Publish” rights) has to come along and publish it. Same thing, really – a simple approval chain, but only one level deep.

Over the years, I’ve come to understand, that when a client says they need “workflow,” what they’re most likely talking about is “collaboration.” They don’t want approvals so much as they want to be able to communicate with other editors about content and make sure content looks good before it goes out the door.

So, the functionality people really want is:

1. To collaboratively discuss content.

2. To prevent bad content from being published.

I’ve always thought that a CMS would be well-served by letting you “turn the page over and write on the back.” You know how Wikipedia has "talk” pages where people can have a meta-discussion about the actual content of the page (example)? Same thing. The average content editor just wants a space where they can call a time-out and discuss the content that’s being produced. Additionally, some of these discussions might need to be resolved before the content can be published.

Take a look at this wireframe.

We scoped this for a client on Episerver, but sadly it never got approved. However, I still think the idea has merit. The major functional points are as follows:

1. Any editor can open a discussion about any piece of content. They can “turn over the page” and engage other editors and users in conversation about that content in the form of a simple discussion forum.

2. The discussion can be “scoped” to a specific piece of content (e.g. – the privacy policy, for example), or to an entire section of content (e.g. – the About Us).

3. Topics are tied to specific versions – so every thread is version-stamped, so you know what the current version of content was when the thread was opened.

4. Topics can “block” publication. When a thread is opened, an editor can check a box that says “this version of content cannot be published until I remove this block.” An administrator could override, but the idea is that a single editor can block the content edit until it’s modified to their satisfaction or someone talks them off a ledge and they voluntarily unblock it.

(Note: there’s something else in the wireframe about requesting approvals, but it’s been 19 months and I can’t really remember what I was doing there.)

I maintain this is really what 95% of people want when they say “workflow.” I have no doubt that “true” workflow scenarios still exist – there are legal, regulatory, and audit scenarios that require historical trails to be present. But these situations are further apart then we care to admit because we’re too busy showing off our shiny workflow solutions in a demo. Many prospects ask for these just because they’ve seen them in examples.

Give editors a competent solution for collaboration, and I’m quite sure that many requirements for workflow will simply evaporate.