Aint Got No (SDL Tridion) Workflow... Blues?

Chris Summers asks and suggests reasons why organizations don't implement SDL Tridion workflow. He's absolutely correct, but I think this extends beyond Tridion into the very nature of knowledge work, situational leadership, and mature business processes.

1. "[Tridion] Workflow is one of the least explored areas".

It may or may not be widely implemented, but we've seen frameworks and webinars (thanks, Mihai) on it.

Though I'm in the yet-to-program-a-workflow (as of 3/21/12), I wouldn't hesitate to document a process, though nor give my not-quite-solicited opinion.

Like most Tridion questions, we start with "how do you/would you do this outside of Tridion?"
I have the philosophy that if you can explicitly describe the steps you want in terms of actions you can do with the CME along with a basic understanding of programming, you can capture enough requirements to build an appropriate workflow, event system, or extension... more or less, with caveats on how long or challenging it would be to build. :-)  
2. Few organizations understand their business processes



Yes, but that's often the nature of today's knowledge work. We're often employed to solve complex, hard-to-define problems without an easy-to-follow step-by-step process. The simple-to-define can be scary because it can be automated or outsourced (good bye job security). Seth Godin has an excellent description on the status and future of knowledge work in Linchpin, btw.
There are also so many "yeah buts" in this discovery. If you ever interview for processes in general, take your time to solicit the big picture. There's always a "yeah but" one-off or a hundred in terms of what action happens after another. I've also heard the joke that after implementing workflow, authors start asking "okay, so how do I skip it?" I like Chris's point that there's likely a simple solution amid the seemingly complex scenarios though.
Some non-managed Web or content processes follow something like (a previous boss/mentor/friend helped point this one out):
  • give IT updates (via email or request form)
  • (not necessarily intentionally) say "ok. ok." quickly until it's live
  • then really check afterwards since of course it's always priority to fix production.
It's not the author or requestor's fault in that cause, especially when they're asked to do their regular work and be a liason to IT, and a reviewer, and the penalty for slowing down the acceptance review is a slipped website deployment date and really late content updates.

Long story short, the above sometimes equates to the following workflow-free and fairly simple CMS requirement:
Let authors publish content and fix it if it's wrong.
3. Hard to differentiate between formal and informal processes


I've seen teams struggle with a quasi-precursor to workflow: source or revision control where only one person can edit something at a time. As an example, just basic source control with a Microsoft Publisher-managed intranet can cause regular requests for access and tickets asking for help with some locked content.


4. Content editors often work on batches of items

Also some requests come from multiple organizations with everything from content, to code, to design changes. Requestors can't possibly know what part belongs to whom, and each part may not have a strong understanding of the details of the related groups (which can be a good thing).

I do love the bundle idea and am interested in seeing the bootcamp session work and use cases that come out of it. I wonder if the challenge will be in soliciting community feedback or the opposite--keeping up with the amount of examples and articles people share?

5. "No out-of-the-box solution for notifying editors [of assigned items]"
We sometimes assume that if we had the right tool, that the reviewers would use it. Even if they knew how, the VPs, Senior Clinicials/Professionals/Other-Important-Reviewer may not have the time, VPN access, or interest in doing more than replying back "yes, perfect" or "wait wait, show it to so-and-so" via email.
This goes beyond WCM systems and touches proposal writing groups, documentation teams, or other informal processes. Sometimes complicated validation with multiple tools can easily be addressed by having one set of authors create and another publish.

The organizations with mature business processes likely already have existing sophisticated forms, third-party software, or understanding that email serves a useful role in confirming content changes, especially with participants with low readiness levels (a la Situational Leadership, a model that recognizes the VPs may want to review their own terms and not necessarily use a specific tool).
We don't read every tweet, marketing message, or even important notice from the bank. Even if Tridion made a SDL buddy jump out of your monitor, dance on your desk, and sing "hey you have content to review" you'd (eventually) go "yeah yeah" and look for the remind me in 15 minutes button or stick it in your desk drawer.

You got content.
Don't ignore me!
I think there's hope in treating the workflow interface as an application itself. Think about your favorite diff software (actually maybe not for busy or non-technical reviewers) or maybe the new SDL Tridion UI. Or flip the equation: only tell me if _____ happens or doesn't happen. Context matters! Provide a clear contextual call to action, maybe describing what changed with a personal message or approach to make it feel like a personal email from the author. A favorite technique from my favorite veteran (RFP) proposal writer</plug for Christy, my SO> is to use something like: "if we don't hear back from you by tomorrow at 5:00pm, we will assume you are okay with the document 'as is' and it will be sent to the client by the end of business on Friday."

Workflow may never be easy (how easy is it to describe what you do everyday?), but we can make it easier at least in the context of CMS.

Thanks to Chris for starting the question, and Dominic Cronin for replying and Chris again for prompting for feedback. Crickey, it's dueling Tridion Banjos (Dom's a harmonica though). Tag, you're next up. Pass on Chris's question (tweet link), otherwise a hundred SDL buddies will visit you in the next hundred days.


Actually, you'll kick yourself when everyone's all "done-that-been-there" with workflows and you missed a chance to share your story.


This content doesn't represent the views, opinions, or ... nevermind, read my footer. I'm not even sure I represent myself in this rambling-of-a-response-post. The SDL Buddy? Not mine either. It's a parody under fair use.

No comments:

Post a Comment

Feel free to share your thoughts below.

Some HTML allowed including links such as: <a href="link">link text</a>.