Lessons Learned from WFM

In a previous role, I helped work research, purchase, and implement a call center scheduling "Workforce Management" (WFM) solution. WFM is software that helps call centers schedule their agents based on historical data as well as monitor real-time adherence to the schedules. Like other software that brands itself "enterprise" it includes integration with other systems, key-performance indicator (KPI) reporting, and dashboards. The particular package from Verint systems included shift-bidding and ELearning features.

Playing the role of cross-functional (weak matrix) project manager on the client-side, we compared vendors, used Gartner research, did several demos, and completed procurement (including the paperwork trifecta of order form, master services agreement, and statement of work or SOW) over a few months.

Here are a few things that validated concepts I've learned from PMBOK, school, and personal experience with other software purchasing situations.

During research, it's important to focus on the business needs over technical benefits, but make sure the solution is supportable and approved by IT.

A vendor may present a list of deliverables (SOW), but keep your own milestones, schedule, and success criteria. Though supported externally, it's still your project so it must meet your own objectives.

Technical issues need to be addressed and prioritized with the business owners, technical team, and third-party vendors. Large issue affect multiple stakeholders differently. When in doubt, ask!

Managing expectations and getting the right (amount of) information to the right people is a large part of the project management and purchase evaluation process. I don't envy line managers in the amount of data they have to handle.

Try to separate the technical issues from project progress; but don't hesitate to hold your vendors ("sellers" in PMBOK parlance) accountable to project goals.

Above-all, a positive focus on how to make the project work has seemed to be more productive than keeping tally only to blame someone later. Definitely track issues, but approach them with the vendor and other parties cooperatively.

Whatever the service or software, it makes sense to focus on the mission and work with the other team while still holding your partner accountable.

Good luck with your next implementation!

Tridion BluePrinting Use Case

I prefer the acronym WCMS. Coming from a Web development and IT background in a healthcare-related company, "CMS" means something completely different.

Here's a use case for Blueprinting and localization for websites that need to be reviewed by external reviewers such as Centers for Medicare & Medicaid Services (CMS). I had a chance to run the scenario by Tory Johnson, a Tridion Professional Services consultant (who earlier identified better ways to use the Tridion 2011 Criteria Objects). He gave me the impression that my following setup might work (or at least confirmed I know a little bit about BluePrinting technology), but do see caveats below before trying this at home... er work.

But first some background and terminology.

Tridion BluePrinting

The Tridion BluePrint model allows developers, designers, and content owners the ability to create publications (collections of content, templates, and functionality) that share (think inheritance... sort of) content, style, or behavior. The BluePrint consists of parent and child publications where content is shared down from parent to child. BluePrinting may mean different things to technical audiences versus the business.

The Tridion localization feature is very important to BluePrinting.

Content Localization

Localization is a Tridion feature that lets you create a "one-off" version of an item, that is then shared down the BluePrint hierarchy. This item will have (almost*) the same Tridion content management identifier (tcmid), will be linked from the same components, but will no longer (automatically) share the same content from its parent publication. After localization, the item will keep its own history and can be updated independent of its parent item.

*The publication part of the 3-part ID will differ between the shared item's tcmid in different publications.

BluePrinting plus localization makes Tridion a strong fit for scenarios where you need to deliver content in multiple languages or targeted to different regions. But it's more than that, a well-designed BluePrint lets teams take the "component + component template = component presentation" concept all the way up to the publication level, where "Content Publication + Template Publication = Website Publication." Read on for an idea I worked on for a colleague (and yes, he gave me that "what?" look after we set it up).

Review Scenario

If you maintain a near-duplicate website for internal or external review, a simple solution is to simply publish content to the site. When it is approved, you can then publish this to the live site.

There's a problem, however, if you have a site that needs to be more than just website preview or user acceptance testing.

For Medicare (CMS) reviewed websites, there are restrictions on what content can be released. In this type of controlled scenario, only minor typos and select non-reviewed content are published to the Live site without CMS approval (from the technical side I'm not really sure what needs to be reviewed--the business side knows more, but this setup lets them pick-and-choose what and how things get updated).

Rather than having editors use versioning or edit history to control what gets published, a separate publication, higher in the blueprint can be used to separate the new yet-to-be-approved changes for the next iteration from the current live site.

Assuming a year-long iteration that begins in the New Year ("1/1 as a date is a hard deadline for many health or benefit-driven programs"), we start off with two publications:
  • Review Website Publication, which is a parent of...
  • Live Website Publication
In actuality we wouldn't use "Live" for the publication name since it might be confused with the live www. website or with the "Live" publication target (which publishes to the live www. website). Since the BluePrint is listed alphabetically, you might have names like "0035 MySuperMedicareProgram (CMS-Review)" and "040 MySuperMedicareProgram."

When the blueprint is first set up both sites are exactly the same. Review (this is not Preview) and Live have the same content shared down through the BluePrint.
  1. To create the CMS Review site, everything is set up the same as the Live site and all currently Live content is published.
  2. To make changes for approval for the next year, content owners determine the type of change:
  3. New

    Proposed content, new layout, and major changes can be made by first creating the proposed change (or localizing the Live Website version first if the items exist) and then publishing the changes. These new items shouldn't be published to the Live Website until approved and any localized items will keep their old approved versions unchanged regardless of how many revisions the Review Website goes through.

    Fix in Both

    A "must fix immediately" minor typo can be updated in the Review publication and published from Review and again in its child publication. If this typo fix applies to something that has been localized, content editors would update the Live Website localized item, then manually make the same correction to the Preview Website "proposed" item as needed.

    Year-End or Approved

    When CMS (Medicare) approves a change for the Review Website Publication, the content owners and their developers would:
    1. publish new items that don't have shared localized versions
    2. unlocalize items in the Live Website Publication, which will wipe out any localized edits and replace the items with their Medicare-approved versions
    3. publish the now-matching (unlocalized) components to Live and start over with both sites matching
    A content clean-up and a review of which items never received approval might also be helpful after the go-live date. :-)

    Issues and Caveats

    I helped set this BluePrint change in a production environment, but have not seen how it works in practical use (I've since changed teams a few times and haven't heard any issues--which strongly suggests it's not being used). The concept is sound, but I suspect there would be issues with the following.
    1. Training -- when should you localize (probably everything in the Live Site at the start of the year or iteration, but always before an edit)?
    2. Troubleshooting -- with content coming from two or more places, the ability to localize at different levels, and the fact that content owners sometimes forget to publish, I can imagine a few "hey, my page doesn't match my last change" type emails.
    3. Support -- a Tridion BluePrint really needs to match the needs of the content. Apparently some organizations want to set up a BluePrint to match an org chart (really?), which is friendly fodder for another blog post. Like any other powerful and flexible technology, BluePrinting shouldn't be underestimated and it isn't something typical business analysts, programmers, or other support roles would understand right away. It's not quite inheritance, nor do the terms "share" and "localize" do it justice.
    Watch out for confusion or misunderstandings around:
    • Preview vs Review
    • Tridion Publication versus Website
    • The word "Publish" (component? page? .NET site?), but this isn't unique to BluePrinting!
      Terminology (feel free to point out any inconsistencies above)
    If you have internal content owners publishing content for Review's Preview before it gets published to Preview's Live for CMS review of the WCMS-enabled content before it ever goes out to Live's Preview and Live's Live site, someone is bound to become confused.

Develop XSLT Templates in Three Steps

A variety of Web-related technologies, including SDL Tridion, have the ability to use XSL Transformations (XSLT) to transform XML into almost any other text-based format; which is handy when converting say, component content stored in XML into HTML or XHTML.*

I love sites like W3Schools that provide detailed tutorials and references on how XSLT works. Other "cookbook" references like this one from XMLPlease.com or the actual XSLT Cookbook from O'Reily give practical and useful examples. An online search for "XSLT identity template" will get you started, but where do we go from there?

I want to add some practical advice on how to work with XSLT in different scenarios, starting with this tip:

<xsl:copy-of select="."/> is GPS for XPath.

When developing and moving around nodes, it helps to see the full source of what you're selecting via XPath. The xsl:copy-of function is the printf() of XSL.

When working with XSLT, I typically iterate towards a final template using three XSL functions. The following assumes you're somewhat familiar with XSLT, have read some of the resources above, but might be stuck on where to start or how to troubleshoot a non-matching XPath.

1) I typically start by reviewing the example source XML file or using the copy-of function.

2) For simple text values, I use xsl:value-of, setting the select attribute to the XPath to the right node or attribute I need. This is useful for structured content where you have a title or headline in plain text and you want to place it somewhere in your output.

3) The final (non-trivial) step is to add xsl:apply-templates as needed to do less selecting and more transforming. The resources above can go into further detail in how to replace nodes, remove namespaces, and best use recursion to do some pretty impressive transformations to the source XML.

If you have the ability to innately understand an XML schema and figure out XPath strings on-the-fly, feel free to skip this copy-of, value-of, apply-templates "method." But if you ever find yourself deeply nested in someone else's XSLT template and can't figure out why something doesn't match, these functions can save some time and frustration.

If the Xpath match doesn't do anything, double check the source with <xsl:copy-of select="."/> within context or replace the period with the Xpath you're troubleshooting. If that doesn't give you anything, go one step higher and remove the last node in your Xpath.

*Tridion uses a variety of templating languages from script-based to XSLT to modular templates using HTML-like Dreamweaver syntax and C# building blocks. XSLT may be a strong and elegant tool, but it's only one of several ways to work with content in Tridion or any other Web-related technology stack.

The New Tridion 2011 Criteria Objects

Despite minor confusion on how the new Tridion 2011 Criteria objects work, the dev teams I work with are satisfied with the new criteria objects (or maybe just relieved that the recent upgrade is nearly done).

I kind of miss that insider-knowledge that a custom Tridion broker metadata query involved multiple key/value "ANDs" separated by "ORs" and combined with a "GROUP BY"! However, the new objects will be easier to explain and maintain.

After your Tridion content management explorer (CME) site is all set up (VM or otherwise) and you're able to publish to a presentation server, you can use the new Criteria objects to pull back matching custom metadata fields and/or values from the broker database.

For example, to find components that have the key name "city," use the following in your presentation server code-behind (C#):

CustomMetaKeyCriteria keyCity = new CustomMetaKeyCriteria("city");

To find specific values, use:

CustomMetaValueCriteria valueLocal = new CustomMetaValueCriteria("San Diego");

You could combine these with an "AND" criteria matches as in:

AndCriteria andCriteria = new AndCriteria(keyCity, orCriteria);

However, to really get a query or filter that matches a key name (the stored XML field name in the content management explorer) to its saved value, you probably want:

CustomMetaValueCriteria value = new CustomMetaValueCriteria(new CustomMetaKeyCriteria("city"), "San Diego");

Using "ANDs" instead of the two-paramater CustomMetaValueCriteria object could work most of the time until you run into a scenario with a match on the key in one (broker database) column and a separate match in the value column for the same component. Tridion 2011 stores the key/value pairs as separate rows in the database making for cleaner queries, but be sure to use the correct Criteria objects. Just cause a filter pulls back Tridion content management identifiers (tcmids) it doesn't mean the query logic is right.

Big thanks to the ASH team and Tridion's Nuno for the help with these on TridionWorld and with Tridion Professional Services (thanks to Tory Johnson)/support/R&D for pointing out the distinction. Nothing like a little collaborations to find a seemingly simple fix.

I highly recommend working with support for your critical issues, joining the forum for a broad range of perspectives from an active partner and developer community, and if you're fairly Tridion-savvy... jump in on the #tridion #oneliner meme going around on Twitter while it lasts.