You Want Collaboration, Not Workflow

By on June 1, 2014

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.

###

What This Links To

Comments

  1. Frank van Puffelen says:

    Hmmm... where is Google Wave when you (finally) need it?

    I wonder how difficult it would be to simply stuff something like Mozilla's TogetherJS into the average CMS: https://togetherjs.com/ .

  2. Amen to all that!

    I posted an article a long time ago titled "workflow is the wrong metaphor":

    http://www.steptwo.com.au/papers/cmb_noworkflow/index.html

    Instead, I argued that people were looking for task management. And by that, I meant "Bob, could you have a look at the second para of this?", exactly as you outline in this post :-)

    (This is why I say it's one of the "widely known secrets of the content management industry: workflow doesn't work".)

    Cheers, James

  3. Carrie says:

    First, I'd argue that it's a "good" content editor that wants to discuss content being produced, not average (at least in my experience). At most companies, I would guess that people designated as editors are merely putter-uppers of content. Given a 1-level workflow as you describe, that's probably the case more often than not.

    I'm giving Gather Content (https://gathercontent.com/) a try for this exact purpose - to have the ability to "turn the page over" or make comments about content and push through an approval process. Mind you, the content will still need to be copied into the CMS, but at least it will get the care and attention good content needs. If this functionality could be combined with a CMS, it would be gold! But, Gather Content does have a way to export to some CMSs, if you happen to be using those.

    We expect a lot of our CMS, probably more than we should. It's not magic. It's technology that supports other functions. If more people demanded this type of collaboration in their CMS, would more systems think about including it?

  4. Kevin Potts says:

    Deane -- My experience largely mimics yours in that 95% of approval workflow is a single step.

    Philosophically, I don't really agree with fostering collaboration inside a content management system. To me, and this really is just my perspective, a traditional web-oriented CMS (Ektron, Wordpress, etc) should house production-ready content and nothing else. Drafts, sketches, notes, comments introduce clutter and distractions, and weigh down a tool that should be optimized for the final content as well as associated metadata.

    However, this an ideological perspective. Even the purest CMS is going to have clutter and drafts and unpublished content. What I wish I had was a three-stage system with pieces adequately segregated:

    1. Collaborative authoring and approval. Messy, stores all the noise.
    2. Final content for publishing. Stores only the final goodness.
    3. Archival and retention policies. Places content in deep freeze, or sets deletion policies to support legal requirements.

    Kind of thinking out loud a bit.

Add a Comment